Bitte um Feedback. Ergänzung fehlender Gebäudehöhen und Stockwerksangaben in Teilen Deutschlands

Communities Deutschland (Germany)
1

Hallo OSM-Community Deutschland,

ich möchte euch einige Überlegungen vorstellen und eure Meinung dazu hören, bevor wir dies weiterverfolgen.

Wir prüfen, ob wir helfen können, bestehende OSM-Gebäude in Deutschland mit fehlenden height=* und/oder building:levels=* Tags anzureichern, basierend auf offenen öffentlichen Datenquellen. Wir würden mit Berlin beginnen und anschließend mit Städte in NRW (Köln, Dortmund, Münster, Bonn) weitermachen. Ein paralleles Pilotprojekt läuft bereits in den Niederlanden mit 3DBAG-Daten, siehe hier: Netherlands - Missing Building Heights and Levels | Nederland - Ontbrekende Gebouwhoogtes en Bouwlagen

Mit diesem Beitrag möchten wir unsere Absichten offen teilen und frühzeitig Input aus der Community einholen.

Welche Quellen wir uns ansehen

Für Berlin haben wir zwei offene Datenquellen der Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen geprüft. Beide stehen unter DL-DE-Zero-2.0:

Für NRW schauen wir uns folgende Daten an:

Für Berlin ist unsere aktuelle Einschätzung, dass die Ebene Gebäudehöhen aus dem Umweltatlas besser zu unserem Anwendungsfall passt als der vollständige LoD2-Datensatz (einfacheres Format, breitere Abdeckung). Wir befinden uns aber noch in der Bewertungsphase und haben uns noch nicht festgelegt.

Was wir tun wollen (und was nicht)

height=* und/oder building:levels=* nur auf bereits bestehenden OSM-Gebäuden hinzufügen, sofern die Zuordnung eindeutig ist. Wir planen nicht, neue Gebäude hinzuzufügen, Geometrien zu verändern oder andere Tags zu ändern. Gebäude, die bereits ein height=* oder building:levels=* Tag haben, werden übersprungen, da wir manuelles Mapping nicht überschreiben wollen.

Ein paar Fragen:

  • Wie steht ihr dazu?
  • Hat jemand schon mit diesen Berlin- (zuerst) oder NRW-Quellen gearbeitet? Gibt es Qualitätsprobleme, die wir kennen sollten?
  • Gibt es bessere Quellen, die wir übersehen haben?
  • Gibt es Lizenz-Vorbehalte, die wir beachten sollten? Wir haben DL-DE-Zero-2.0 als ohne Sondergenehmigung verwendbar verstanden, lassen uns aber gerne korrigieren.
  • Gibt es bevorzugte Tag-Konventionen in der deutschen Community für source:height=*, Quell-URL oder Versions-Tagging?
  • Gibt es allgemeine Hinweise, Bedenken oder “achtet auf X”-Empfehlungen aus früheren Imports?

Falls wir weitermachen, werden wir vor jeglichen Uploads eine Deutschland-spezifische Organised-Editing-Wiki-Seite veröffentlichen und diesen Thread aktuell halten.

Viele Grüße,
Salim Baidoun TomTom

2 Likes
2

Ich bin da immer so ein bisschen vorsichtig mit “automatischem import” oder “update”.

Für NRW und andere Bundesländer hab ich ja eine möglichkeit geschaffen mit “point and click” mithilfe des josm plbuildings plugins (fork zzbuildings) ALKIS Outlines automatisch zu übernehmen oder upzudaten.

Das Posting hat mich jetzt auf die Idee gebracht da auch building:height/building:levels evtl mit zu übergeben. Die gml_ids hab ich eh in der Datenbank durch die anderen Datensätze. Es wäre also vermutlich ein einfaches eben aus den LoD daten die liste gml_id, height, levels zu ermitteln und daneben zu legen und die API anzureichern. Dann kommt das einfach mit.

Flo

2 Likes
3

Hallo @flohoff

Vielen Dank für die schnelle Reaktion. Die Info zu deiner Arbeit ist sehr hilfreich, und wir teilen die Vorsicht bei automatischen Imports.

Dein Ansatz mit plbuildings und zzbuildings klingt sehr interessant. Bevor wir uns überhaupt ein Bild machen, würden wir gerne tiefer einsteigen. Hast du Links zu Repository oder Doku? Und welche Lessons Learned wären für uns wichtig zu kennen, vor allem zur Community-Reaktion, Datenqualität und wie du dir den Übergang zu height und levels vorstellst?

