Location not working in trunk default style
Hi I discovered that the location tags (mkgmap:city and so on) are not working in the default style and the reason involves the way that base-style works. It prepends the rules in the current style before the rules in the base style. This allows rules in the current style to override rules in the base-style as you would expect. However, if you have an action-only rule then it will never be seen if a real rule in the current style matches first. So putting all the location actions in a base-style does not work. Solutions? My ideas: First in the particular case of location, address and perhaps access tags I think that they should be separate file(s). The very fact that the same rules are repeated in lines, points and polygons, strongly indicates that they should be separated. They could be placed in one file, which would be used by each of the different geometry types. Second, perhaps there is a need for two commands include-before and include-after which allow you to do the inclusion either way as appropriate for the situation. ..Steve
On Fri, Nov 25, 2011 at 07:12:51PM +0000, Steve Ratcliffe wrote:
First in the particular case of location, address and perhaps access tags I think that they should be separate file(s). The very fact that the same rules are repeated in lines, points and polygons, strongly indicates that they should be separated. They could be placed in one file, which would be used by each of the different geometry types.
I agree, one file for these should be enough. I did not quite follow you regarding access tags. They do not matter for polygons, do they? For points, they can matter with link-pois-to-ways, which implements access restrictions based on nearby nodes that carry access tags.
Second, perhaps there is a need for two commands include-before and include-after which allow you to do the inclusion either way as appropriate for the situation.
Could we have something similar to the #include and #undef in the C preprocessor? For #undef (or whatever it will be called), an example would be a style that is derived from the default style but removes the lines rules for power=line and man_made=*. Last, given the current breakage in trunk (sorry, I failed to notice it), I guess that we should we have a separate branch for refactoring the default style and the substyle handling. Best regards, Marko
Hi
indicates that they should be separated. They could be placed in one file, which would be used by each of the different geometry types.
I agree, one file for these should be enough. I did not quite follow you regarding access tags. They do not matter for polygons, do they? For points, they can matter with link-pois-to-ways, which implements access restrictions based on nearby nodes that carry access tags.
I put them all together, because they all apply across a range of object types and modify the properties of the object rather than selecting what kind of object it is.
Second, perhaps there is a need for two commands include-before and include-after which allow you to do the inclusion either way as appropriate for the situation.
Could we have something similar to the #include and #undef in the C preprocessor? For #undef (or whatever it will be called), an example would be a style that is derived from the default style but removes the lines rules for power=line and man_made=*.
Removing rules would be tricky with the current implementation. Inclusion would be possible - do you mean randomly named files from the current style? ..Steve
Am Sonntag 27 November 2011, 15:34:31 schrieb Steve Ratcliffe:
Hi
indicates that they should be separated. They could be placed in one file, which would be used by each of the different geometry types.
I agree, one file for these should be enough. I did not quite follow you regarding access tags. They do not matter for polygons, do they? For points, they can matter with link-pois-to-ways, which implements access restrictions based on nearby nodes that carry access tags.
I put them all together, because they all apply across a range of object types and modify the properties of the object rather than selecting what kind of object it is.
Second, perhaps there is a need for two commands include-before and include-after which allow you to do the inclusion either way as appropriate for the situation.
Could we have something similar to the #include and #undef in the C preprocessor? For #undef (or whatever it will be called), an example would be a style that is derived from the default style but removes the lines rules for power=line and man_made=*.
Removing rules would be tricky with the current implementation. Inclusion would be possible - do you mean randomly named files from the current style?
..Steve
IMO a #include statement that behaves like in C/C++ or even better like the source statement within a shell script would be sufficient and much better than the current base-style technique. The statement should be allowed at any position within a stylefile and 'sources' the stated file line by line exactly at that position. At the moment i archive this by generating the styles with some cat commands before any mkgmap call. Preventing double inclusion of a file is not so important for me, cause it may or may not make sense including the same ruleset twice at different positions within the 'final' ruleset. Specifying the files to include platformindependent with relative and absolute paths or relative to the 'default style' paths would be helpful. Examples: source "../mystyletemplates/locatorrules.txt" #include <default/locator.rules> #def and #undef is IMO not so useful at all, cause you allways are able to prevent the execution of a rule by catching the element within another rule given before the rule you want to 'undef'. Allowing an empty element type definition or a keyword 'next' or 'abort_element' comparable to the awk script 'next' statement would help much more keeping the style files simple and readable. Example: highway=residential & mynamespace:not_usable=yes [ next ] or highway=residential & mynamespace:not_usable=yes [ next ] or highway=residential & mynamespace:not_usable=yes {abort} would prevent any further processing of the elements matching the condition. If this is already implemented please let me know, did not see it within the examples or the documentation. Regards Hasemann
On Mon, Nov 28, 2011 at 12:45:30AM +0100, Olaf Hasemann wrote:
#def and #undef is IMO not so useful at all, cause you allways are able to prevent the execution of a rule by catching the element within another rule given before the rule you want to 'undef'.
You are right, the #undef would merely allow the OSM parser to drop uninteresting tags (saving memory). For a relatively rare tag, such as power=line, this should not make much difference. For more widely-used tags, you would probably be better off omitting the include/source/base-style for the tags you are not interested in.
Allowing an empty element type definition or a keyword 'next' or 'abort_element' comparable to the awk script 'next' statement would help much more keeping the style files simple and readable. Example:
highway=residential & mynamespace:not_usable=yes [ next ]
To my knowledge, this has not been implemented. I am not entirely convinced of the usefulness. This should be fairly easy to implement, basically replace the convertNode(), convertWay() calls with a no-op when the keyword is present. The [] stuff is parsed in osmstyle/TypeReader.java. Maybe we could simply have a special flag in GType that tells to omit the conversion in convertWay(), convertNode() and the like? Marko
Hi, On Mon, Nov 28, Olaf Hasemann wrote:
IMO a #include statement that behaves like in C/C++ or even better like the source statement within a shell script would be sufficient and much better than the current base-style technique. The statement should be allowed at any position within a stylefile and 'sources' the stated file line by line exactly at that position. At the moment i archive this by generating the styles with some cat commands before any mkgmap call.
I fully agree. Currently I'm using the cat command, too, but I would prefer the #include statement, too. If I would better understand the mkgmap code now I would have already created a patch ;) Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (4)
-
Marko Mäkelä -
Olaf Hasemann -
Steve Ratcliffe -
Thorsten Kukuk