"the validator will only prevent the most obvious errors but will give
you no clue how to fix them correctly"
I know. But two or three rounds of trial and error with the validator
should be enough to bring a new user to an acceptable representation.
"there is no difference between connections in endpoints or in a
crossing point as far as I can tell."
You're right. I should have used "overlap" not "cross". That's what I
meant really. If a waterway and a highway cross, that means they share
a common node, so it represents a ford and maybe a dam. If they
overlap but do not cross, they should, in principle, be in different
vertical positions, so they should have a different value in the
"layer" tag.
"or one of covered,location,indoor,steps,lift or level, maybe more."
I have to read more about them an check their usage, but they could
all be incorporated in the same rule in the validator. It's just a few
extra values in a set referred to in a rule. Surely this set can grow
over time.
"except for indoor mapping and maybe other weird cases."
I'm not so much involved with indoor mapping yet, but I think the
rules would still apply. What I know about indoor mapping (possibly
too little): it is being done in such a way that people will first
filter by level and then render. So "layer" probably applies within
"level". If you have two ways that overlap at the same level but do
share a node, they must sit at different layers, right? They must be
vertically displaced, so one of them should be an indoor "tunnel" and
the other should be an indoor "bridge" (or something alike), right?
"also railways?"
As far as I can imagine, it should apply to railways too. Also to
combinations of railways with highways, and railways with waterways.
(If it does not, please show me an example.)
"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 believe you mean that these propositions are joined with "AND"
logic: not connected AND different layer values AND not of
{bridge,tunnel,...} AND no level tag", right?
Different layer values AND not one of {bridge,tunnel,...} will issue a
warning for the way without bridge=* or layer=* that goes underneath
bridge=yes+layer=1, right?
"identical to d?"
Exactly, that's the point I'm trying to state. Layer is a relative
value, its actual values should not be assigned any special meaning.
Layer=0 does not mean ground level, and layer=-1 does not mean
underground nor should be forbidden for rivers (as long as it obeys
the other thumb rule: "use layer only in short ways or short spans of
a way").
"unless indoor or other strange cases"
Correct, let's add "within the same level" to all of those rules, and
assume level=0 when level is not specified in a tag. Then they all
work also for indoor mapping.
"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"."
Yes but it is also much harder to get everyone in the world to follow
it. Even a person that knows that rule may forget to apply it
sometimes. I know that this same reason does not apply to many other
similar situations in which a validation rule would be much more
complex than that.
"With some luck, you can restrict "d" to waterways and it becomes "easy"."
Fair enough, since the current problem mostly concerns waterways. I
just tried to arrive at a more generic rule, which I believed would be
more useful in the long term.
On Fri, Mar 14, 2014 at 5:12 PM, Richard Z. <ricoz....@gmail.com> wrote:
> 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
> correctly.
>
>> 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"
>
> Richard
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
--
Fernando Trebien
+55 (51) 9962-5409
"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