Und von unserer Seite: wie können Leute wie wir bei TomTom überhaupt zu deiner Arbeit beitragen? Wir sind für vieles offen, sei es Daten, Code, Testing oder Doku, je nachdem was für dich tatsächlich nützlich wäre.

Wir wollen erstmal verstehen, bevor wir irgendetwas konkret vorschlagen. Lieber das richtige als das schnellste.

Viele Grüße, Salim

4

Hallo Salim und TomTom-Team,
ich finde euren Plan für Berlin prinzipiell gut und würde mich freuen, wenn wir bei den Gebäudeattributen in OSM Fortschritte machen. Ähnlich wie bei Straßenbäumen (bei denen es beispielsweise in Hamburg auch schon “Importe” gab) liegt es in der Natur der Sache, dass es extrem viele davon gibt, sich viele Attribute nur umständlich messen lassen und die Detailtiefe in OSM daher zu Wünschen übrig lässt. Gleichzeitig gibt es hervorragende OpenData, die aktuelle und weitgehend plausible Daten mitbringen und OSM-kompatibel sind.

Datenqualität und -quellen: Ich habe in Berlin schon viele Gebäude gemappt oder Stockwerkszahlen nachgetragen – mal mit, mal ohne Ground Truth. Mein Vertrauen in die Berliner Gebäude-OpenData ist dadurch so hoch, dass ich sie inzwischen auch “blind” übernehme, da mir nur in den seltensten Fällen Fehler aufgefallen sind. Als Quelle für building:levels nutze ich ALKIS (ALKIS Berlin Gebäude - [WFS] | Berlin Open Data). Zumindest für eine Datenübernahme der Stockwerkszahlen scheint mir das der beste Layer zu sein, da sich hier auch Gebäudeumringe und Gebäudeteile diffenzieren lassen. Mit den Gebäudehöhen habe ich bisher kaum Erfahrungen gesammelt, das Gelände- und Oberflächenmodell erschien mir in anderen Kontexten bisher aber immer recht präzise. In welcher Form würdet ihr die Daten übernehmen? Vermutlich keine Gebäudeteile (oder nur, wenn in OSM vorhanden), sondern den höchsten Wert im Gebäudeumring? Höhen auf eine Nachkommastelle gerundet?

Die OSM-Gebäudeumringe wurden in Berlin in den letzten Jahren vielerorts auf Grundlage der ALKIS-Daten präzisiert. Im größten Teil der Stadt sind die OSM-Geometrien also sehr nah an ALKIS – es gibt aber auch noch Ecken, wo die OSM-Gebäudeumringe noch von älteren Luftbildern stammen (also geometrisch, geschätzt, nicht zu 98% übereinstimmen, sondern vielleicht nur zu 80%). Vermutlich kein Problem, aber vielleicht trotzdem gut zu wissen.

Lizenz: Die Berliner Daten können bedenkenlos für OSM genutzt werden, da die Berliner Senatsverwaltung diese explizit für OSM freigegeben hat.

Import: Ich würde mir wünschen, dass ihr auf der Organised-Editing-Wiki-Seite nicht nur die Methodik einer Datenübernahme skizziert, sondern vor einem “stadtweiten Rollout” mit einem “Probeimport” zeigt, wie das Ergebnis konkret aussehen würde.

P.S. Auch wenn es vielleicht nicht in eurem primären Interesse liegt, könnte es im Rahmen eines Imports interessant sein, Gebäudenutzungen (Wohn- vs. Gewerbenutzung u.ä.) gleich mit zu übernehmen. ALKIS enthält eine Kategorie der Gebäudenutzung, woraus sich unspezifische OSM-Tags (building=yes) präzisieren lassen würden. Die Zuverlässigkeit der Daten dürfte aufgrund ihres baurechtlichen Hintergrunds sehr hoch sein; bei der konkreten Umsetzung könnte es aber noch Abstimmungsbedarf geben (Zuordnung der Kategorien, Verwendung von building vs. building:use etc.)

P.P.S. Für Datenanalysen halte ich building:levels übrigens für den wesentlich nützlicheren Wert als height. Letzteres ist zwar “nett für Renderings”, aber aus building:levels lässt sich meist ein vergleichbares Ergebnis erzielen bei gleichzeitiger Mehrinformation. Stockwerkszahlen sind (in Kombination mit Gebäudenutzung) beispielsweise interessant, um Bevölkerungsverteilungen zu berechnen – hab ich mal getestet und musste auf Grund der mangelhaften Datenlage in OSM auf ALKIS ausweichen.

6 Likes
5

Gebäudehöhen sind im Wiki spezifiziert als:

