logo separator

[mkgmap-dev] Update on missing POI Labels on some devices and some questions...

From osm osm at pinns.co.uk on Sat Dec 7 19:59:51 GMT 2024

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 at lists.mkgmap.org.uk
>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20241207/607db307/attachment-0001.html>


More information about the mkgmap-dev mailing list