Matching tags which did not match a previous rule?

[papab]

Example:
   

Code: [Select]

<rule e="way" k="surface" v="smooth_paved">
<line stroke="#AAAAAA" stroke-width="0.9" stroke-dasharray="2,2" stroke-linecap="butt" />Then have a rule for a surface which is anything else but smooth_paved?

something like v=~"smooth_paved"

[karlchick]

I think the only way is to have a rule that matches all the alternative values of surface.
Karl.

[john_percy]

Something like the following was supposed to work at one stage but I'm not sure it is correct or bug free:

Code: [Select]

<rule e="way" k="surface" v="smooth_paved">
<line stroke="#AAAAAA" stroke-width="0.9" stroke-dasharray="2,2" stroke-linecap="butt" />
</rule>
<rule e="way" k="surface" v="*|~">
<!-- value matches everything *else* or nothing -->
....I know that is pretty non-standard!

[papab]

I think the only way is to have a rule that matches all the alternative values of surface.
Karl.

The problem with this is that a due to the anarchic nature of OSM, all the values of surface are not known are they?

[papab]

Something like the following was supposed to work at one stage but I'm not sure it is correct or bug free:

Code: [Select]

<rule e="way" k="surface" v="smooth_paved">
<line stroke="#AAAAAA" stroke-width="0.9" stroke-dasharray="2,2" stroke-linecap="butt" />
</rule>
<rule e="way" k="surface" v="*|~">
<!-- value matches everything *else* or nothing -->
....I know that is pretty non-standard!

Maybe I'm missing something.  For a smooth_paved road, your example will match both rules, won't it?

[john_percy]

You would think so, but the Mapsforge interpreter used that illogical and non standard way to pick up everything not included in the previous match.
It's not the only illogicality in the matching. If you match on k="a|b" then nest a match on k="a" it will also match on k="b" as the results of the previous match are cached as it were.
I don't guarantee it still works like that.

Sent from my moto g(6) plus using Tapatalk

[poutnikl]

I must admit I have never met surface=smooth_paved yet.
I would rather expect surface=paved|asphalt  and smoothness=excellent|very_good|good

To use your terms, surface=smooth_paved seems to me like an anarchic tagging :-)

Most routers, definitely all BRouter profiles I am aware of, would consider it as unpaved, as the tagvalue smooth_paved is not among listed paved values they use to determine pavedness.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[john_percy]

I think the only way is to have a rule that matches all the alternative values of surface.
Karl.

The problem with this is that a due to the anarchic nature of OSM, all the values of surface are not known are they?

However not all the anarchic tags make their way into the final map. OAM for example has a list of which tags and values are processed into their maps.

Sent from my moto g(6) plus using Tapatalk

[john_percy]

I must admit I have never met surface=smooth_paved yet.
I would rather expect surface=paved|asphalt  and smoothness=excellent|very_good|good

To use your terms, surface=smooth_paved seems to me like an anarchic tagging :-)

Most routers, definitely all BRouter profiles I am aware of, would consider it as unpaved, as the tagvalue smooth_paved is not among listed paved values they use to determine pavedness.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

OAM processes surface="smooth_paved"
See https://www.openandromaps.org/wp-content/snippets/makes/tagmapping-min.xml


Sent from my moto g(6) plus using Tapatalk

[poutnikl]

Hmm, https://taginfo.openstreetmap.org/keys/surface  counts say
 surface=asphalt cca13000000 as the most common,
surface=smooth_paved 1, by the word one.

Rare and unusual tag values give IMHO more troubles than gain.

Specifically BRouter codes in its rd5 files just the most significant down to reasonable threshold to keep reasonable data size.
Edit: Not enumerated tagvalues are covered in profiles by logical branching SWITCH or IF THEN ELSE.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk

[john_percy]

@poutnikl Thanks for that info!

Sent from my moto g(6) plus using Tapatalk

[papab]

Thanks John for the illogical tip, I'll try it.
Yes, my example came about because I'm using an OAM .map file, and it tag-transorms many surface tags into smooth_paved.   It doesn't look like the tag-transform has a way to pick up the stray tags either.

I've been using mkgmap for a couple of years and it handles this stuff much better.   You can process a way, and if it matches it doesn't execute they following code, so if it doesn't match anything you can catch everything left with a wildcard.

[poutnikl]

Ah, I see, so OAM transforms some OSM tag=tagvalues into its own tag=tagvalues, that are not present in OSM, similarly  like BRouter creates its own way context route tags from OSM route relations.

It has confused me.

Sent from my Xiaomi MI A2 / Android 10, via Tapatalk