Update on missing POI Labels on some devices and some questions...
* As I posted here <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2024q4/034350.html>on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): ** * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps. Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this? Any and all help is appreciated. *
Hi Scott There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread... By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage. Sticking to these can make a reasonably well-featured map that works on many devices. Many POI types don't show at low resolution! For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format) https://www.mkgmap.org.uk > Documentation is a starting point for help. Ticker On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps. Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this? Any and all help is appreciated. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I agree with Ticker; there is also something else which MAY help: If your Garmin came with maps its worth checking which points do show up. A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile Regards Nick On 07/12/2024 15:52, Ticker Berkin wrote:
Hi Scott
There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread...
By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage.
Sticking to these can make a reasonably well-featured map that works on many devices.
Many POI types don't show at low resolution!
For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes
I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format)
https://www.mkgmap.org.uk > Documentation is a starting point for help.
Ticker
On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps.
Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this?
Any and all help is appreciated.
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
* Thanks everyone for the input. If I understand correctly, there seems to be no universal POI types across all devices (when I look at some of the referenced lists, there seems to be a small bit of consistency with the 0x01...0x11?) types. However, as I have seen in practice, some of the newer devices such as XT2/Tread seem to not even follow these "standards" (the XT2 and Tread definitely do not display text for the well-known 0x1400 type). In my particular case, I need (only) one POI type that will always display a big text label and ideally, no icon (I'm settled for now on 0x1E00 which seems to work across all devices I care about (until garmin releases some new device)). At the risk of repeating what I have previously asked, can anyone explain to me: * Assuming there's no consistency across devices, how do the OSM generated maps work across devices? Do they not? (I'm not an OSM expert by any means). How the heck does OSM always know a text label will be displayed on every device for a given POI type? When OSM maps are generated does the creator specify a device type so that internal OSM type maps can be used (sorry for my ignorance of how OSM works). In thinking more about this, does OSM generate a TYP file that defines custom point types for all needed icons so they work across all devices? Seems like that is the only way any of this could work. * Even more perplexing, does this mean that garmin must release different versions of maps for each device class (say a US topo)? I never buy garmin maps so maybe I have missed this. When I look online to buy the garmin 100k topo <https://www.garmin.com/en-US/p/127633#requirements>, it seems it works for all devices. * Finally, and I asked this before, is there any mkgmap capabilities I can get to using the .osm input as opposed to the mp file format (assuming I generate TYP files)? I ask this because I want to potentially save myself from trying to dive very deep into the non-mp file stuff if there's nothing to be gained. * And finally, just to vent here, why in God's name would a manufacturer ever create such a mess??? Seems like a real headache even for them, let alone us reverse-engineers ;) Thanks again for your patience. As you can tell, I am a blind man stumbling around in a dark room here. * On 12/7/2024 8:07 AM, osm wrote:
I agree with Ticker; there is also something else which MAY help:
If your Garmin came with maps its worth checking which points do show up.
A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile
Regards
Nick
On 07/12/2024 15:52, Ticker Berkin wrote:
Hi Scott
There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread...
By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage.
Sticking to these can make a reasonably well-featured map that works on many devices.
Many POI types don't show at low resolution!
For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes
I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format)
https://www.mkgmap.org.uk > Documentation is a starting point for help.
Ticker
On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps.
Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this?
Any and all help is appreciated.
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Scott, OSM is just a data source, it doesn't create Garmin maps. I think there must be two different programs which are able to generate Garmin maps with OSM data as input, one is mkgmap, the other is the one used by Garmin. As far as I know this program creates maps in a newer IMG format and maybe there are standards how POI are treated in this newer format. I assume that Garmin simply doesn't test new hard or firmware against old maps produced 10 years ago, and I am surprised that new devices still support this old and limited format. It is possible that there is a not-yet-identified bit in the IMG format which influences the rendering. The code in mkgmap which writes the IMG format is the same for .mp input and osm input, so I don't see how using OSM data as input could help you. ciao Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von scott taggart <taggart@taggarts.org> Gesendet: Samstag, 7. Dezember 2024 20:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Update on missing POI Labels on some devices and some questions... Thanks everyone for the input. If I understand correctly, there seems to be no universal POI types across all devices (when I look at some of the referenced lists, there seems to be a small bit of consistency with the 0x01...0x11?) types. However, as I have seen in practice, some of the newer devices such as XT2/Tread seem to not even follow these "standards" (the XT2 and Tread definitely do not display text for the well-known 0x1400 type). In my particular case, I need (only) one POI type that will always display a big text label and ideally, no icon (I'm settled for now on 0x1E00 which seems to work across all devices I care about (until garmin releases some new device)). At the risk of repeating what I have previously asked, can anyone explain to me: * Assuming there's no consistency across devices, how do the OSM generated maps work across devices? Do they not? (I'm not an OSM expert by any means). How the heck does OSM always know a text label will be displayed on every device for a given POI type? When OSM maps are generated does the creator specify a device type so that internal OSM type maps can be used (sorry for my ignorance of how OSM works). In thinking more about this, does OSM generate a TYP file that defines custom point types for all needed icons so they work across all devices? Seems like that is the only way any of this could work. * Even more perplexing, does this mean that garmin must release different versions of maps for each device class (say a US topo)? I never buy garmin maps so maybe I have missed this. When I look online to buy the garmin 100k topo<https://www.garmin.com/en-US/p/127633#requirements>, it seems it works for all devices. * Finally, and I asked this before, is there any mkgmap capabilities I can get to using the .osm input as opposed to the mp file format (assuming I generate TYP files)? I ask this because I want to potentially save myself from trying to dive very deep into the non-mp file stuff if there's nothing to be gained. * And finally, just to vent here, why in God's name would a manufacturer ever create such a mess??? Seems like a real headache even for them, let alone us reverse-engineers ;) Thanks again for your patience. As you can tell, I am a blind man stumbling around in a dark room here. On 12/7/2024 8:07 AM, osm wrote: I agree with Ticker; there is also something else which MAY help: If your Garmin came with maps its worth checking which points do show up. A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile Regards Nick On 07/12/2024 15:52, Ticker Berkin wrote: Hi Scott There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread... By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage. Sticking to these can make a reasonably well-featured map that works on many devices. Many POI types don't show at low resolution! For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format) https://www.mkgmap.org.uk > Documentation is a starting point for help. Ticker On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote: As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps. Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this? Any and all help is appreciated. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
You're a bit 'confused' It's not OSM that determines the visibility of types but the Garmin device itself . mkgmap creates maps based on osm data and 'feeds' devices with maps. It's up the each device to accept part or all of the map. So in your case , much of the data gets ignored and falls on death ears, ie it's eclectic On 07/12/2024 19:17, scott taggart wrote:
*
Thanks everyone for the input. If I understand correctly, there seems to be no universal POI types across all devices (when I look at some of the referenced lists, there seems to be a small bit of consistency with the 0x01...0x11?) types. However, as I have seen in practice, some of the newer devices such as XT2/Tread seem to not even follow these "standards" (the XT2 and Tread definitely do not display text for the well-known 0x1400 type). In my particular case, I need (only) one POI type that will always display a big text label and ideally, no icon (I'm settled for now on 0x1E00 which seems to work across all devices I care about (until garmin releases some new device)). At the risk of repeating what I have previously asked, can anyone explain to me:
*
Assuming there's no consistency across devices, how do the OSM generated maps work across devices? Do they not? (I'm not an OSM expert by any means). How the heck does OSM always know a text label will be displayed on every device for a given POI type? When OSM maps are generated does the creator specify a device type so that internal OSM type maps can be used (sorry for my ignorance of how OSM works). In thinking more about this, does OSM generate a TYP file that defines custom point types for all needed icons so they work across all devices? Seems like that is the only way any of this could work.
*
Even more perplexing, does this mean that garmin must release different versions of maps for each device class (say a US topo)? I never buy garmin maps so maybe I have missed this. When I look online to buy the garmin 100k topo <https://www.garmin.com/en-US/p/127633#requirements>, it seems it works for all devices.
*
Finally, and I asked this before, is there any mkgmap capabilities I can get to using the .osm input as opposed to the mp file format (assuming I generate TYP files)? I ask this because I want to potentially save myself from trying to dive very deep into the non-mp file stuff if there's nothing to be gained.
*
And finally, just to vent here, why in God's name would a manufacturer ever create such a mess??? Seems like a real headache even for them, let alone us reverse-engineers ;)
Thanks again for your patience. As you can tell, I am a blind man stumbling around in a dark room here.
* On 12/7/2024 8:07 AM, osm wrote:
I agree with Ticker; there is also something else which MAY help:
If your Garmin came with maps its worth checking which points do show up.
A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile
Regards
Nick
On 07/12/2024 15:52, Ticker Berkin wrote:
Hi Scott
There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread...
By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage.
Sticking to these can make a reasonably well-featured map that works on many devices.
Many POI types don't show at low resolution!
For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes
I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format)
https://www.mkgmap.org.uk > Documentation is a starting point for help.
Ticker
On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps.
Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this?
Any and all help is appreciated.
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 12/7/2024 11:59 AM, osm wrote:
You're a bit 'confused'
It's not OSM that determines the visibility of types but the Garmin device itself .
mkgmap creates maps based on osm data and 'feeds' devices with maps. It's up the each device to accept part or all of the map. So in your case , much of the data gets ignored and falls on death ears, ie it's eclectic
Confused and ignorant at this point, for sure! Now nderstood that OSM just outputs its contents (in .osm format, correct) to be rendered by mkgmap into a .img file. My central question is still: "do OSM maps largely work across all garmin devices, including the newer XT2 and tread, including having basic text labels"? Assuming "yes" for the moment, where is the secret sauce in mkgmap that generate universally displayable text labels? Does the .osm format pass enough "style" info to mkgmap for it to construct TYP files and POI references that work across most garmin units? Scott
On 07/12/2024 19:17, scott taggart wrote:
*
Thanks everyone for the input. If I understand correctly, there seems to be no universal POI types across all devices (when I look at some of the referenced lists, there seems to be a small bit of consistency with the 0x01...0x11?) types. However, as I have seen in practice, some of the newer devices such as XT2/Tread seem to not even follow these "standards" (the XT2 and Tread definitely do not display text for the well-known 0x1400 type). In my particular case, I need (only) one POI type that will always display a big text label and ideally, no icon (I'm settled for now on 0x1E00 which seems to work across all devices I care about (until garmin releases some new device)). At the risk of repeating what I have previously asked, can anyone explain to me:
*
Assuming there's no consistency across devices, how do the OSM generated maps work across devices? Do they not? (I'm not an OSM expert by any means). How the heck does OSM always know a text label will be displayed on every device for a given POI type? When OSM maps are generated does the creator specify a device type so that internal OSM type maps can be used (sorry for my ignorance of how OSM works). In thinking more about this, does OSM generate a TYP file that defines custom point types for all needed icons so they work across all devices? Seems like that is the only way any of this could work.
*
Even more perplexing, does this mean that garmin must release different versions of maps for each device class (say a US topo)? I never buy garmin maps so maybe I have missed this. When I look online to buy the garmin 100k topo <https://www.garmin.com/en-US/p/127633#requirements>, it seems it works for all devices.
*
Finally, and I asked this before, is there any mkgmap capabilities I can get to using the .osm input as opposed to the mp file format (assuming I generate TYP files)? I ask this because I want to potentially save myself from trying to dive very deep into the non-mp file stuff if there's nothing to be gained.
*
And finally, just to vent here, why in God's name would a manufacturer ever create such a mess??? Seems like a real headache even for them, let alone us reverse-engineers ;)
Thanks again for your patience. As you can tell, I am a blind man stumbling around in a dark room here.
* On 12/7/2024 8:07 AM, osm wrote:
I agree with Ticker; there is also something else which MAY help:
If your Garmin came with maps its worth checking which points do show up.
A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile
Regards
Nick
On 07/12/2024 15:52, Ticker Berkin wrote:
Hi Scott
There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread...
By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage.
Sticking to these can make a reasonably well-featured map that works on many devices.
Many POI types don't show at low resolution!
For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes
I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format)
https://www.mkgmap.org.uk > Documentation is a starting point for help.
Ticker
On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps.
Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this?
Any and all help is appreciated.
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
You make an interesting point. There are certain aspects of the Garmin img file structure mkgmap does not understand because it hasn't been reverse-engineered but I am more than certain that the bits we don't understand do not affect labelling of pois . Certainly the TYP file structure which I understand fully , has nothing to do with your POI labelling issues. mkgmap creates maps of an older Garmin format If maps created by Garmin show the 'hidden' POIs and mkgmap generated maps don't then it seems that for some strange reason these Garmin devices adopt the new format for points but not for lines or polygons etc - we've not seen any evidence of this when analysing NT maps (new format). I think the latest batch of new devices are similar to the myriad of watches Garmin produces , where price is determined by the number of options/tools. On 07/12/2024 20:10, scott taggart wrote:
On 12/7/2024 11:59 AM, osm wrote:
You're a bit 'confused'
It's not OSM that determines the visibility of types but the Garmin device itself .
mkgmap creates maps based on osm data and 'feeds' devices with maps. It's up the each device to accept part or all of the map. So in your case , much of the data gets ignored and falls on death ears, ie it's eclectic
Confused and ignorant at this point, for sure!
Now nderstood that OSM just outputs its contents (in .osm format, correct) to be rendered by mkgmap into a .img file. My central question is still: "do OSM maps largely work across all garmin devices, including the newer XT2 and tread, including having basic text labels"? Assuming "yes" for the moment, where is the secret sauce in mkgmap that generate universally displayable text labels? Does the .osm format pass enough "style" info to mkgmap for it to construct TYP files and POI references that work across most garmin units?
Scott
On 07/12/2024 19:17, scott taggart wrote:
*
Thanks everyone for the input. If I understand correctly, there seems to be no universal POI types across all devices (when I look at some of the referenced lists, there seems to be a small bit of consistency with the 0x01...0x11?) types. However, as I have seen in practice, some of the newer devices such as XT2/Tread seem to not even follow these "standards" (the XT2 and Tread definitely do not display text for the well-known 0x1400 type). In my particular case, I need (only) one POI type that will always display a big text label and ideally, no icon (I'm settled for now on 0x1E00 which seems to work across all devices I care about (until garmin releases some new device)). At the risk of repeating what I have previously asked, can anyone explain to me:
*
Assuming there's no consistency across devices, how do the OSM generated maps work across devices? Do they not? (I'm not an OSM expert by any means). How the heck does OSM always know a text label will be displayed on every device for a given POI type? When OSM maps are generated does the creator specify a device type so that internal OSM type maps can be used (sorry for my ignorance of how OSM works). In thinking more about this, does OSM generate a TYP file that defines custom point types for all needed icons so they work across all devices? Seems like that is the only way any of this could work.
*
Even more perplexing, does this mean that garmin must release different versions of maps for each device class (say a US topo)? I never buy garmin maps so maybe I have missed this. When I look online to buy the garmin 100k topo <https://www.garmin.com/en-US/p/127633#requirements>, it seems it works for all devices.
*
Finally, and I asked this before, is there any mkgmap capabilities I can get to using the .osm input as opposed to the mp file format (assuming I generate TYP files)? I ask this because I want to potentially save myself from trying to dive very deep into the non-mp file stuff if there's nothing to be gained.
*
And finally, just to vent here, why in God's name would a manufacturer ever create such a mess??? Seems like a real headache even for them, let alone us reverse-engineers ;)
Thanks again for your patience. As you can tell, I am a blind man stumbling around in a dark room here.
* On 12/7/2024 8:07 AM, osm wrote:
I agree with Ticker; there is also something else which MAY help:
If your Garmin came with maps its worth checking which points do show up.
A TYP file may be included into the gmapsupp which will should reveal some of the types used - Gmaptool can export this supfile
Regards
Nick
On 07/12/2024 15:52, Ticker Berkin wrote:
Hi Scott
There is some consistency across Garmin models I've come across for a set of standard POIs that have a (semi-)defined meaning; but I don't know if Garmin are breaking this with devices like XT, Tread...
By semi-defined I mean they respond to appropriate 'FIND' searches and some devices actually show what considers the POI to be. There are various lists of these around the internet and, from a mkgmap distribution, ./examples/styles/default/points shows usage.
Sticking to these can make a reasonably well-featured map that works on many devices.
Many POI types don't show at low resolution!
For the POI you've mentioned, I've noted from experimentation: 0x14 No icon. Country. Big font. no subtypes {major country} 0x1e No icon. has name. State {province/region}. no subtypes
I don't think you get any difference in the final map and behaviour whether the input is MP or from OSM (osm.pbf, o5m, etc format)
https://www.mkgmap.org.uk > Documentation is a starting point for help.
Ticker
On Fri, 2024-12-06 at 10:47 -0800, scott taggart wrote:
As I posted here on 2024.12.01, I was having issues with POIs not displaying labels for some garmin devices (specifically the XT2 and Tread) when generating /img files using mp file input to mkgmap. I did some exploration and discovered this (maybe well known but not by me): * Each device model displays POIs differently (i.e., type 0x100 does not show the same thing). There seems to be no consistency across models (Felix echoed this in a follow-up post). * Each model displays labels for each POI type differently (some show no label, others show small vs big text). There seems to be no consistency across models. * I attempted to use the custom "[_point]" feature of the mp files and mkgmap but the custom point bitmaps only work for some garmins. Even then, it didn't help with my missing [poi] labels. * Prior to the labels not working on the XT2 and Tread units, I always used the 0x1400 POI code type for my labels. With a lot of cross-model experimentation I discovered a single POI code (0x1E00) will display large text on all garmin models I was able to test with (Montana 6XX and 7XX, XT, XT2, Tread). I have no idea if this POI code will work with all garmins that support custom maps.
Questions: * Are these issues with each model behaving differently with respect to POI types well-known? If so, how are they gotten around by (OSM) map builders? How can a single map be built that has POIs and labels that are consistent across more than one device. What am I missing? * How does OSM handle this? I presume that an OSM map generated for an area works on all garmin devices? I will admit that I don't know what the OSM map limitations are across garmin models. Does the JOSN model allow the devices POI maps to be loaded on a per-map basis? If I were to switch to JOSN model for mkgmap input, could I get around all the device limitations I am running into with the mp file format? Can someone recommend a good tutorial on getting up to speed on generating JOSN for simple map input to mkgmap? * OSM uses the JOSM model to feed mkgmap. Does that model allow for more flexibility and control than the "mp" input file model? I presume the MP file format is obsolete. * Is there any better documentation for the MPO format than the CGPSMAPPER pdf file floating around on the internet? * Can anyone recommend either a different website or people whom I may contact for further help with any of this?
Any and all help is appreciated.
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
De: "scott taggart" <taggart@taggarts.org> Para: "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Sábado, 7 de Diciembre 2024 17:10:19 Asunto: Re: [mkgmap-dev] Update on missing POI Labels on some devices and some questions...
On 12/7/2024 11:59 AM, osm wrote:
You're a bit 'confused'
It's not OSM that determines the visibility of types but the Garmin device itself .
mkgmap creates maps based on osm data and 'feeds' devices with maps. It's up the each device to accept part or all of the map. So in your case , much of the data gets ignored and falls on death ears, ie it's eclectic
Confused and ignorant at this point, for sure!
Now nderstood that OSM just outputs its contents (in .osm format, correct) to be rendered by mkgmap into a .img file. My central question is still: "do OSM maps largely work across all garmin devices, including the newer XT2 and tread, including having basic text labels"? Assuming "yes" for the moment, where is the secret sauce in mkgmap that generate universally displayable text labels? Does the .osm format pass enough "style" info to mkgmap for it to construct TYP files and POI references that work across most garmin units?
Scott
OSM "only" provides geographic data and does not have nor pass nothing with respect to the style to mkgmap or to any other map generator. The "secret sauce" in mkgmap is hidden in the styles and typ files, which most of them are created after hours and hours of trial and error, and checking which device show which types and how they show them. Most authors of mkgmap compiled maps distributes their maps for free, and got feedback from their users and (with some luck and mostly effort) maps get improved in every release, not only because the OSM data gets updated, but also because mkgmap has been improved, and also some maps get more and more specialized. Maybe you can learn more digging in the svn of mkgmap for changes in the default styles, or in the code from some authors that have their tool chain in github. Some old docs here https://www.cferrero.net/maps/maps_index.html and a list of providers here https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download Most of the time the investigation is done using synthetic osm files (not real data, but data specially crafted to be able to see how a map work in a device), which POIs are shown, which categories, etc. etc. Regards. M. 2.15.1.0
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 On 12/8/2024 6:24 PM, muralito@montevideo.com.uy wrote:
*De: *"scott taggart" <taggart@taggarts.org> *Para: *"mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> *Enviados: *Sábado, 7 de Diciembre 2024 17:10:19 *Asunto: *Re: [mkgmap-dev] Update on missing POI Labels on some devices and some questions...
On 12/7/2024 11:59 AM, osm wrote:
You're a bit 'confused'
It's not OSM that determines the visibility of types but the Garmin device itself .
mkgmap creates maps based on osm data and 'feeds' devices with maps. It's up the each device to accept part or all of the map. So in your case , much of the data gets ignored and falls on death ears, ie it's eclectic
Confused and ignorant at this point, for sure!
Now nderstood that OSM just outputs its contents (in .osm format, correct) to be rendered by mkgmap into a .img file. My central question is still: "do OSM maps largely work across all garmin devices, including the newer XT2 and tread, including having basic text labels"? Assuming "yes" for the moment, where is the secret sauce in mkgmap that generate universally displayable text labels? Does the .osm format pass enough "style" info to mkgmap for it to construct TYP files and POI references that work across most garmin units?
Scott
OSM "only" provides geographic data and does not have nor pass nothing with respect to the style to mkgmap or to any other map generator.
The "secret sauce" in mkgmap is hidden in the styles and typ files, which most of them are created after hours and hours of trial and error, and checking which device show which types and how they show them. Most authors of mkgmap compiled maps distributes their maps for free, and got feedback from their users and (with some luck and mostly effort) maps get improved in every release, not only because the OSM data gets updated, but also because mkgmap has been improved, and also some maps get more and more specialized. Maybe you can learn more digging in the svn of mkgmap for changes in the default styles, or in the code from some authors that have their tool chain in github. Some old docs here https://www.cferrero.net/maps/maps_index.html and a list of providers here https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download
Most of the time the investigation is done using synthetic osm files (not real data, but data specially crafted to be able to see how a map work in a device), which POIs are shown, which categories, etc. etc.
Regards. M. 2.15.1.0
Documento sin título
---------------------------------------------------------------------------------------------------------------------------------------
<https://crm2.montevideo.com.uy/trazabilidad/servlet/aredirect1?LPhdB6L%2FWNhVZs6SLZxphQ%3D%3D>
Factura Electrónica de Montevideo COMM La instalación más rápida de todo Uruguay Informate aquí. <https://crm2.montevideo.com.uy/trazabilidad/servlet/aredirect1?LPhdB6L%2FWNhVZs6SLZxphQ%3D%3D>
---------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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
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
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
Hi Joao In the .typ file having something like: [_point] type=0x02d subtype=0x09 String=Swimming Pool String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x03,Zwembad String15=0x15,Basen String10=0x10,Piscina String5=0x05,Piscina ... [end] StringX is just to make it unique and I generally use the language code here, but, AFIR, it doesn't matter what number. The entry without a language code defaults to 0x00. Code Zero is used if there isn't a specific entry the device language. Worrying that it doesn't display a point in an area. You might find the --order- by.. option fixes it. If not will need to look at the order in which mkmap outputs the sections Ticker On Tue, 2025-02-04 at 22:37 +1100, Joao Almeida via mkgmap-dev wrote:
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
_______________________________________________ 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
Hi Ticker, No the String does not make any difference I've tested with multiple combinations. The only thing that makes a difference is FontStyle=NoLabel or the name tag not being present in the POINT tags. The whole thing is very frustrating... On 4/02/2025 11:10 pm, Ticker Berkin via mkgmap-dev wrote:
Hi Joao
In the .typ file having something like:
[_point] type=0x02d subtype=0x09 String=Swimming Pool String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x03,Zwembad String15=0x15,Basen String10=0x10,Piscina String5=0x05,Piscina ... [end]
StringX is just to make it unique and I generally use the language code here, but, AFIR, it doesn't matter what number. The entry without a language code defaults to 0x00. Code Zero is used if there isn't a specific entry the device language.
Worrying that it doesn't display a point in an area. You might find the --order- by.. option fixes it. If not will need to look at the order in which mkmap outputs the sections
Ticker
On Tue, 2025-02-04 at 22:37 +1100, Joao Almeida via mkgmap-dev wrote:
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
_______________________________________________ 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
Hi Joao 1) Have you tried NT equivalent types? ie 0x2d --> 0x10e2d 2) Use the customizable pois : 0x11500 - 115FF r Nick On 04/02/2025 20:44, Joao Almeida via mkgmap-dev wrote:
Hi Ticker, No the String does not make any difference I've tested with multiple combinations. The only thing that makes a difference is FontStyle=NoLabel or the name tag not being present in the POINT tags.
The whole thing is very frustrating...
On 4/02/2025 11:10 pm, Ticker Berkin via mkgmap-dev wrote:
Hi Joao
In the .typ file having something like:
[_point] type=0x02d subtype=0x09 String=Swimming Pool String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x03,Zwembad String15=0x15,Basen String10=0x10,Piscina String5=0x05,Piscina ... [end]
StringX is just to make it unique and I generally use the language code here, but, AFIR, it doesn't matter what number. The entry without a language code defaults to 0x00. Code Zero is used if there isn't a specific entry the device language.
Worrying that it doesn't display a point in an area. You might find the --order- by.. option fixes it. If not will need to look at the order in which mkmap outputs the sections
Ticker
On Tue, 2025-02-04 at 22:37 +1100, Joao Almeida via mkgmap-dev wrote:
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
_______________________________________________ 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
_______________________________________________ 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
Hi Nick, Yes I have tested unfortunately I didn't even managed to get the NT equivalent or the customizable POIS to display... On 5/02/2025 6:13 pm, osm via mkgmap-dev wrote:
Hi Joao
1) Have you tried NT equivalent types?
ie 0x2d --> 0x10e2d
2) Use the customizable pois : 0x11500 - 115FF
r
Nick
On 04/02/2025 20:44, Joao Almeida via mkgmap-dev wrote:
Hi Ticker, No the String does not make any difference I've tested with multiple combinations. The only thing that makes a difference is FontStyle=NoLabel or the name tag not being present in the POINT tags.
The whole thing is very frustrating...
On 4/02/2025 11:10 pm, Ticker Berkin via mkgmap-dev wrote:
Hi Joao
In the .typ file having something like:
[_point] type=0x02d subtype=0x09 String=Swimming Pool String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x03,Zwembad String15=0x15,Basen String10=0x10,Piscina String5=0x05,Piscina ... [end]
StringX is just to make it unique and I generally use the language code here, but, AFIR, it doesn't matter what number. The entry without a language code defaults to 0x00. Code Zero is used if there isn't a specific entry the device language.
Worrying that it doesn't display a point in an area. You might find the --order- by.. option fixes it. If not will need to look at the order in which mkmap outputs the sections
Ticker
On Tue, 2025-02-04 at 22:37 +1100, Joao Almeida via mkgmap-dev wrote:
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
_______________________________________________ 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
_______________________________________________ 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
participants (6)
-
Gerd Petermann -
Joao Almeida -
muralito＠montevideo.com.uy -
osm -
scott taggart -
Ticker Berkin