value (string) handling via style file
Moin, I want to do some modifications of the tag-values via the style file. I know this has been a topic here before, but I can not find the neccessary hints right know. - How can I check the first character of the value in a style file? (I want to detect whether the first character is a minus sign "-".) - How can I check the last character of the value in a style file? (incline allows either "%" or "°") - How can I remove the first character of the value in a style file? ("-5%" -> "5%") - How can I check, whether a character is numeric? (in [0..9]) Can anybody help me? Gruss Torsten PS: The definition of the incline tag is really a nightmare for automated evaluation.
On Thu, Nov 03, 2011 at 05:31:04PM +0100, Torsten Leistikow wrote:
- How can I check the first character of the value in a style file? (I want to detect whether the first character is a minus sign "-".)
- How can I check the last character of the value in a style file? (incline allows either "%" or "°")
You need the ~ (regexp match) operator for this. I am not sure if the mkgmap regexps have an implicit match-at-start ^ at front and match-at-end $ at end. If they do, then you can do this: incline ~ '-.*' incline ~ '.*(%|°)' If not, these should work: incline ~ '^-.*' incline ~ '.*(%|°)$' You can of course combine these two: incline ~ '^-.*(%|°)' this should match only negative inclines that end in % or °
How can I remove the first character of the value in a style file? ("-5%" -> "5%")
Sorry, this I do not know. There is a substring filter, which might do the trick here (when you only want to remove a fixed number of characters at the front). It works something like this: { name '${incline|substr:1}' } (I am not sure about the exact syntax)
- How can I check, whether a character is numeric? (in [0..9])
incline ~ '^-?[1-9][0-9]*(%|°)$' should match anything that optionally starts with -, is followed by a digit 1 to 9 and then by any number (including zero) of digits 0 to 9, and finally ending in % or °. I hope that this helps. Marko
Moin, Marko Mäkelä schrieb am 03.11.2011 19:37:
I hope that this helps.
Thanks, with your help I was at least able to filter out the non-numeric values by using incline ~ '^-?[0-9]*.' instead of inlcine=* I did not succeed in removing the minus sign from the out put (since the direction of the ways is not visible in my map, there is no point in having the sign when using the grade of the incline as a label). So I would be glad, if anybody knows, how to use the substring filter. Gruss Torsten
Marko, Is it possible to use wildcards in key tags (like key:*=value or *key*=value) with regular expression? It can be useful with key tags like oneway:*=yes (with * = bicycle, cycleway etc) or cycleway:*= or more complicated *:cycleway:* or any kind of vehicle key tags like bicycle:* or maybe name:* (to cover items with name: on an object if name is unset) http://taginfo.openstreetmap.org/search?q=bicycle%3A#keys http://taginfo.openstreetmap.org/search?q=cycleway%3A#keys http://taginfo.openstreetmap.org/search?q=oneway#keys http://taginfo.openstreetmap.org/search?q=name%3A#keys
On Fri, Nov 04, 2011 at 05:19:07PM +0100, Minko wrote:
Is it possible to use wildcards in key tags (like key:*=value or *key*=value) with regular expression?
Side note: that looks like a shell glob pattern, not a regular expression. Currently, I don't think so. As far as I understand, the style rule matcher and even the OSM data parser want to see a complete list of keys in advance, so that irrelevant tags can be dropped quickly.
It can be useful with key tags like oneway:*=yes (with * = bicycle, cycleway etc) or cycleway:*= or more complicated *:cycleway:* or any kind of vehicle key tags like bicycle:* or maybe name:* (to cover items with name: on an object if name is unset)
Technically, the parser's tag-list could be extended or replaced with a tag-regexp. The parser would drop all non-matching keys based on a regexp match instead of based on a tag-list lookup. But, I am not sure how this could be implemented in the style rule matcher. Steve is the expert there. I guess that this should be reasonable, provided that the rules do contain some constant keys as well. If you had a hypotethical rule cycleway:.* ~~ .* { echo } then it would have to be checked against every object in the input, which is probably way too expensive. Best regards, Marko
participants (3)
-
Marko Mäkelä -
Minko -
Torsten Leistikow