Use the maximum height for buildings, not the average height. Specifically, the maximum is the distance between the top edge of the building (including the roof, but excluding antennas, spires and other equipment mounted on the roof) and the lowest point at the bottom where the building meets the terrain.

Wie ist die Definition der Höhe in den LoD2-Daten beschrieben? Falls es unterschiedlich ist, könnten / sollten diese Daten in OSM unter einem anderem Key (height:LoD2=* ?) gespeichert werden. Dann könnte man auch für Gebäude, die bereits Höhen erfasst haben, einen Vergleich machen.

6

Leicht OT:

Erstens würde ich das aus persönlicher Erfahrung doch sehr in Frage stellen. Die Daten werden irgendwann erstellt - und dann kaum noch gepflegt. Da fehlt auch der Vermessungsverwaltung die Manpower/Motivation (auch aus Kostengründen).
Zweitens beschreibt das eher building:use und nicht den ursprünglichen Gebäudetyp.

Allerdings sind auch viele building:(*<> yes) in OSM vom Luftbild her geraten und haben nur sehr begrenzte Qualität. Da gibt es zu viele SC-Nutzer, die einfach keine Lücken hinterlassen wollen…
Hier zum Beispiel “offensichtlich” eine Garage/ein Carport: Way: 643505080 | OpenStreetMap - als “detached” erfasst.

4 Likes
7

sehe ich auch weitgehend so. Gerade dass es baurechtlich so wichtig sein kann, bedeutet, dass die tatsächlich vorhandenen Nutzungen ggf. unterschlagen werden, damit man keine Probleme bekommt.

2 Likes
8

Hallo @flohoff @Supaplex030 @dieterdreist @pyram @stephan_t :

danke für die Rückmeldungen bisher. Schön zu sehen, dass die Lizenzfrage durch die Community bereits geklärt ist, vielen Dank @Supaplex030 für den Link zur OSM-Freigabe der Senatsverwaltung.

Bevor wir einen konkreten Vorschlag formulieren, würden wir lieber zuerst eure Einschätzung hören.

Wir schauen uns zwei Quellen an:

  • ALKIS Berlin Gebäude
  • Umweltatlas Gebäudehöhen

Frage an euch:

  • Ist eine der beiden Quellen für Berlin klar dominant gegenüber der anderen?
  • Oder seht ihr einen Hybrid-Ansatz mit beiden, verknüpft über eine gemeinsame Gebäude-ID (z.B. ALKIS uuid ↔ Umweltatlas gml_id), als realistisch?
  • Gibt es Erfahrungen aus eurer Arbeit, die in eine bestimmte Richtung deuten?

Wir wären für eure Unterstützung dankbar. Ihr arbeitet seit Jahren mit diesen Daten und kennt Stärken und Schwächen besser als wir.

Vor jedem weiteren Schritt würden wir gerne zu einer Schlussfolgerung kommen, die aus der Community kommt.

Hi all,

Thanks for the responses so far. Good to see the license question is already settled within the community, special thanks to @Supaplex030 for the link to the Senate OSM release.

Before we put forward a concrete proposal, we would rather hear your assessment first.

We are looking at two sources:

  • ALKIS Berlin Gebäude
  • Umweltatlas Gebäudehöhen

Question for you:

  • Is one of the two sources clearly dominant over the other for Berlin?
  • Or do you see a hybrid approach with both, linked via a shared building ID (e.g. ALKIS uuid ↔ Umweltatlas gml_id), as realistic?
  • Are there experiences from your work that point in one direction?

We would appreciate your support here. You have been working with these data sources for years and know the strengths and weaknesses better than we do.

Before any next step, we would like to reach a conclusion that comes from the community.

Best regards,
Salim (TomTom)

9

Das klingt meiner Meinung nach sinnvoll.

ALKIS wird kontinuierlich aktualisiert, während die Gebäudehöhen/Umweltatlas ein “One-Shot”-Datensatz ist, der sich auf einen älteren Datenstand – vermutlich auf Basis von ALKIS – bezieht, derzeit von 2022. Ich würde also in jedem Fall ALKIS als primäre Referenz nutzen (für building:levels), und falls es im Datensatz für die Gebäudehöhen einen Match über den Objektidentifikator (uuid/gml_id) gibt, dann zusätzlich height darüber beziehen. Denn wenn es diesen Match gibt, ist trotz des Datenstandes von 2022 klar, dass das Gebäude auch heute noch besteht.

