Not sure what you mean by adding a name with the .TYP file, can you explain a bit more? lowest priority I mean. Everything else is more important therefore it will be displayed instead of the POINTS. I'll try the flag you mention and test it. On 4/02/2025 9:41 pm, Ticker Berkin via mkgmap-dev wrote:
Hi
I've no experience of this but some thoughts:
Doesn't adding a name with the .TYP file work?
When you say "lowest priority", do you mean it draws Points after Polygons and Lines and is this the order mkgmap outputs things.
--order-by-decreasing-area might help as it keeps everything in each subdivision contained, rather than letting areas 'leak' into adjacent subdivisions, so conflicting with the order of writing.
Ticker
On Tue, 2025-02-04 at 20:29 +1100, Joao Almeida via mkgmap-dev wrote:
Hi,
I've been trying to work with the rendering issues with the garmin Tread since I got mine a couple of years ago. I have a Tread SxS edition. And moved from a Montana 700i and before than from the old Montana. In those devices my maps were perfect, what I rendered in basecamp rendered pretty much the same way in the devices.
With the Tread that is not the case at all!
Here are some of my findings so far.
Many of the DEFAULT mkgmap POINT codes and previous Garmin POINT codes are not rendered by the Tread. Do not confuse POI's with POINTS, POINTS are embedded map points like amenities, locations and other points. POIs are added by the user these normaly are gpx Items or orverlay layers. For this purpose I'm referring to POINTS.
I tested what POINTS were being rendered by the Tread device with the mkgmap test-map... Then I applied my TYP to the test map and managed to find what POINTS were rendered or not.
HERE are my findings: For the Tread to render a POINT IT CANNOT BE defined as FontStyle=NoLabel.
ALSO the POI itself has to have a NAME defined (data from OSM) or added via the Style. As an example I added this to my style: amenity = toilets { addlabel 'TOILETS' } [0x2200 resolution 24] #tread DEFAULT ICON
Also. The render of POINTS seems to depend massively on the rendering of the layers IE: Poligons and Lines. I've observed that the POINTS seem to have the lowest possible rendering priority compared to the other elements.
Hope it helps...
Let me know if you find a way to display a POINT without a label or a name...
Cheers Joao
On 11/12/2024 2:15 am, Ticker Berkin wrote:
Hi Scott
I'd suggest looking at what sort of details and labelling the devices show with their Garmin map, and then, as Nick/osm@pins suggests, find a tool to extract and format the TYP subfile and see what it defines.
The chance of mkgmap being reworked to generate the next generation container format is low. The chance of this providing functionally that will support addition point types, label formatting changes or feature selection based on devices is unknown, but, I'd suggest, also very low.
Ticker
On Mon, 2024-12-09 at 08:42 -0800, scott taggart wrote:
M,
Thanks for you input. I will dig deeper into mkgmap source code.
For what it's worth, I'd love to see some feedback from anyone in the OSM/mkgmap community regarding the XT2 and Tread devices and whether OSM-
mkgmap generated maps are working properly (specifically text labels). I'm curious if there will have to be some re-working of mkgmap to accommodate these devices.
Scott
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s