Hi all, attached is a patch that removes the incomplete support for the name-tag-list parameter in the style options file. Please make sure that you specify this parameter on the command line or with a config file given in the -c option. If mkgmap finds the name-tag-list parameter in the style options file, it will print a warning to stderr. If I here no complains, I will commit this next monday. The compiled binary is here: http://files.mkgmap.org.uk/download/114/mkgmap.jar Ciao, Gerd
Hi, is this option in general necessary? I think it could be quiet simple be solved in style-file. name:en=* { set foobar:name='${name:en}' } int_name=* & foobar:name!=* { set foobar:name='${int_name}' } foobar:name=* {set name='${foobar:name}' ; delete foobar:name } would be equal to: name-tag-list=name_en,int_name,name The advantage of handing in style is, that you are much more flexible. E.g. use '${name} - ${name:en}' if you want to. I don't know if this is useful. Henning
Hi Henning, I think it is needed. The values are e.g. used in the LocationHook, which is executed before the style rules. Gerd Henning Scholland wrote
Hi, is this option in general necessary? I think it could be quiet simple be solved in style-file.
name:en=* { set foobar:name='${name:en}' } int_name=* & foobar:name!=* { set foobar:name='${int_name}' } foobar:name=* {set name='${foobar:name}' ; delete foobar:name }
would be equal to: name-tag-list=name_en,int_name,name
The advantage of handing in style is, that you are much more flexible. E.g. use '${name} - ${name:en}' if you want to. I don't know if this is useful.
Henning
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/name-tag-list-v1-patch-tp5758153p5758192.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 23.04.2013 14:28, schrieb GerdP:
Hi Henning,
I think it is needed. The values are e.g. used in the LocationHook, which is executed before the style rules. Ok, sounds logical.
Maybe a filter-style-file would be a great solution for all such problems (also for process-destination). This could work like: *Hook wants to know the value of tag "name", mkgmap takes a look in this filter-style-file and return the needed value. If we stay by my example in the mail before, the filter returns "name:en", if there is a "name" and a "name:en" to the *Hook. Henning
Hi Henning, this would not solve the problem that I have: Some routines need (?) the value before the style is read, and some of them work also without any style. This problem is only in the architecture of the classes. Besides that I think that it is a good idea to pass the value as a command line arg. A person in Germany and a person in Italy might want to use the same style, but with different name preferences. I think that the reason for this parm, isn't it? Ciao, Gerd Henning Scholland wrote
Am 23.04.2013 14:28, schrieb GerdP:
Hi Henning,
I think it is needed. The values are e.g. used in the LocationHook, which is executed before the style rules. Ok, sounds logical.
Maybe a filter-style-file would be a great solution for all such problems (also for process-destination). This could work like: *Hook wants to know the value of tag "name", mkgmap takes a look in this filter-style-file and return the needed value. If we stay by my example in the mail before, the filter returns "name:en", if there is a "name" and a "name:en" to the *Hook.
Henning
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/name-tag-list-v1-patch-tp5758153p5758218.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, my intention was a little bit different. I explain it a little bit more. For example the LocationHook needs a name of the boundary-relation. So actually the data is read and name-tag-list filters data and picks out the correct name-tag. My proposal is, that there is a variable filter in general between osm-data and using the data by mkgmap. If you take may example above: mkgmap read data, detects an object with name=Hallo and name:en=hello, it would be changed to name=hello and name:en=hello Henning
Hi Gerd, my intention was a little bit different. I explain it a little bit more.
For example the LocationHook needs a name of the boundary-relation. So actually the data is read and name-tag-list filters data and picks out the correct name-tag.
My proposal is, that there is a variable filter in general between osm-data and using the data by mkgmap.
If you take may example above: mkgmap read data, detects an object with name=Hallo and name:en=hello, it would be changed to name=hello and name:en=hello
Henning
So you want to replace the name-tag-list with something similar to a style rule? I aggree that using name is somehow ambiguous. It would be better to using mkgmap:name for setting the name. That might be changed. WanMil
Hi, WanMil wrote
So you want to replace the name-tag-list with something similar to a style rule?
I aggree that using name is somehow ambiguous. It would be better to using mkgmap:name for setting the name. That might be changed.
I think a common method to evaluate the name of an OSM object is a good idea. Searching for "name" (including the quotes) in the sources I found various places that search for tags - equal to "name" - containing "name" - ending with ":name" and it's difficult to understand why they all look a little bit different. Some are evaluating the name-tag-list, some are not (and cannot, e.g. the BoundaryElementSaver). I don't know how many different methods we really need. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/name-tag-list-v1-patch-tp5758153p5758392.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (4)
-
Gerd Petermann -
GerdP
-
Henning Scholland -
WanMil