[mkgmap-dev] Possible problem with global search index since r3875

Mon Apr 10 08:33:58 BST 2017

Hi all,

I also don't like the current results for roads with a name and a ref. For the mentioned rule we get two labels
Label 1 :"13/14 Hauptstrasse" (with highway shield box)
Label 2 : "Hauptstrasse (13;14)"
If --housenumbers is used, we may see a third label if there are numbers:
Label 3 : "Hauptstrasse"

If I got that right the highway shield code only makes sense on label 1 and we have Java code in Subdivision.createLine() 
which seems to make sure that we don't add duplicate ref labels if they only differ by the highway shield code. 
So I came up with the attached patch for the default style. 

Please comment!
Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve at parabola.me.uk>
Gesendet: Sonntag, 9. April 2017 11:23:38
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Possible problem with global search index since r3875

Hi

> The rule that produces the label "13/14 Hauptstrasse"  (start is highway shield code) is this:
> highway=primary {name '${ref|highway-symbol:box} ${name}' | '${ref|highway-symbol:box}' | '${name}'; addlabel '${name} (${ref})' }

This may be unpopular but we should stop doing this.  This was needed
before we could have multiple labels, but that was a long time ago.

The Garmin way to do this is that the name is the first label, then
any refs or alternate names.

So this case would ideally be represented as:

   Label 1: Hauptstrasse
   Label 2: 13
   Label 3: 14

..Steve
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refs.patch
Type: application/octet-stream
Size: 1648 bytes
Desc: refs.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170410/a83ff9ad/attachment.obj>