logo separator

[mkgmap-dev] Handling of refs

From Felix Hartmann extremecarver at gmail.com on Sat Jun 1 18:28:26 BST 2013

okay, just make it clear what happens if in the style the plain "name" 
is changed. Does it affect the address search? Does it affect the label 
only? Does it affect the popup only?

but I think that's what will be shown after point 1. is done.
Currently I must say, I don't really understand what happens regarding 
address search on name changes within the style.

It would be great to have a clear differentiation between:
1. name used for address search
2. name used for label
3. name used for popup
4. name used for routing instructions (not sure which one this is, so we 
probably need to test and then document which of the 1-3 it actually is)
5. don't call the highway symbol thingy "name". It's a symbol only - so 
name is confusing (at least for me) - but of course it belongs here and 
in the documentation to this list of name options.

(1. should be the official name, 2. in some cases could be cut down to 
be shorter - maybe do this in general in order not to have monstrous 
long labels, 3. here one could include much more information - maybe we 
could even have an option to create new lines? document how many lines 
are shown on which GPS device / Mapsource / Basecamp, 4. well this one 
should be shorter again I suppose, 5. this is completely separate from 
name on the output, but created from similar (ref) input)


On 01.06.2013 12:48, WanMil wrote:
> 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
>>
>




More information about the mkgmap-dev mailing list