<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Mo., 8. Okt. 2018 um 17:39 Uhr schrieb Tobias Knerr <<a href="mailto:osm@tobias-knerr.de">osm@tobias-knerr.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
These aren't intended as competing tags, but as complimentary tags. A<br>
perfectly mapped building (indoor mapping + outdoor 3D modelling) should<br>
currently use both sets of tags. The tags mentioned in A are used for<br>
describing the outer shape of the building, whereas the tags from B are<br>
used for indoor mapping.<br></blockquote><div><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
These different use cases result in somewhat different conventions for<br>
the tags:<br>
<br>
- A is only counting above-ground levels (because only those can be<br>
verified without entering the building), whereas B includes underground<br>
levels.<br></blockquote><div><br></div><div><br></div><div>A is not counting only above ground levels.</div><div>It is counting these in building:levels, but it has "building:levels:underground" for underground levels and has also roof levels separate. <br></div><div>The building:min_level definition says it is "For describing number of values, "filling" space between ground level and bottom level of building or part of building". min_level=-1 is a common value for the tag according to taginfo, and it doesn't seem to contradict the definition (if a "negative fill" is accepted).<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- B allows for things like "skipped levels", to reflect naming<br>
conventions chosen by the building owners, whereas A is strictly about<br>
counting levels, and does not take local customs for naming levels into<br>
account at all.<br></blockquote><div><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">I agree that both is useful, local naming/ref and the physical situation. From what I understand, we do not need building:max_level for scheme A (because the number of building levels is already clear from the 3 building:levels tags).</div><div class="gmail_quote"><br></div><div class="gmail_quote">I was using ranges and lists in the level tag so far, something that seems to be common as well: <a href="https://taginfo.openstreetmap.org/keys/level#values">https://taginfo.openstreetmap.org/keys/level#values</a></div><div class="gmail_quote"><a href="https://wiki.openstreetmap.org/wiki/Key:level">https://wiki.openstreetmap.org/wiki/Key:level</a><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I can see the min_level and max_level and non_existent_levels tags are useful for describing Indoor stuff (POIs, also building parts), but it is basically a two/three-tag-alternative to "level" with a range or list value. Minor nitpick: rather than "non_existent_levels" the name "skipped_levels" would have been nice, as it would also refer to generally existing levels (in the building) which are skipped in the specific building:part.<br></div></div><div><br></div><div>A disadvantage from max_level and min_level and non_existent_levels is that you cannot infer the amount of total levels (if the definition is levels as locally used/signed), because you  can never know how many levels there are in between level 1 and level 2 (in actual buildings). It could well be there are levels 1.1, 1.2, 1.3 or SU and SO. or foobar. We should definitely agree on to what the max_level and min_level tags refer (if they are written in local level names/refs, what would make sense, I agree).</div><div><br></div><div>Cheers,<br></div><div>Martin<br></div><div><br></div></div></div>