mergeroads branch - how to set street labels in style files
Hi all, I am thinking about how to simplify setting the four possible labels of streets / POIs. This is what I think how it works: Each street and POI can have four different labels. At the moment the following procedure is used to assign them: All labels are filled with the values of name mkgmap:display_name mkgmap:ref (splitted by ";") This means in detail: 1st label: highway shield for the first reference. Usually the name of the street is added separated with a space. Some Garmins display the whole label shielded, some show only the part until the first whitespace. Some Garmins show this as street name when the street is selected and they show the 2nd when the details of the street are shown (Oregon 400 behaviour). 2nd-4th label: in case mkgmap:display_name is set it is used as second label. The value of mkgmap:ref is splitted by separator ";" and fills the rest of the available labels. In case the 1st label starts with a shield the 2nd label is usually displayed in routing instructions. Street search indexes all four labels. So a street with the following labels: 1st: <shield>L276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276 can be searched via all three labels (except the shield character in the 1st label). =========================== My questions: - Do you think the current behaviour is useful? - @Steve: Would it be possible to index not all labels? Change the upper example to: 1st: <shield>L276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276 4th: Laacher Straße In case the first label starts with a shield and there are at least three labels, then start indexing at the 3rd label. In any case skip the shielded label. This removes all strings with a shield which I think are not useful for address search. I am not sure if that really makes sense but just let us thinking around ... :-) - Should we change the usage of the labels to the following algorithm: Use: name mkgmap:display_name mkgmap:streetname mkgmap:ref (splitted by ";") Only add labels if they don't equal the labels before. So if mkgmap:streetname is the same like the name of the street it will not be used as label. I am happy to hear about your opinions and ideas! Have fun! WanMil
Hi WanMil
Street search indexes all four labels. So a street with the following labels: 1st: <shield>L276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276
In a Garmin map this would be just 1st: <shield>L276 2nd: Laacher Straße The third and fourth positions would be for alternate names. I do not see the need to repeat the name and the ref so many times. Having the ref in brackets after the name comes from the time before we had NET and more than one possible name. Perhaps the other entries were useful before we had the real index as well. With the index both the name and the ref are searchable with just those two name entries. ..Steve
Am 12.10.2013 00:00, schrieb Steve Ratcliffe:
1st: <shield>L276 2nd: Laacher Straße
The third and fourth positions would be for alternate names.
So we would need something like: mkgmap:ref -> 1st mkgmap:name -> 2nd mkgmap:name_1 -> 3rd mkgmap:name_2 -> 4th Everything else should be done in style-file. What about the case if one tag is missing? Eg. mkgmap:ref = <empty>. Should then the 1st one stay empty as well or should this field filled with mkgmap:name? If there are no issues with Garmin, I would prefer let the missing ones stay empty. So it's quite clear and constant which tag is associated with which field. Henning
Hi, I think only first label is visible on map and used for driving instructions. The only manifestations of other labels that I have noticed is in address search. These are my experiences form cgpsmapper, but I assume that street labels in mkgmap are the same. In my opinion first label should be set to "name", others should be available to use in style but empty by default. I have found that the sequence "<shield>ref name" looks bad in many devices and I prefer to avoid it. I set first label to street name and second to reference number, if both value are present. This way I can see street names in a city. I use other labels for alternative names. I'd like ref to be searchable, I understand that only shield mark is removed and reference number is used for indexing. -- Best regards, Andrzej
On 12/10/13 08:05, Henning Scholland wrote:
tag is missing? Eg. mkgmap:ref = <empty>. Should then the 1st one stay empty as well or should this field filled with mkgmap:name?
Yes if there is no ref then the plain name would be the first entry in the map file and any other entries would be moved up.
If there are no issues with Garmin, I would prefer let the missing ones stay empty. So it's quite clear and constant which tag is associated with which field.
Yes, it would probably be best to have the mkgmap entries empty, rather than loads of logic to shuffle them around. I think however that empty ones would have to be dropped when written to the file. ..Steve
On 12/10/13 08:05, Henning Scholland wrote:
tag is missing? Eg. mkgmap:ref = <empty>. Should then the 1st one stay empty as well or should this field filled with mkgmap:name?
Yes if there is no ref then the plain name would be the first entry in the map file and any other entries would be moved up.
If there are no issues with Garmin, I would prefer let the missing ones stay empty. So it's quite clear and constant which tag is associated with which field.
Yes, it would probably be best to have the mkgmap entries empty, rather than loads of logic to shuffle them around. I think however that empty ones would have to be dropped when written to the file.
..Steve
So the order to set the labels might be: mkgmap:ref mkgmap:name mkgmap:name:1 mkgmap:name:2 mkgmap:name:3 ... The first four of the tags that are set are used. I think the following behaviour makes sense: If mkgmap:name is not set then the name tag is used? The name action adds the mkgmap:name tag instead of settings the name in the java element? I wonder if it is easier for style devs to set one mkgmap:addname separated with ";" instead of setting mkgmap:name:1..n? WanMil
-----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-----
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@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
Hi, we talk about 4 labels, but shouldn't we set whole address for each label? Cgpsmapper accept 3 labels but for 2 of them you can set different city, region or country. This is usable, because quite often there are streets at 2 cities border, which not only have 2 names, but belong to 2 different regions. I'm not sure how OSM deals with multiple names, but you could at least add support for mp format and prepare tools in style. BTW, do you know, that cgpsmapper source is for sell? http://cgpsmapper.com/buy.htm -- Best regards, Andrzej
On 17.10.2013 12:33, Andrzej Popowski wrote:
BTW, do you know, that cgpsmapper source is for sell? http://cgpsmapper.com/buy.htm
Is there still a need for it? Conditions state: "you can buy all the source code, with no limit for use." so that includes open publication? If there is a need, I would be willing to pay 300€ in a shared buy (just need to get some receipt saying that I paid 300€ in part to buy the source code and that the amount includes VAT). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
I do not see the need to repeat the name and the ref so many times. Having the ref in brackets after the name comes from the time before we had NET and more than one possible name. Perhaps the other entries were useful before we had the real index as well.
I have tried a map with Garmin style (1st=<shield>ref 2nd=name). This has the disadvantage that the ref is displayed on the map but not used in the routing instructions. Only the street name is given as routing instruction (tested on Oregon 400 and Nüvi 1490). WanMil
On 12/10/13 15:07, WanMil wrote:
I have tried a map with Garmin style (1st=<shield>ref 2nd=name). This has the disadvantage that the ref is displayed on the map but not used in the routing instructions. Only the street name is given as routing instruction (tested on Oregon 400 and Nüvi 1490).
Sure, but that would be how official Garmin maps work too, unless we are missing a trick. Anyway, it seems reasonable to keep 2nd='name (ref)'; I just wanted to present the opposite extreme. Cheers, ..Steve
On 12/10/13 15:07, WanMil wrote:
I have tried a map with Garmin style (1st=<shield>ref 2nd=name). This has the disadvantage that the ref is displayed on the map but not used in the routing instructions. Only the street name is given as routing instruction (tested on Oregon 400 and Nüvi 1490).
Sure, but that would be how official Garmin maps work too, unless we are missing a trick.
Anyway, it seems reasonable to keep 2nd='name (ref)'; I just wanted to present the opposite extreme.
It's quite interesting, how Garmin maps look like. In the end anybody can implement an own style, so it's just a minor discussion how to set the name in the default style. I observed that there are more shield characters apart from the ref symbols. Do you know their functions? GPSMapEdit tells me that they hide some parts. Maybe they are useful for our purpose? WanMil
Cheers, ..Steve
On 18/10/13 20:41, WanMil wrote:
I observed that there are more shield characters apart from the ref symbols. Do you know their functions? GPSMapEdit tells me that they hide some parts. Maybe they are useful for our purpose?
There are characters that can be used to separate parts of a name so that the following or preceding parts of the name are hidden at particular zooms to save space. Eg. N[0x1e]Green[0x1f]Street would display N Green Street or just Green. Then there are non-spacing versions and characters for force upper or lower case of the following character. ..Steve
Hi Felix, off-topic, but interesting ;)
Is there still a need for it?
There are some features in cgpsmapper, still not available in mkgmap, but I think nothing really important. The main advantage of cgpsmapper is stability, this is commercial grade compiler.
Conditions state: "you can buy all the source code, with no limit for use." so that includes open publication?
I was thinking about it too. What I wouldn't like is to publish code dealing with locking maps. While it is not difficult to revers engineer it, direct available source code would be quite problematic for publishers, which still use cgpsmapper for commercial products. This would include some of my work too.
If there is a need, I would be willing to pay 300€ in a shared buy
I'm considering participation too, if there would be a reasonable way of shared buy. But I'm not sure if this code has a future. Mkgmap seems to have great support and potential for future development, could cgpsmapper compete there? Still would be nice to release current version of full featured cgpsmapper for free. -- Best regards, Andrzej
I didn't think about cgpsmapper as a program. To me at least it has no interest. My thinking was, I will participate if it helps improving mkgmap, or debugging mkgmap, and maybe improve autorouting? Also I think it only makes sense to buy, if the source code afterwards really can be openly published (maybe take out the locking part, even though I think that part is already pretty much floaring around the net, I can remember that cgpsmapper locking mechanism and how it works was already published in some places some time ago). I don't think there is any use for cpgsmapper as a compiler anymore (except maybe compare output of mkgmap and cgpsmapper for the same input material). On 17.10.2013 13:57, Andrzej Popowski wrote:
Hi Felix,
off-topic, but interesting ;)
Is there still a need for it?
There are some features in cgpsmapper, still not available in mkgmap, but I think nothing really important. The main advantage of cgpsmapper is stability, this is commercial grade compiler.
Conditions state: "you can buy all the source code, with no limit for use." so that includes open publication?
I was thinking about it too.
What I wouldn't like is to publish code dealing with locking maps. While it is not difficult to revers engineer it, direct available source code would be quite problematic for publishers, which still use cgpsmapper for commercial products. This would include some of my work too.
If there is a need, I would be willing to pay 300€ in a shared buy
I'm considering participation too, if there would be a reasonable way of shared buy.
But I'm not sure if this code has a future. Mkgmap seems to have great support and potential for future development, could cgpsmapper compete there?
Still would be nice to release current version of full featured cgpsmapper for free.
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
participants (5)
-
Andrzej Popowski -
Felix Hartmann -
Henning Scholland -
Steve Ratcliffe -
WanMil