setting display_name to "name "
It seems that dipslay_name internally in mkgmap is not allowed to be set to "name". If identical it will not be set at all. Or is this really a Garmin limitation? To me it seems to be rather an mkgmap bug. If I set: {name '${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}' | '${name}'; set display_name='${ref}_${name}'} Both name and display_name are set correctly. If I change this to: {name '${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}' | '${name}'; set display_name='${ref} ${name}'} then display_name is not set (hence only ref will show up in routing instructions). Also splitting up the command into two lines, and setting dipsplay_name='${name}' after name in a second line it will not be set.
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
It seems that dipslay_name internally in mkgmap is not allowed to be set to "name". If identical it will not be set at all. Or is this really a Garmin limitation? To me it seems to be rather an mkgmap bug.
As far as I can tell, this behaviour was added by Mark's highway shield "crap" patch. I think this change in Subdivision.java is responsible: if(trSansGC.length() > 0 && !trSansGC.equalsIgnoreCase(nameSansGC)) { //System.err.println("Adding ref " + tr + " to road " + name); pl.addRefLabel(lblFile.newLabel(tr)); } You can see the additional label will only be added if it differs from the name after the Garmin codes have been stripped from the name. Cheers.
On 21.03.2010 22:08, Mark Burton wrote:
Folks,
You can see the additional label will only be added if it differs from the name after the Garmin codes have been stripped from the name.
Sure, what's the point in having multiple labels the same (apart from the shield code)?
Mark
I'm not setting multiple labels. The display_name is the name shown for routing instructions. If not set, the ref alone will be taken instead. So instead of say "left on A11 Westautobahn" the GPS will only say "left on A11". Actually it would be great if one could set the display_name for all roads, but I think it is only possible for roads with a highway-shield. The name display_name is a bit incorrect, it would be more logically named "routing_instructions_name". Strangely in City Navigator maps, there is no additional tooltip for "display_name" even when they use it, whereas with mkgmap we will always have a second tooltip (be it on GPS or Mapsource).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
I'm not setting multiple labels. The display_name is the name shown for routing instructions. If not set, the ref alone will be taken instead. So instead of say "left on A11 Westautobahn" the GPS will only say "left on A11".
Hmm, for me, I still get the longer routing instruction. For example, if the first label is "B5395" (with a highway shield prefix) and the second label (set through display_name) is "Oldhall Street (B5395)", then the routing instructions is: Turn right onto Oldhall Street (B5395) 2.5 km 1.5 km 0:02:16 0:03:44 46° true N53.02019 W2.76553 The patch we're currently evaluating hasn't changed that behaviour. Mark
On 21.03.2010 23:29, Mark Burton wrote:
Felix,
I'm not setting multiple labels. The display_name is the name shown for routing instructions. If not set, the ref alone will be taken instead. So instead of say "left on A11 Westautobahn" the GPS will only say "left on A11".
Hmm, for me, I still get the longer routing instruction.
For example, if the first label is "B5395" (with a highway shield prefix) and the second label (set through display_name) is "Oldhall Street (B5395)", then the routing instructions is:
Turn right onto Oldhall Street (B5395) 2.5 km 1.5 km 0:02:16 0:03:44 46° true N53.02019 W2.76553 Well that is intended behaviour. The first label is used to be "printed" on the map, and display_name is only used if a highway-symbol is present. Then it will be used. If display_name is not given, then your first label would have been used. If neither is given, then it would simply be "Oldhall Street". The patch for the patch by Clinton, allows that display_name can be identical to "name" and I find it pretty useful.
The patch we're currently evaluating hasn't changed that behaviour.
Your version 4, disallowed setting display_name and name to the same value.
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
The patch for the patch by Clinton, allows that display_name can be identical to "name" and I find it pretty useful.
I am very slow - please spell it out for me. How does having two labels that are the same apart from the first one having a highway shield prefix behave any differently from just having the first label on its own? I don't understand the benefit. Mark
On 21.03.2010 23:42, Mark Burton wrote:
Felix,
The patch for the patch by Clinton, allows that display_name can be identical to "name" and I find it pretty useful.
I am very slow - please spell it out for me.
Well this won't work (no labels shown, nor ref included into display name): highway=* & ref=* {set display_name='${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}' | '${name}'} If however I only do this then both Mapsource and my etrex will only show ref in routing instructions, instead of "ref name". highway=* & ref=* {name '${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}' | '${name}'} Therefore I need to do the following (so that both label is shown, as well as ref included into routing instructions) highway=* & ref=* {name '${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}' | '${name}'; set display_name='${ref} ${name}'} So I do need to be able to set name and display_name to the same value (and I want to have ref before name, as often name gets cut off on etrex small display).
How does having two labels that are the same apart from the first one having a highway shield prefix behave any differently from just having the first label on its own? I don't understand the benefit.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix, Thanks for the explanation - I was hoping you would write English rather than style language as I understand that about as well as I understand German language! Anyway, I think I have worked out what the issue is. It's because there are trailing labels following and they get shown instead of the display name. I will post a v6 patch tonight that should fix that. Mark
Felix,
Your version 4, disallowed setting display_name and name to the same value.
Actually, display_name isn't really handled specially at all, it's just the same as any other ref but it goes to the head of the ref queue. i.e if you have: name = peach ref = banana;orange display_name = kiwi the labels get output in this order: peach kiwi banana orange
Hi Clinton,
Sure, what's the point in having multiple labels the same (apart from the shield code)?
I suppose "because Felix said so" isn't a good argument is it? ;-)
I think that I have twigged what the issue is - I think what Felix is possibly looking at this situation: name = <shield>carp ref = shark display_name = carp But with my patch the labels output are: <shield>carp shark And so "shark" will be used in the routing instructions when he wants "carp". OK - if that's what the issue is, I am going to change the code to only trash the ref if it's the only ref (and the same as the name sans shields) but if there is multiple refs then none of them will get trashed. I will post a v6 patch tonight Mark
On 22.03.2010 00:19, Mark Burton wrote:
Hi Clinton,
Sure, what's the point in having multiple labels the same (apart from the shield code)?
I suppose "because Felix said so" isn't a good argument is it? ;-)
I think that I have twigged what the issue is - I think what Felix is possibly looking at this situation:
name =<shield>carp ref = shark display_name = carp
But with my patch the labels output are:
<shield>carp shark
And so "shark" will be used in the routing instructions when he wants "carp".
I have name=somestreet ref_from_relation=EV6 I want to have inside map: name=EV6 somestreet and in routing instructions too: EV6 somestreet. Without using display_name in routing instructions I will only see /EV6/ instead of /EV6 somestreet/. Actually I would even prefer to have name for tooltip: EV6 Somestreet Name for Routing instructions: EV6 Somestreet BlaBlub (BlaBlub added later in style-file) Name printed in map: EV6 (meaning only one tooltip not two or three for the same road, currently every label gets its own tooltip). It gets a bit more difficult for me, as I add refs from route relations. It would be nice in future to be able to search for all of the following in address index: name ref ref_from_relation ref name ref_from_relation name name Blablub (Blablub is added during processing the style-file to name)
OK - if that's what the issue is, I am going to change the code to only trash the ref if it's the only ref (and the same as the name sans shields) but if there is multiple refs then none of them will get trashed.
I will post a v6 patch tonight
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
It seems that dipslay_name internally in mkgmap is not allowed to be set to "name". If identical it will not be set at all. Or is this really a Garmin limitation? To me it seems to be rather an mkgmap bug.
I haven't had time to properly think about this. But if you want to give it a try, here's a possible, but completely untested solution: Change the lines from my previous e-mail in Subdivision.java to the following: if(trSansGC.length() > 0 && (!trSansGC.equalsIgnoreCase(nameSansGC) || !r.equalsIgnoreCase(name))) { //System.err.println("Adding ref " + tr + " to road " + name); pl.addRefLabel(lblFile.newLabel(tr)); } and it might work. Then again, it might not. ;-) Cheers.
participants (3)
-
Clinton Gladstone -
Felix Hartmann -
Mark Burton