Insofern erscheint mir also ein Hybrid-Ansatz mit beiden, verknüpft über ihre gemeinsame Gebäude-ID (ALKIS uuid ↔ Umweltatlas gml_id) sinnvoll.

Theoretisch ist denkbar, dass sich die Stockwerkszahl eines Gebäudes seit 2022 verändert hat (z. B. durch Aufstockung) und einer aktuellen Stockwerkszahl aus ALKIS dann eine veraltete Gebäudehöhe aus dem Umweltatlas zugeordnet werden würde. Da die Stockwerkszahl auch im Umweltatlas vorhanden ist, könnte dieser Fall über einen Vergleich des Wertes mit dem (aktuellen) ALKIS abgefangen werden. Ich kenne die Umweltatlas-Daten aber nicht genau genug um sagen zu können, ob die Stockwerkszahlen im Normalfall immer gleich sind.

10

Ich wollte einfach nur mal die Rückmeldung geben, dass ich mich super freuen würde, wenn diese Daten in OSM ergänzt werden würden - ich benutze building:level beruflich im Bereich Schulwegplanung, um die Anzahl von Schulkindern abzuschätzen. Da diese Infos oft fehlen, muss ich die vielerorts (meist aus nicht OSM-kompatiblen Quellen) nacherheben, was viel Arbeit bedeuten kann. Hochladen kann ich die so geänderten Daten dann aber in der Regel nicht.

Für meine Arbeit ist es ausreichend, wenn die Daten ungefähr stimmen. Kleinere Abweichung, wie das bei automatischen Imports zu erwarten ist, wären unproblematisch. Für OSM wäre es natürlich besser, wenn alle Zahlen stimmen täten, aber ich glaube, es ist immer noch besser als gar keine Zahlen zu haben.

2 Likes
11

Da muss ich widersprechen bzw den widersprechenden Meinungen zustimmen. Bereits die bisher in verschiedenen Bundesländern (mehr oder weniger automatisch und wenig bis gar nicht dokumentierten) durchgeführten bzw andauernden “Imports” der ALKIS-Daten über das bereits erwähnte plbuildings pluing sind nicht unproblematisch, wie hier ja kürzlich diskutiert wurde, weil damit massiv bestimmte tags verwässert wurden/werden, nämlich da, wo das was ALKIS liefert überhaupt nicht zu den OSM-Definitionen passt (z.B. Garagen als commercial in RLP). Ob diese Probleme in allen Bundesländern auftreten ist mir bisher nicht bekannt.

Inwiefern die Qualität der Stockwerkdaten besser bzw. für OSM brauchbar ist kann ich nicht beurteilen. Die Idee eines Probeimports finde ich gerade dann positiv, wenn Probleme mit dem zugrunde liegenden Datensatz schon bekannt sind, so könnte man ggf. weitere Probleme frühzeitig erkennen.

2 Likes
12

Das ganze ist kein Import sondern eben eine “Point-and-click” übernahme aus dem ALKIS des Gebäudeoutlines. (Ich hab den kram gebaut)

Es werden OSM Tags basierend auf der ALKIS “Gebäudefunktion” angereichert basierend auf dem offiziellen ALKIS Katalog der Gebäudefunktion.

AdV GeoinfoDok Anwendungsschema Gebäudefunktion

Es hat sich gezeigt das einige Bundesländer das mehr so mäßig genutzt haben - So z.b. hat Niedersachsen und RLP für Garagen die Gebäudefunktion “2000” benutzt hat anstatt des genaueren “2463”. Daran kann man jetzt wenig ändern.

Es bleibt demjenigen der da die Gebäude updated überlassen das zu korrigieren. Sollte bereits ein “building=garage” gemapped sein kommt ein popup das es ein konflikt gibt - kann man dann annehmen oder eben auf garage lassen. Ein “building=yes” würde schweigend zu einem “building=commercial”.

So richtig verstehe ich die Behauptung nicht was da verwässert wird. Es kann lediglich ein unspezifiziertes Gebäude zu einem commercial werden, es bleibt aber in jedem fall in der Hand des Mappers vor Ort der das natürlich nur macht wenn er sich sicher ist das das richtig ist.

Und man kann auch nur den Outline übernehmen ohne die Tags - es bleibt immer in der Hand des Mappers.

Flo

13

Gerne mal hier reinschauen, dann müssen wir diesen Thread nicht derailen

14

Ich habe da eben mir mal die mühe gemacht und angefangen die LoD2 Daten zu extrahieren und mal zu matchen auf das was ich eh an Gebäudeoutlines habe und bin innerhalb von 20 Minuten auf inkonsistenzen gestoßen.

