[mkgmap-dev] Handling of refs

Sat Jun 1 17:48:28 BST 2013

That's what I plan to do:

1. I will post a small gmapsupp.img with very few roads that show any 
possible combination of symbol, number of labels so that a broad number 
of people can test and post, in which situations which labels are 
displayed, spoken as routing instructions etc.

2. Implement new mkgmap tags:
mkgmap:ref_symbol
mkgmap:label1
..
mkgmap:label4
The new tags are used only if the mkgmap option --name-schema is set. If 
this option is not set (--no-name-schema) a warning is printed with 
hints how to reorganize the styles to use the new --name-schema.

@Felix: The address tags (mkgmap:country, mkgmap:region, mgkmap:city 
etc.) will stay the same.

3. After 3 months mkgmap uses --name-schema as default.

4. After another 3 months only the new tagging schema is supported.

WanMil

> Well in that case maybe we should introduce somthing like
>
> name (same name for everything)
> name:address
> name:label
> name:display_symbol...
>
> (or to keep compatibility with old we could keep the reverse namespace
> of display:name and just add the others)
> On 01.06.2013 10:36, WanMil wrote:
>> I've done some code review. AFAIK each road can have up to 4 labels. But
>> there is no ref field and no field for the highway symbols.
>> It is not yet clear to me how the 4 label fields are used in the devices
>> and Mapsource/Basecamp.
>>
>> That's what I've found out so far:
>> - In case the first label starts with a symbol code character the part
>> until the first whitespace is displayed as symbol (my Nüvi 1490 displays
>> the complete first label as symbol).
>>
>> - If the first label contains the symbol character plus text without
>> whitespace the second label is shown as street name.
>>
>> - The whole first label (excluding the symbol character) is used for
>> address search. This is an mkgmap problem and might be fixed easily.
>>
>> - I've never seen the third and/or fourth label in
>> Mapsource/Basecamp/device so I don't know how they are used by Garmin.
>>
>> I expect that there have been some discussion in the past about this but
>> I didn't start a search for this. Maybe someone has a hint for a good
>> thread in the mailing list.
>>
>> WanMil
>>
>>
>>> Hi,
>>>
>>> I tried to remove the name from motorway_links and other _links.
>>> My first approach was simple:
>>> highway=motorway_link { delete name }
>>>
>>> This changed nothing! Mmmh, I looked into the source code and observed
>>> that the action
>>> { name 'abc' }
>>> is different to
>>> { set name='abc' }
>>>
>>> After using { name 'abc' } it is not possible to remove or to change the
>>> name using the style. So I changed all rules to
>>> { set name='abc' }
>>>
>>> This improved things a bit but the refs were still displayed. Then I
>>> noticed that there is a lot of automatic name handling in the
>>> StyledConverter:
>>>
>>> The ref is composed of the tags mkgmap:display_name, ref, int_ref,
>>> nat_ref and reg_ref.
>>> If there is no name set the composed ref is used as name.
>>>
>>> So the final rule to remove the name from the motorway_link is
>>> highway=motorway_link { delete name; delete mkgmap:display_name; delete
>>> ref; delete ref; delete int_ref; delete nat_ref; delete reg_ref }
>>>
>>> I think this is not very intuitive?! Without having a look into the
>>> source code I would have never been able to remove the name.
>>>
>>> I wonder if it would be better to implement these hard coded rules
>>> within the style so anybody can see what happens and can easily
>>> influence the naming:
>>>
>>> 1. Create a new mkgmap tag mkgmap:ref which is used to set the ref field
>>> in the garmin map. Without setting mgkmap:ref the ref field will be
>>> empty. This makes mkgmap:display_name superfluous. Another advantage is
>>> that the ref, nat_ref etc. tags can be removed from the builtin-tag-list.
>>>
>>> 2. Set the name using the tag mkgmap:name. Remove the { name 'abc' }
>>> action. This might be controversial and requires changes in all styles.
>>>
>>> What do you think?
>>>
>>> WanMil
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>