[Tagging] The actual use of the level tag

[Tobias Zwick]

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.

This is an interesting point. I agree, this is important information for
an indoor-map.
And from this standpoint, your suggestion to allow "level:ref" on single
shops within one building as a replacement for "level" sounds like a
good solution to accommodate for the points I made.

---

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.

First, I am still in the dark a bit how this affects SIT with S3DB
compatibility, perhaps Tordanik can explain. After all, a clearly
defined global Z-Order of things would be in the best interest of
3d-rendering, but he mentioned that this is not how the level tag was
intended (for SIT).

Second, why can not the layer tag be used to arrange the global z-order
of things?

Regards
Tobias


[1] By the way: The most complex example of such a situation I know is
Pathum Wan (ปทุมวัน) junction in central Bangkok, a multi-level skytrain
station, five different malls and a culture centre connect with each
other with various footbridges. Photos:
http://www.komchadluek.net/photo-gallery/512