[Tagging] layer=-1, rivers, bridges and tunnels

Richard Z. ricoz.osm at gmail.com
Fri Mar 14 20:12:19 UTC 2014

On Fri, Mar 14, 2014 at 03:55:39PM -0300, Fernando Trebien wrote:
> I don't think you should be required to check the river's layer tag.
> Validators should do this job for you, it's quite easy to write a rule
> for that.

validators can check for many errors but if you want to change
anything you have to understand the whole situation. 
Imagine you want to add a new bridge to a complex freeway intersection
with junctions and overpasses.. the validator will only prevent the
most obvious errors but will give you no clue how to fix them
> Given two ways that cross internally (excluding connections at
> endpoints), and considering the "layer value" defined explicitly in a
> tag or implicitly 0 when the tag is missing, have the validator issue
> a warning in the following situations:

there is no difference between connections in endpoints or in a crossing 
point as far as I can tell.

> 1. The ways have the same layer value and are unconnected. (They
> should be connected, or else something is surely missing. This could
> actually be considered an "error".)

except for aerial ways and similar exceptions

> 1.1. Also warn if if one way is a waterway and the other is a highway
> and the connection is not explicitly a ford. (It should be, for
> clarity. If it's not, it's also possibly not a ford, therefore the
> connection is wrong.)

there is also the odd case of highways across dams, those are connected
with the waterway

> 2. The ways have different layer values and both are missing a tunnel
> or a bridge tag. (One of them must be either a bridge or a tunnel.
> They can both be tunnels or bridges, but they can't be "none of those
> two" simultaneously in the real world.)

or one of covered,location,indoor,steps,lift or level, maybe more.

> 2.1. Additionally, if one of them is a bridge and the other is a
> tunnel or is neither a tunnel nor a bridge: the bridge should have a
> greater layer value.
> 2.2. Similarly, if one is a tunnel, its layer value should be lower if
> the other is a bridge or has neither tag.

except for indoor mapping and maybe other weird cases.

> These rules apply to any arbitrary combination of stacked waterways
> and highways that I can think of right now. 

also railways?

>  A few examples using two
> overlapping ways:
> a. The ways are connected and do not have a layer tag: everything is
> ok, no rules issue a warning.
> b. The ways are not connected and do not have a layer tag: rule 1
> issues a warning. They must either be connected or lie at different
> layer levels.
> c. The ways are not connected, both have the same layer (say layer=3
> or layer=-4), and have no other tags: rule 1 issues a warning. Similar
> to situation "b".
> d. The ways are not connected and one of them has a layer=-1 tag and
> no other tags: rule 2 issues a warning.

more general: not connected, different layer values and not one of
bridge,tunnel,covered,location,indoor,steps,lift, no level tag and 
a few more things to take into account.

I am not sure it is so easy to catch all that.

> e. The ways are not connected and one of them has a layer=1 tag and no
> other tags: rule 2 issues a warning too.

identical to d?

> f. The ways are not connected, one of them is a bridge with layer=2
> and the other is a tunnel with layer=5: rule 2.1 issues a warning.

unless indoor or other strange cases

> g. The ways are not connected, one of them is a tunnel with layer=1
> and the other is neither a bridge nor has a layer tag (layer=0 is
> assumed): rule 2.2 issues a warning.

> Actually, situation "d" is what would discourage people from using
> layer=-1 to work around today's validator warnings. With this ruleset,
> it's impossible to eliminate the warning without actually taking
> action on bridges.

It is a lot easier saying that every bridge and tunnel must have a layer 
tag and enforce that than catching all the situations mentioned in 
situation "d".

With some luck, you can restrict "d" to waterways and it becomes "easy"


More information about the Tagging mailing list