Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
On 12/10/13 15:07, WanMil wrote: I have tried a map with Garmin style (1st=shieldref 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
Am 12.10.2013 00:00, schrieb Steve Ratcliffe: 1st: shieldL276 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 shieldref 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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=shieldref 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
-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
Re: [mkgmap-dev] mergeroads branch - how to set street labels in style files
Hi WanMil Street search indexes all four labels. So a street with the following labels: 1st: shieldL276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276 In a Garmin map this would be just 1st: shieldL276 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
