[Tagging] RFC - Level:ref=*

Martin Koppenhoefer dieterdreist at gmail.com
Wed Dec 2 10:39:01 UTC 2015

2015-12-01 21:33 GMT+01:00 Simon Poole <simon at poole.ch>:

> could have the tags added:
> level:ref=EG
> level:name=Erdgeschoss
> In a typical mall (were the non-floor plan variant is most  useful) you
> can easily have 20, 30 shops per level.

yes, I was not suggesting to add this to all shops in all cases. It should
likely go onto a "building level" object if present (indoor=level in your
proposal), or could be on some POIs just to have the reference, or could
only be added in buildings /parts where the mapper thinks that it is
noteworthy (e.g. not what you would expect or could infer with common
knowledge, e.g. level:name=Wintergarten).

>> Since SIT works really well (see OpenLevelUp),
> The min_level-idea doesn't work AFAIK in all cases, where storey heights
> of adjacent buildings are different and they are connected by a bridge, and
> more general, it doesn't work where levels aren't simply stacked and
> uniform for the whole part/buidling but are inclined or have varying
> absolute elevations in different rooms (e.g. connected by a ramp). The
> min_level of which building should apply? I still suggest to use
> building_levels for the amount of all levels of that building part /
> building, not the concept of "building_levels=min_level of a neighbouring
> building until first level+amount of building levels of the part that is
> tagged".
> Also buildings with varying floor heights are not depictable (AFAIK).
> SIT is not intended as a replacement for S3DB which you seem to be
> implying and I'm not quite sure why you believe you can't model a
> connection between two floors potentially with different numbering schemes
> in two different buildings given that the numbering -is- local to the
> building or building:part.

Yes, you are right, I was referring to
and in particular this picture:
Imagine the configuration in this picture was different: 7 floors on the
left and 9 floors on the right (lower ceiling height). Further imagine the
bridge had 2 floors: B1 with 5 meters height and
above it B2 with 3 m height.

Actually in SIT this situation is indeed depictable (but it will not define
the vertical position of these 2 floors, you'll need S3DB additionally). In
S3DB as far as I understand it, this situation is not clearly depictable
(because it is not clear which minlevel should apply to this bridge part).
You cannot refer to "non-existing"/missing building levels to define a
vertical position, because you don't know what height for these
non-existent levels should be asumed.

Don't get me wrong, your proposal looks good and works fine for most cases,
but it should have an additional/optional possibility to store absolute
elevation of levels as well (you do have height, but there should be an
optional ele suggestion IMHO). This would also solve inclined floors
(different ele on different nodes).

Also it is not clear what "height" refers to in case of a building level,
because currently the structure and installations/finishings are not
contemplated (you can see this also in the sketch).. May I suggest to
define it: distance from the finished surface of the floor of the
object/level to the finished surface of the floor level above. (This is the
standard definition for building levels, alternatively you could define raw
distances (but that's hardly surveyable).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20151202/c626f7e0/attachment.html>

More information about the Tagging mailing list