Namen von Gebäuden und Gebäudeteilen.

Wenn es um Gebäudeteile geht (d.h. es ist auch baulich erkennbar ein Teil), dann building:part=was es ist (Büros, Hörsäle, Seminarräume, Labore, etc.). Dazuhin den Namen als name. Das ersetzt nicht das building-Objekt, ebenfalls mit name sofern zutreffend.
Sind es dagegen nur organisatorisch unterschiedliche Bereiche im selben Gebäude, ohne dass es bauliche Unterschiede bzw. Einheiten gäbe, dann müsste man das über das Taggen dieser Nutzungseinheiten machen (was auch in ersten Fall zusätzlich Sinn macht).
Dafür gibt es aus komplett unerfindlichen Gründen auch nach 16 Jahren immer noch keine vernünftigen tags, die die Funktionen, die an einer Uni vorkommen, beschreiben würden. Auch organisatorisch gibt es AFAIK nichts dokumentiertes (Fakultäten, Institute, etc.) und was defakto getaggt ist scheint unterschiedlichen Systematiken zu folgen. Man könnte damit mal anfangen :wink:
Ansonsten halt office=* und name, bzw. irgendwas anderes und name :wink:

warum ist https://www.openstreetmap.org/way/726606578 extra und nicht mit in der building-Fläche - damit fällt die Relation nur mit outer weg.
(Kenne aber das Problem nicht vor Ort, ob es ein Gebäude ist.)

https://www.openstreetmap.org/way/832518590 sieht mehr nach Verbindungsbau aus - gehört das wirklich zum Kohlrauschbau?

https://www.openindoor.io/ ?

Wenn ich mich recht errinnere, sind die Gebäude oberirdisch nicht verbunden.
Habe aber gerade nochmal in die Pläne geschaut, “unterirdisch” (Oberirdisch für OSM) aber schon^