Hier eins der Beispiele:

  • NRW Aachen, Stephanstraße 15
  • gml_id DENW39AL10005VWc
  • Laut LoD2 höhe 4.776 keine Geschossangabe

Wenn man mal mit Streetview nachsieht hat das Gebäude 5 Geschosse. Das ist so ziemlich unbrauchbar.

Wenn ich mir mal Gebäude auflisten lasse nach height/levels dann kommt sowas bei raus. Und es sind ja nur wenige Gebäude mit den Anzahl der Geschossen vorhanden.

Gebäude die 2.7m hoch sind aber 4 Geschossig sind. Oder 30m und ein Stockwerk - Das lasse ich ja vielleicht noch durchgehen - Das Amazon hochregallager.

      gml_id      | height | levels | dachform |    levelheight     
------------------+--------+--------+----------+--------------------
 DENW39AL10003jwO |  0.562 |      1 |     1000 |              0.562
 DENW39ALI40000QC |  2.743 |      4 |     1000 |            0.68575
 DENW39AL10005WA5 |  1.684 |      2 |     1000 |              0.842
 DENW39AL2xI0004e |   2.83 |      3 |     1000 | 0.9433333333333334
 DENW39AL10001qBG |  2.996 |      3 |     1000 | 0.9986666666666667
 DENW30AL0000xgYk |  6.003 |      1 |     5000 |              6.003
[ ... ]
 DENW39AL10003jxc |  18.97 |      1 |     3100 |              18.97
 DENW39ALQq0000ni | 19.494 |      1 |     5000 |             19.494
 DENW39ALP60000IL | 19.949 |      1 |     3100 |             19.949
 DENW39ALP60000Cy | 20.082 |      1 |     3100 |             20.082
 DENW39AL1Gh0003B | 21.019 |      1 |     3100 |             21.019
 DENW39ALP60000GR | 21.618 |      1 |     5000 |             21.618
 DENW39ALQq0000Xu | 22.712 |      1 |     5000 |             22.712
 DENW39ALP60000MQ | 25.606 |      1 |     5000 |             25.606
 DENW39AL10003jyI | 28.726 |      1 |     5000 |             28.726
 DENW39AL10003k1Q |  29.81 |      1 |     5000 |              29.81

Also so ganz ist mir noch nicht klar wie man das nutzen kann/will.

15

Ich hab mal gerade in der postgis die LoD2 höhen extrakte über die gml_id mit dem WFS Output für die Gebäudeoutlines verschnitten und das im QGIS visualisiert - also colorierung nach Gebäudehöhe. Wieder der Aussschnitt “Stephanstraße, Aachen”.

Da das ja Frontbebauung ist müssten die Gebäude entlang der Straße alle “in etwa” dieselbe Höhe haben. Es fallen sofort die Fehler in den LoD2 Daten auf. Hier sind mit einem mal Gebäude die zwischen 15-20m sein sollten (Alles 4-5 Geschosse) nur noch 4-5m.

Hier visualisiert ist die bldg:measuredHeight aus den LoD2 Daten.

20260601-flo-aachen-qgis-screenshot-building-height-lod2
20260601-flo-aachen-qgis-screenshot-building-height-lod2871×769 384 KB

16

Meine Vermutung nach Vergleich mit Luftbild:

Es handelt sich i.d.R. um Gebäude mit einem deutlich niedrigerem Anbau/rückwärtigen Seitenflügel, die keine getrennte outlines haben. Die Gebäudehöhe richtet sich also nach dem niedrigsten Bauteil.

Das ist oft so, aber nicht immer so.

17

Ich tippe das das so ein Problem ist das Gebäude halt kein Kubusse sind. D.h. bei komplexen Gebäuden ist das halt die “mittlere Höhe” des Gesamtgebäudes.

Man müsste halt die Gebäude teilen - also aus dem LoD2 die komplettform übernehmen als building:parts mit den Höhen.

Irgendwie unbefriedigend.

Flo

18

Nene, nach mittlerer Höhe sieht das nicht aus. Wir reden hier von Gebäuden von etwas 18-20 m Höhe, da ist es schwierig auf etwa 5 m mittlere Höhe zu kommen. Die Erdgeschosse (Hochparterre) haben ca. 5 m, was dies auch für die rückseitigen eingeschossige Anbauten wahrscheinlich erscheinen lässt.

Aber egal, das ist ein systematischer Fehler, der doch recht häufig aufzutreten scheint und die Angaben relativ unbrauchbar macht.

Es haben halt nicht alle Geodienste den gleichen Qualitätsanspruch wie OSM ;-)