On Tue, Jan 22, 2019 at 10:18:51PM +0100, Tobias Zwick wrote:
> On 22/01/2019 10:47, Lionel Giard wrote:
> > So, i'm really in favor of the level=* for a "data user friendly" tag
> > (that could correspond to local numbering, but not always) and a special
> > tag for the local levels. At this moment i would see a *local level tag
> > *like "level:ref=*" or "loc_level=*" (like we have for name and loc_name
> > ?) but _*on each object*_, as it would not be realistic to use an
> > outline in the cases i present).
> >
> > PS: i hope my example is not too confusing, or badly explained. :-)
>
> I understand it. (To recap - ) you are giving a real-life example of
> what Roland described: Using the level tag outside of (a single)
> building but in a wider scope.
> To be able to show on indoor maps what is really on the same level on a
> scope that exceeds single buildings, you need to use the level-tag also
> in a scope that exceeds single buildings, making it important that the
> level indices of (neighbouring) buildings match.
>
> So, basically, your example is like a situation where two malls are
> connected by a footbridge, but one mall labels its level there as "UG"
> and the other as "M".[1]
> If the level tag was allowed to be non-numerical and required to always
> follow the building operator's denomination even if they are letters and
> not numbers, the information on what buildings (and non-buildings like
> footbridges, train stops, tunnels etc.) connect to each other is lost.
I think "level" in adjacent buidlings can never be relied upon. In some
cases key:ele would help.
> So, though, this means that (already now), the level tag enjoys somewhat
> of a dual-usage:
> - On the one hand, it should follow the building operator's denomination
> as long as it is numeric, thus, is or comes close to how the level is
> really named "on the ground"
> - On the other hand, in a wider context, it is used similarly to the
> layer tag: An arbitrary ("programmer's") value to arrange a Z-order.
>
> I think this dual usage may come back to bite us.
correct and it is tempting to do it so. If and when it bites us I think we
will find "rescues".
> Second, why can not the layer tag be used to arrange the global z-order
> of things?
layer is too weak as ordering operator. 2 ways layer=-1 + layer=2 can meet
in a node and (depending on node type if any) - will usually be assumed
to meet exact level.
Also there are loads of historical baggage associated with layer limiting
its usability. Because of widespread errors/abuse data consumers will/have
to ignore layer in many combinations.
Richard
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
