[mkgmap-dev] mergeroads branch - how to set street labels in style files

Wed Oct 16 12:05:52 BST 2013

Could we have an external file that defines how the labels are read in?

I would like to have name, mgkmap:name=1, mkgmap:name2, mkgamp:name=3
to be used. However just having mkgmap:name1 to 4 is also okay (would 
mean the first line of my style is name=* {set mkgmap:name='${name}'}

then replace all calls to name by calling mkgmap:name in the style 
subsequently. Which does make some lines longer. Same would be true for 
ref if you need it. If there is a separate file where you can define 
what is by default read in as the first fields, it would save some space 
and lines.

Otherwise just go for mkgmap:name1 to 4 as not being able to define what 
ends up where, would be rather confusing. So definitely not already hard 
define name:1 with ref, and name:2 with name, as some people may prefer 
maps without using ref. I will have to do some testing, but I think I 
rather not need ref at all. (I much prefer if the search alternatively 
can find "route name", "street name" each on it's own, and alternatively 
"street name (route name)".

Felix
(clearly the current way is not good, I don't know at all the outcome of 
setting, ref, name, whatever).
On 13.10.2013 00:30, Henning Scholland wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I think it's better to have only something like:
>
> mkgmap:name:1
> mkgmap:name:2
> mkgmap:name:3
> mkgmap:name:4
>
> If [..] is processed the string of mkgmap:name:1..4 is written to the
> file. If one tag is empty the next one in order is used. If
> mkgmap:name:4 is processed, all other fields stays empty.
>
> I don't know if it's useful to have an automatism for name-tag because
> this is again a hard coded thing, which we would like to omit.
>
> Maybe an additional style-function addname <string> is an useful
> thing. This function would add the string to the first empty
> mkgmap:name:1..4. If all 4 are not empty nothing will be added.
>
> Henning
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (MingW32)
>
> iQEcBAEBAgAGBQJSWc2OAAoJEPFgsWC7jOeTYYcH/jt+/KlT7zjYGyqHub2TO9We
> 6C3s2VcGMbU3Es8yocJFaUUhCEgKyVh3QUaqvLDHHOSCzD/O4+KtaYMXoNSZsKwX
> /QdkFOXOyWx32zqRPbohfFqghakM169w41v/jpuy/os/dMl36X1PAfPFpp/Hcv6L
> rddkUEJ3zuSqCxo5k7XZYS2miJ77V/j6fDFTuyJpNnhQdE6c3JOdfctYtuiEGc8q
> 3eV/xjw1oojJg6Yb2nvmernx8m5q02yZMIcaPia/ATIv2q+61b3244z1aZbDLSHE
> dTs59PgHym5FqGfP0ElEmIUeduP7UFByyqlrRmLYRBnP+6oTOPl+LJwMs58bPUE=
> =Q9BX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org