[PATCH v4] - Code around highway shield crap when sorting labels
v4 - found the motorways (and a load of other roads too!) -------- v3 - now works harder to clean up road names for use in MDR file - not sure if this will have a beneficial effect but it could possibly fix the issue recently reported by Felix. Motorways are still not showing up. ------- v2 - remove more duplicate labels that only differ in letter case - remove leading spaces from labels even if they start with a Garmin code. Still something wrong with motorway names because on the UK map, only the M74 appears in the mapsource road names - all other motorways are missing - very odd. ------- This patch codes around the problems introduced by highway shields with regard to the sorted roads: 1 - the sort order should now be much improved 2 - no duplicate symbols (shield version + non-shield version) It also includes a fix to the label reading code so that labels with a highway shield prefix are read in correctly when generating the MDR file. For me, in mapsource, road search for roads with highway shields now works apart from motorways which don't seem to searchable - perhaps that's deliberate on Garmin's part? All feedback appreciated. Mark
On Mar 18, 2010, at 23:38, Mark Burton wrote:
v4 - found the motorways (and a load of other roads too!)
This version seems to work quite well. I can now locate roads, using the address search, which I could never find before (even with v3 of this patch). I'll test more thoroughly, but it looks good so far. Thanks!
On 20.03.2010 12:53, Clinton Gladstone wrote:
On Mar 18, 2010, at 23:38, Mark Burton wrote:
v4 - found the motorways (and a load of other roads too!)
This version seems to work quite well. I can now locate roads, using the address search, which I could never find before (even with v3 of this patch).
I'll test more thoroughly, but it looks good so far.
Thanks!
To me it looks good so far as well. (still of course only being able to search for addresses in active tile on GPS, and Mapsource 6.16.02 refusing to send map to GPS with registered address search).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
okay searching for roads works very well now. However the ENQ problem is not solved for me. Using: /set ref = '${ref}'/ inside relations file for relations that have a ref (like EV6) and then /{ set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'}/ inside lines file, causes mkgmap to create these havoc names. If read with mapedit name looks like this: ~[0x2f]EV6 ~[0x2e]EV6 DONAURADWEG inside Mapsource it looks like this: EV6 | EV6 DONAURADWEG Clearly mkgmap has some problem here. There is nowhere at all where I ask [0x2f] or [0x2e] to be included into the name. Furthermore is neither 0x2f nor 0x2e the type of the road.
Felix,
okay searching for roads works very well now.
Good.
However the ENQ problem is not solved for me. Using: /set ref = '${ref}'/ inside relations file for relations that have a ref (like EV6) and then /{ set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'}/ inside lines file, causes mkgmap to create these havoc names.
Sorry, once again, I am nonplussed by the style syntax, what does the 6:4 mean in the above?
If read with mapedit name looks like this: ~[0x2f]EV6 ~[0x2e]EV6 DONAURADWEG inside Mapsource it looks like this: EV6 | EV6 DONAURADWEG
Clearly mkgmap has some problem here. There is nowhere at all where I ask [0x2f] or [0x2e] to be included into the name. Furthermore is neither 0x2f nor 0x2e the type of the road.
Well, the 0x2f and 0x2e are the 6-bit encodings of the Oval and Box shields so at least one of those matches what your doing above but I can't see how the Oval code is getting in there. Do you have some other rule that adds an Oval shield? So I wonder if the problem is that your ending up with a highway shield code embedded in the name rather than being a prefix. Perhaps, it can only cope with prefix shields. Mark
On 21.03.2010 10:32, Mark Burton wrote:
Felix,
okay searching for roads works very well now.
Good.
However the ENQ problem is not solved for me. Using: /set ref = '${ref}'/ inside relations file for relations that have a ref (like EV6) and then /{ set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'}/ inside lines file, causes mkgmap to create these havoc names.
Sorry, once again, I am nonplussed by the style syntax, what does the 6:4 mean in the above?
This means 6 characters maximum, or 4 non numeric characters maximum if I remember it correctly. Default is 7:5 if I remember correctly.
If read with mapedit name looks like this: ~[0x2f]EV6 ~[0x2e]EV6 DONAURADWEG inside Mapsource it looks like this: EV6 | EV6 DONAURADWEG
Clearly mkgmap has some problem here. There is nowhere at all where I ask [0x2f] or [0x2e] to be included into the name. Furthermore is neither 0x2f nor 0x2e the type of the road.
Well, the 0x2f and 0x2e are the 6-bit encodings of the Oval and Box shields so at least one of those matches what your doing above but I can't see how the Oval code is getting in there. Do you have some other rule that adds an Oval shield?
No, the full rules for the highway shields are as follows (I don't think there is a bug inside on my part): ( extremecarver=mr | route=mtb ) & ref=* { set name='${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}'; add display_name='${name}'} extremecarver5=bike & ref=* & extremecarver!=mr & route!=mtb { set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'} highway=* & ref=* & extremcaver5!=bike & extremecarver!=mr & route!=mtb { set name='${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}'; add display_name='${name}'}
So I wonder if the problem is that your ending up with a highway shield code embedded in the name rather than being a prefix. Perhaps, it can only cope with prefix shields.
I don't understand what you mean with /being a prefix/.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Sorry, once again, I am nonplussed by the style syntax, what does the 6:4 mean in the above?
This means 6 characters maximum, or 4 non numeric characters maximum if I remember it correctly. Default is 7:5 if I remember correctly.
OK - thanks.
Well, the 0x2f and 0x2e are the 6-bit encodings of the Oval and Box shields so at least one of those matches what your doing above but I can't see how the Oval code is getting in there. Do you have some other rule that adds an Oval shield?
No, the full rules for the highway shields are as follows (I don't think there is a bug inside on my part):
( extremecarver=mr | route=mtb ) & ref=* { set name='${ref|hig00002f4b | 01 38 00 | 3 byte stream hway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}'; add display_name='${name}'}
extremecarver5=bike & ref=* & extremecarver!=mr & route!=mtb { set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'}
highway=* & ref=* & extremcaver5!=bike & extremecarver!=mr & route!=mtb { set name='${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}'; add display_name='${name}'}
Yes, you do have another rule that adds an oval shield (the last one above). So what's happening is that two of the rules are matching and you are getting both a box and an oval shield added to the name - and that's badness.
So I wonder if the problem is that your ending up with a highway shield code embedded in the name rather than being a prefix. Perhaps, it can only cope with prefix shields.
I don't understand what you mean with /being a prefix/.
What I mean is that the highway shield code has to prefix (go at the front) of the name and not be embedded within the name string. Mark
BTW - do you think this v4 patch is working well enough to commit now?
Hi Clinton,
BTW - do you think this v4 patch is working well enough to commit now?
yes
Me too! :-)
Good and thanks for the earlier +ve report. Unless anything untoward crops up, I shall commit it later today. Mark
On 21.03.2010 10:52, Mark Burton wrote:
Felix,
Sorry, once again, I am nonplussed by the style syntax, what does the 6:4 mean in the above?
This means 6 characters maximum, or 4 non numeric characters maximum if I remember it correctly. Default is 7:5 if I remember correctly.
OK - thanks.
Well, the 0x2f and 0x2e are the 6-bit encodings of the Oval and Box shields so at least one of those matches what your doing above but I can't see how the Oval code is getting in there. Do you have some other rule that adds an Oval shield?
No, the full rules for the highway shields are as follows (I don't think there is a bug inside on my part):
( extremecarver=mr | route=mtb )& ref=* { set name='${ref|hig00002f4b | 01 38 00 | 3 byte stream
hway-symbol:hbox:6:4} ${name}' |
'${ref|highway-symbol:hbox:6:4}'; add display_name='${name}'}
extremecarver5=bike& ref=*& extremecarver!=mr& route!=mtb { set name='${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}'; add display_name='${name}'}
highway=*& ref=*& extremcaver5!=bike& extremecarver!=mr& route!=mtb { set name='${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}'; add display_name='${name}'}
Yes, you do have another rule that adds an oval shield (the last one above). So what's happening is that two of the rules are matching and you are getting both a box and an oval shield added to the name - and that's badness.
Well that has not been the problem. I rather think that "set name" does not work for highway shields. I now changed the lines to: ( extremecarver=mr | route=mtb ) & ref=* {name '${ref|highway-symbol:hbox:6:4} ${name}' | '${ref|highway-symbol:hbox:6:4}' | '${name}'; add display_name='${name}'} ( extremecarver5=bike & ref=* ) & extremecarver!=mr & route!=mtb {name '${ref|highway-symbol:box:6:4} ${name}' | '${ref|highway-symbol:box:6:4}' | '${name}'; add display_name='${name}'} highway=* & ref=* & extremcaver5!=bike & extremecarver!=mr & route!=mtb {name '${ref|highway-symbol:oval:6:4} ${name}' | '${ref|highway-symbol:oval:6:4}' | '${name}'; add display_name='${name}'} Which works very well - even though the result should in theory be identical.
So I wonder if the problem is that your ending up with a highway shield code embedded in the name rather than being a prefix. Perhaps, it can only cope with prefix shields.
I don't understand what you mean with /being a prefix/.
What I mean is that the highway shield code has to prefix (go at the front) of the name and not be embedded within the name string.
Okay, now I understand. However the highway shield always prefixed the name. I do know that it is not possible to add the ref to the end of the name if displaying highway-shields. (except for display_name)
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Clinton Gladstone -
Felix Hartmann -
Mark Burton