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
Hi Wanmil, On the osm forum someone noticed that housenumbers were not found along secondary and tertiary roads: http://forum.openstreetmap.org/viewtopic.php?pid=337308#p337308 Could this be also related to the internal ref handling (ref is added to the name tag?). I agree the ref handling should be handled in the styles only and not in the mkgmap source code.
Hi If there is a name-field and a ref-field in Garmin-format, then I would suggest to fill them with mkgmap:ref and mkgmap:name, if these tags are not set or empty, use name and ref. Everything else should be handled in style-file. Also { name 'abc' } should be equal to { set name='abc'}. Henning
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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?
Yes it does affect the address search. See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg16032.html If you put a ref to the name, the housenumber can't find the matching streetname anymore.
Am 01.06.2013 19:28, schrieb Felix Hartmann:
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? In general it would be very nice and useful, if every change to name (or however the tag is called in the end) is handled by every mkgmap-operation as written in style-file. Maybe therefor it's neccesarry to have a special name-file ( in addition to lines, points,...). Each process working with names could take a look into this special file and takes in the end the tag name (or however called) as the name. This also would be completly compatible for existing styles. If there is no such style-file, name-Tag would be used. This also would make name-tag-list obsolet.
Why is it useful? Eg. European Garmin-devices and their users would have problems entering an arabic or chinese town-name in adress-surch. So you can extend the name with name:en (which are mostly sign-posted too) and the English name is eays surchable. Henning
participants (5)
-
aighes -
Felix Hartmann -
Henning Scholland
-
Minko -
WanMil