(Wobei das Gebäude hier ein Paradebeispiel für das Beispiel hier ist: https://wiki.openstreetmap.org/wiki/DE:Key:building:levels
Und deswegen das 1. Kellergeschoss für OSM wohl ein Erdgeschoss ist, das "umzurechnen war etwas verwirrend^… )

Was ich allerdings nicht verstehe:
Hier müsste eigentlich der Kohlrauschbau erscheinen:
https://openlevelup.net/?l=3#19/52.29339/10.46068

Denn roof:level:1 habe ich an das eine Gebäude rangepappt…

Die Raumpläne sagen, dass es zum Kohlrauschbau gehört.

Muss halt bloß wer Mappen XD
Momentan scheint Auto Cad Architecture verwendet zu werden, wenn ich mir so die Metadaten der Raumpläne anschaue

Warum auch nicht Architektur wird mit (3D-)CAD-Programmen gezeichnet…

Wenn es erstmal um building:levels + roof geht hilft dir vielleicht erstmal dies weiter:
https://demo.f4map.com/#lat=52.2936814&lon=10.4635225&zoom=19&camera.theta=59.985&camera.phi=-15.756

Frage 1:
wieviele oberirdische Geschosse hat denn der Verbindungsbau
https://www.openstreetmap.org/way/832518590
tatsächlich 2 (EG + OG) wie dieser Gebäudeteil:
https://www.openstreetmap.org/way/832857417
?

Frage 2:
was verbindet er, wenn die Nachbargebäude derzeit kein building:levels:underground haben
?

falls die Frage nach einer technischen Möglichkeit der Datenkonversion war: über einen Export nach dxf könnte man das tun, wobei die paar Umrisse vermutlich schneller gezeichnet sind als bis man sich in die Konversion einarbeitet und alles das rauslöscht was man nicht braucht

… würde ebenfalls raten über export ob dwg/dxf oder sonstwas gar nicht erst nachzudenken.

Das müsstest du wohl die zuständigen Leute fragen und ich vermute die Antwort wird sein:
“Wurde schon immer so gemacht” …

Das Problem ist, dass wir hier den “D-Fall” haben:
https://wiki.openstreetmap.org/wiki/File:Building-levels.png
Wenn man nach den Raumplänen geht hat das Gebäude 2 Kellergeschosse und ein Erdgeschoss. (Wäre auch mein Empfinden, wenn man von Norden kommt)
Wenn man nach OSM geht, hat das Gebäude: 1 Kellergeschoss und Erdgeschoss und ein Obergeschoss. (Wäre auch mein Empfinden, wenn man von Süden kommt)

Der andere Gebäudeteil hat.
Wenn man nach den Raumplänen geht hat das Gebäude 1 Kellergeschosse und ein Erdgeschoss (Wäre auch mein empfinden)
Wenn man nach OSM geht, hat das Gebäude: Erdgeschoss und ein Obergeschoss.

  1. Ist beim Ohm-Bau bisher nicht gemappt (habe es beim Kohlrauschbau hinzugefügt, da ich eh gerade am ändern war)
  2. Eine Treppe nach oben :wink: (Das ist kein einfacher Durchgang, da sind Räume drinnen :wink: )

Mmh … würde annehmen, dass da also wohl ein Geländeversatz ist …

Fachsprachlich bzw. im Baurecht spricht man vom “Vollgeschoss” (im Sinne von vollwertigen Geschoss, das kein Keller- oder Dach- bzw. Staffelgeschoss ist).
Das OSM building:levels=x bezieht sich im Kern auf Vollgeschosse, ist also nix irgendwie Seltsames (bei Anschütungen/Geländeversätzen können natürlich Definitionprobleme entstehen).

Ich würde dir raten, dich nicht von irgendwelchen Bildchen verwirren zu lassen, sondern die Definition(en) der Architekten einfach zu übernehmen, wenn die (beispielsweise beim Zwischenbau) nur ein EG sehen (und kein 1. OG), wäre das building:levels=1

eigentlich versuchen wir in OpenStreetMap, weltweit gültige Definitionen zu verwenden. Was ein Vollgeschoss ist und wie das ermittelt wird, entscheiden in Deutschland die Länder in den Landesbauordnungen, und da gibt es durchaus Unterschiede, so ist z.B. teilweise die lichte Höhe entscheidend, in anderen Fällen die Geschosshöhe (Oberkante Fußboden bis Fußboden des nächsten Geschosses bzw. Dachhaut). Auch wieviel im Boden liegen darf bzw. daraus herausragen muss unterscheidet sich.

Ich hingegen würde dazu raten, sich an die Definitionen der OSM-Tags zu halten, nach denen ein Geschoss wie D im Bild eindeutig zu building:levels hinzugezählt wird.

Wen es interessiert, mit diesem Edit wurde das bunte Bildchen im April 2016 eingefügt:
https://wiki.openstreetmap.org/w/index.php?title=Key%3Abuilding%3Alevels&type=revision&diff=1287602&oldid=1160444
von einem Account der seit April 2016 keinen Edit mehr im OSM-Wiki getan hat.
Dies war das Vorlage- bzw. Vorgängerbildchen:
https://commons.wikimedia.org/wiki/File:Stockwerke.png

Dass es (allein) in Deutschland 16 Landesbauordnungen gibt ist mir wohlbekannt, für eine “was-ist-das-wahre-Vollgeschoss”-Disk ist mir meine Zeit aber wirklich zu schade.

wo gibt es dieses eindeutige Bild, bzw. welches Bild meinst Du?

Ich beziehe mich auf das Bild unter Key:building:levels#Example, das simonharms auch verlinkt hat.

Die Festlegung als solche ist deutlich älter und stammt aus dem Kontext von Simple 3D Buildings, also von 2012. Die Wiki-Dokumentation war bis vor ein paar Jahren zugegeben nicht so gut – zumindest für die Höhe findet sich aber seit der ersten Version der Seite die analoge Festlegung (“The height is the distance between the lowest possible position with ground contact to top of the roof […]”). Vielleicht könnte man mit mehr Recherche noch bessere Quellen finden, aber eigentlich weiß ich das nicht aus dem Wiki, sondern weil ich damals bei der Erfindung von S3DB mit dabei war. Mir ist klar dass meine Erinnerung für euch vielleicht nicht die fundierteste Quelle ist.

Letztlich geht es mir darum, weiter eine weltweit einheitliche, objektive Festlegung zu haben, mit der eine automatisierte Auswertung z.B. fürs 3D-Rendern etwas anfangen kann. Die Definition der o.g. Wikiseite leistet das. “Was sagt das Baurecht dort vor Ort” oder “was ist die von den lokalen Gepflogenheiten und der jeweiligen Landessprache geprägte Auffassung der Architekten” leisten das hingegen nicht. Wenn der Wunsch besteht, Level-Bezeichnungen wie “0”, “1”, “EG”, “OG”, … mit denen vor Ort in Einklang zu bringen, gibt es dafür aus dem Bereich Indoor-Mapping passende Tags.

ich bin auch für weltweite Standards, was die OpenStreetMap tags aussagen sollen, aber je nach Definition muss das nicht unbedingt dasselbe bedeuten, genauso wie ein tag der sagt: “das ist hier ein Fahrradweg” nicht bedeutet, dass alle Regeln für Fahrradwege in allen Ländern gleich sind.
Ich hoffe ich komme demnächst dazu, ein paar Varianten zu den building:levels Bildern zu zeichnen, damit klarer wird, weshalb das noch nicht die gesamte Definition sein kann. Die Bilder sind an sich schon klar, nur sind es die extremen bzw. einfachsten Beispiele dessen, was in der Realität vorkommt und von uns gemappt wird. Was ein Vollgeschoss ist, spielt z.B. schon eine Rolle, weil sonst vielleicht auch ein Kriechkeller oder ein ähnlich niedriges Technikgeschoss gezählt werden müsste, und man zu unerwüschten Nebeneffekten kommt (mehr GeschossFläche berechnet als es eigentlich gibt).

da gibt es sicherlich auch Situationen, wo je nach Definition dessen, was zum Haus gehört, Unerwartetes resultiert. Stell Dir ein Haus auf einer Klippe vor, dessen Abwasserrohr 30m nach unten reicht, wird das Haus dann 30m höher? Oder falls Rohre (und Kabel/Blitzableiter etc.) nicht gelten, es könnte auch eine Stahlstütze sein.

Es geht also darum, dass im Grenzfall (das Gelände steht unterschiedlich hoch an) ein Gebäude im 3D ein Geschoss höher erscheinen sollte (statt ein Geschoss niedriger), wobei eine korrekte Darstellung des anstehenden Geländes in OSM gar nicht stattfindet. Mit dieser Idee, unter der Prämisse dass ein “vorbeigehender Mapper auf die Schnelle etwas schätzt”, könnte ich ja noch leben.

Wenn aber ein Beitragender die Gebäude-Grundrisse seines Arbeitgebers vorliegen hat, deren Zuordnung [meine Vermutung aus der Ferne] auf deren baurechtlicher Einordnung beruht, dann würde ich ihm ausdrücklich davon abraten diese Einordnung zu ignorieren bzw. zu manipulieren - nur um eine vage OSM-3D-Idee umzusetzen.

Es geht darum, dass man OSM mit Höhendaten kombinieren kann und als Ergebnis eine Darstellung in 3D erhält, bei der das Zusammenspiel von Gebäude und Gelände der Realität entspricht – mit Gelände, das auf der einen Seite niedriger ist als auf der anderen. Dazu würde man natürlich falls vorhanden die Informationen aus OSM (z.B. Knoten wie Eingänge mit level-Tags auf dem Gebäudeumriss) nutzen, um das Gelände gegenüber den externen Daten weiter zu verfeinern.

Könnte man dieses Ziel auch mit einer anderen Definition von building:levels erreichen? Prinzipiell ja, solange man daraus die bisherige Information eindeutig, automatisiert und ohne Studium baurechtlicher Vorgaben in allen Ländern der Erde ableiten kann.

Mit Proposal und Migrationsstrategie für bestehende Daten und Software (statt als schleichende Aushöhlung der Definition durch Aufrufe im Forum, sich nicht daran zu halten) wäre ich für eine Diskussion über bessere Definitionen von building:levels durchaus offen.

Das aber möglichst separat von der Beantwortung von Einsteigerfragen. Denn neben Anwendungsentwicklern dürften Einsteiger eine zweite Gruppe sein, für die klare Antworten über die Bedeutung von Tags wichtig sind.

Schön und gut, aber was hat das mit der Einordnung von Geschoss x unter building:levels ODER building:levels:underground zu tun?
Ich plädiere doch nicht dafür es wegzulassen, sondern dafür es (baurechtlich) korrekt einzuordnen - statt Nutzer aufzurufen in OSM (völlig sinn- und grundlos) manipulierte Daten zu hinterlegen.
In der seriösen 3D-Architektur-Visualisierung werden Höhendaten des Gebäudes mit Höhendaten des umgebenden Geländes kombiniert - wenn ich die nicht habe, dann habe ich ein ganz grundsätzliches Problem.
Relevant ist dabei dann beispielsweise Oberkante Fußboden von Geschoss x - irrelevant ist erstmal ob Geschoss x ein Vollgeschoss oder KG ist, denn ein KG bzw. die Tiefgarage kann (und muss) man genausogut in eine 3D-Visualisierung einbinden.

Es gibt mir einen Ankerpunkt, um Gelände und Gebäude zu verbinden: Ich suche in meinen Geländedaten den innerhalb des Gebäudepolygons niedrigsten Punkt und passe dann das Gebäude so ein, dass die building:levels oberhalb dieser Marke liegen und die building:levels:underground unterhalb dieser Marke.

Wenn diese Information anderweitig getaggt wäre, z.B. als “bei diesem Gebäude ist das umgebende Gelände auf Höhe von level -1”, hätte ich kein Problem mehr damit, die Stockwerke auch nach anderen Kriterien aufzuteilen.

Da ich ein solches Tagging ohnehin gerne hätte – v.a. wenn man es auch an Nodes verwenden kann für “hier ist das Gelände auf Höhe von level 1, hier drüben ist es 0.5 m unter dem Fußboden von level 0” – wäre das vielleicht längerfristig eine Lösung? Könnte man evtl. mal zusammen mit anderen offenen Fragen zum Stockwerksmapping angehen. Es bräuchte dann natürlich trotzdem eine Festlegung für den Fall, dass diese Information nicht ausdrücklich angegeben ist.

Ok damit verstehe ich vermutlich dein Problem, bei Hanglage, bzw. Geländeversatz droht mit diesem Render-Rezept insb. ein eingeschossiges Gebäude mehr oder weniger im Hang abzusaufen.
Unter der Prämisse, dass wir hier eh nur von Schätzungen und groben Render-Andeutungen reden, und das eine leichte Höhenübetreibung optisch unproblematischer ist als ein absaufen, mal kurz angedacht:

  • Eine Höhenübetonung jedes EG
  • Eine Höhenübetonung insbesondere bei building:levels=1
  • statt nur niedrigsten Gelände-Punkt auch den höchsten ermitteln und interpolieren (wenn relevante Differenz)

Was die Verarnkerung von Infos zum Geländeverlauf an OSM-Objekten anbelangt, muss ich dir ehrlich sagen, dass ich dies nicht wirklich gedanklich durchdrungen habe, nur spontan:
An der Fläche eher schwierig, weil ein Gebäude (insb. in Hanglage) von ganz unterschiedlichen, komplexen Geländeschnittlinien umgeben sein kann.
Auf Node-Ebene sehe ich das größte Potential bei den entrace-nodes. In der Architektur ist dies der Punkt, an dem von Oberkante Fußboden Innen auf das Geländeniveau außen gewechselt werden muss. Und da gibt es häufig Unterschiede, die mit Treppen, Rampen oder Anschüttungen überbrückt werden müssen. Diese Übergänge sind dann auch on the ground sicht- und einschätzbar.
Beispiel das Photo in
https://wiki.openstreetmap.org/wiki/Tag:entrance%3Dyes
3 Steigungen a ca. 16-17 cm für eine Außentreppe, bedeutet OK Innen ca. 0.5 m über OK Gelände an diesem Punkt - das könnte man perspektivisch taggen.

Und nochmal, ich kann mit dem Bildchen leben, wenn aber ein engagierter Nutzer mit validen eigenen Daten nachfragt, dann rate ich ihm, die zu nutzen statt sie zu verbiegen.