Moin, Chris66 schrieb am 05.10.2012 10:22:

When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is evaluating the first way behind all the _link ways. ... So the idea is a new mkgmap option --process-destination which does following pre-processing:

For all _link ways which have a destination-Tag copy the tag to the following non-link way (motorway or trunk).

I think, a better solution would be the splitting of the concerned link ways in two parts. The first part could get the types 0x08 or 0x09 assigned and the second part could get the destination tag for the display name. Modifying the following way might have some negative consequences for the display or routing information of this way, when you are not coming from the link. Gruss Torsten

Hi, I am also doing this. In addition, there is an undocumented tag "dest_ref" (sometimes "destination_ref") used to contain the ref of the road that the exit leads to. I override the "ref" of the ramp with "dest_ref" as the ref of the ramp is usually either the exit number or the ref of the motorway itself. The exit number could be useful, but IMHO only when we can get proper motorway exit handling in mkgmap. I believe this part of the img format is not yet understood. The effect of my customisations is that the spoken instructions say "keep right on N230 Maarssen" and not "keep right on 6 Maarssen". Maybe it's just me, but I find (signed) road numbers a useful hint. Also, dest_ref and destination can be exploited in plenty of other circumstances, including urban junctions where the ways for turning off are mapped separately. They can be used to reflect the signposting for routing/navigation purposes, irrespective of the actual name/ref of the road concerned. Using these distinct tags keeps them out of the way of tagging wars and inconsistent usage of the contents of "ref" and "name". My rules look like this: (highway=* & int_ref ~ 'E .*') {set int_ref='${int_ref|subst:E =>E}'} # if we have a ref, zap int_ref, otherwise ref<=int_ref (highway=* & ref!=* & int_ref=*) {set ref='${int_ref}'} highway=* {delete int_ref;} (highway ~ '.*_link') & exit:to=* {set name='${exit:to}'} (highway=* & destination=*) {set name='${destination}'} (highway=* & destination_ref=*) {set ref='${destination_ref}'} (highway=* & dest_ref=*) {set ref='${dest_ref}'} In order for this to work, I needed to change the "feature code" (is that the right term?) for the *_link roads to be the same as the base highway type as the standard ramp codes 0x08 and 0x09 seem to ignore the name of the ramp itself and instead the text is based on the road at the end of the ramp, which is not always handy. Colin

Hi, I added following lines to my style file in order to display the "destination"-Tag on motorway-junctions:

----------

# Set the routing direction (highway=motorway|highway=motorway_link) & destination=* { add display_name = '${ref} (${destination})' } (highway=trunk|highway=trunk_link) & destination=* { add display_name = '${ref} (${destination})' }

# Set highway names to include the reference if there is one

----------

This works well (see pictures [2] and [3]), but:

When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is evaluating the first way behind all the _link ways.

This is not what is stated in the wiki [1]. In most cases, only the _link ways are tagged.

So the idea is a new mkgmap option --process-destination which does following pre-processing:

For all _link ways which have a destination-Tag copy the tag to the following non-link way (motorway or trunk).

Chris

[1] http://wiki.openstreetmap.org/wiki/Key:destination [2] http://up.picr.de/11670098jg.png [3] http://up.picr.de/11670102jj.png

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev