Netherlands - Missing Building Heights and Levels | Nederland - Ontbrekende Gebouwhoogtes en Bouwlagen

Communities Nederland (Netherlands)
,
21

My two cents on building heights.

Over the past months I’ve spent quite some time mapping 3D buildings in my area, including splitting buildings into parts where needed.

image
image611×201 4.25 KB

If this data is clearly available, importing it would certainly be useful. In that sense I tend to agree with earlier comments that this is probably something that should be solved through an import or tooling, rather than manual tasks.

However, I would be cautious about automatically importing detailed building:parts. Many buildings consist of multiple parts with different heights, which makes a fully automated process quite complex.

Importing the maximum building height to the existing building outline would already be a big improvement.

Also worth noting: when using building:levels, most 3D renderers assume an average floor height of about 3 metres and derive the total height from that. That works often, but certainly not always, which makes height=* the more accurate tag when reliable data is available.

One question about the 3DBAG height values: do they represent the height of the main roof surface, or the highest reconstructed point in the model? I’m curious how that is defined exactly in the dataset.

More generally, even a basic import of reliable height data would already add value at a national scale. Once that baseline exists, mappers can more easily refine buildings further with building:parts, roof shapes, and other 3D details where needed. Having measured data available is much better than having to estimate it manually.

1 Like
22

Yes, we need a map that indicates where 3D tags are mapped ;-)

Ohsome voor building:part

Screenshot_20260309_073109
Screenshot_20260309_073109876×446 59.8 KB

If this data is clearly available, importing it would certainly be useful.

The data is available, see the 3D BAG viewer. Zoom to some well know area’s and compare some simplere and complex building. Play a with the LoD level.

Would be good to compare things with what you mapped yourself but I did for what I recently mapped and I was reasonable impressed but I see some clear limitations. What would be good if we get a common understanding of this.

See the openingspost:

  • height = b3_h_dak_max − b3_h_maaiveld (gemeten van de hoogste dakwaarde in LoD2.2 tot aan het maaiveldniveau uit de AHN-puntenwolk).

Alle attributen zijn netjes gedocumenteerd hier:

Helaas mist b3_h_dak_max maar de naam zelf doet iets vermoeden

Ik ben niet zo overtuigd dat alleen een import van building height ons veel verder brengt, ja voor gebouwen met een plat dak maar laten we dan ook gelijk dat (plat dak) mappen.

23

Hoi OSM Nederland,

Als vervolg op mijn eerdere post in deze thread (Netherlands - Missing Building Heights and Levels | Nederland - Ontbrekende Gebouwhoogtes en Bouwlagen), wil ik open zijn over een heel kleine pilot rond gebouwhoogtes die we net hebben uitgevoerd, en de community om feedback vragen voordat we verder gaan.

Wat we hebben gedaan

We hebben height tags toegevoegd aan 17 gebouwen, met data uit 3DBAG (BAG, TU Delft, CC BY 4.0). De gebouwen liggen binnen 8 kleine polygonen verspreid over de gemeente Amsterdam, inclusief het Weesp-gebied, bewust gespreid in plaats van geconcentreerd in één buurt. Het idee was om de tool en de tagging convention te testen in meerdere verschillende stedelijke contexten in één keer, variërend van woonstraten met laagbouw tot kantoorgebouwen. Binnen deze acht testgebieden hebben we ook gebouwen geselecteerd die al een height tag hadden, om te voorkomen dat we deze zouden overschrijven, evenals één gebouw met de type=building relatie, waaraan we ook bewust geen height hebben toegevoegd. Uiteindelijk hebben we 17 gebouwen bijgewerkt zoals verwacht. De volledige multipolygon scope is bijgevoegd zodat iedereen de exacte locaties kan inspecteren.

Test scope als GeoJSON:
AMS_heights_tool_test_scope_multipolygon copy.txt (2.6 KB)

  • Gebruikt account: ttmechanicalupdates@groups.tomtom.com
  • Changeset(s): 182242209, 182242210, 182242211, 182242212, 182242215
  • Datum: 05-05-2026, 12:19 CET
  • 3DBAG versie: 2025-09-03
  • source:height = 3DBAG
  • source:height:date = 2025-09-03

Wat we NIET hebben aangepast

  • ref:bag tags (ongewijzigd gelaten)
  • building geometry
  • building:levels (3DBAG publiceert geen aantal verdiepingen en wij hebben deze niet ingevuld)
  • gebouwen die al een height tag hadden (overgeslagen)
  • gebouwen zonder een matchende ref:bag (overgeslagen)

Als jullie geen bezwaren hebben tegen deze 17, zullen we onze voorbereide wiki import page delen en publiceren volgens de OSM Import Guidelines, en hier delen voor jullie feedback voordat we verder gaan. Als de QA laat zien dat iets niet werkt zoals we hadden verwacht, zijn we volledig bereid om de 17 gebouwen terug te draaien (revert). Dit is in lijn met de OSM Import Guidelines en de Automated Edits Code of Conduct, die beide verwachten dat georganiseerde edits omkeerbaar zijn.

Salim, TomTom

Hi OSM Nederlands,

Following up on my earlier post in this thread (Netherlands - Missing Building Heights and Levels | Nederland - Ontbrekende Gebouwhoogtes en Bouwlagen) , I want to be open about a very small pilot we just ran on building heights and ask the community for feedback before we do anything more.

What we did
We added height tags to 17 buildings, sourced from 3DBAG (BAG, TU Delft, CC BY 4.0). The buildings sit inside 8 small polygons distributed across the Amsterdam gemeente, including the Weesp area, deliberately spread rather than concentrated in one neighbourhood. The idea was to test the tool and tagging convention against several different urban contexts in one run, ranging from low-rise residential streets to office buildings. Within these eight test areas we also selected buildings that already had a height specified, to make sure we did not overwrite them, as well as one building with the type=building relation, to which we also intentionally did not add a height. We ultimately updated 17 buildings as expected. The full multipolygon scope is attached so anyone can inspect the exact locations.

Test scope as a GeoJSON :
AMS_heights_tool_test_scope_multipolygon copy.txt (2.6 KB)

  • Account used: ttmechanicalupdates@groups.tomtom.com
  • Changeset(s): 182242209,182242210,182242211,182242212,182242215
  • Date: 05.05.2026 - 12:19 pm CET
  • 3DBAG version: 2025-09-03
  • source:height = 3DBAG
  • source:height:date = 2025-09-03

What we did NOT touch

  • ref:bag tags (kept as is)
  • building geometry
  • building:levels (3DBAG does not publish floor counts and we did not enter them)
  • buildings that already had a height tag (skipped)
  • buildings without a matching ref:bag (skipped)

If you have no objections with these 17, we will share and publish our prepared wiki import page following the OSM import guidelines and share it here for your feedback before doing anything more. If QA shows that something is not working as we expected, we are fully willing to revert the 17 buildings. This is in line with the OSM Import Guidelines and the Automated Edits Code of Conduct, both of which expect any organised editing to be reversible

What we want to hear from you.

Salim, TomTom

24

Je hebt nu de ref:bag ongemoeid gelaten. Dat is mooi, maar als je een pand toch wijzigt, zou het wellicht nog mooier zijn dat je de ref:bag voorziet van voorloopnullen als die ontbreken. Dat is iets dat we met de BAG plugin ook doen als een pand toch wijzigt vanwege mutaties.

Zie ook Voorloop nul(len) BAG referentie nummers

1 Like
25

Hoi Sander,

Heel erg bedankt voor de waardevolle feedback! We zullen dit zeker meenemen en voorloopnullen toevoegen aan de ref:bag waar die ontbreken, in lijn met wat de BAG plugin al doet. Ik zal dit ook expliciet documenteren in de wiki import page wanneer we die publiceren. Bedankt ook voor de link naar het topic over voorloopnullen, ik zal die doornemen.

Groeten, Salim

26

Is de licentie van 3DBAG niet CC BY 4.0 ipv CC0?

2 Likes
27

Changeset 182242209 geladen in OSMCha en daar zie ik:

Screenshot_20260506_064820-1

Dat kan beter.

Drie tags toegevoegd:

Screenshot_20260506_065153
Screenshot_20260506_065153463×152 14.2 KB

Wat betreft de source tags, niet slecht maar liever zou ik een link zien naar een 3DBAG object ID zien, daarmee is direct duidelijk dat de source 3DBAG is. Zou goed zijn als je met die ID op de 3DBAG site naar dat object kan springen.

Ik zie dat er z’n link is:

https://api.3dbag.nl/collections/pand/items/NL.IMBAG.Pand.1655100000500568

Zoals ik eerder schreef zou ik behalve de hoogte ook iets van de vorm van het dak willen toevoegen, Key:roof:shape:

Screenshot_20260506_072018
Screenshot_20260506_072018275×132 12 KB

Deze twee vormen zou uit de data te halen moeten zijn en daarmee heb je een groot deel van de daken. Andere vormen zijn te moeilijk of kunnen later.

2 Likes
28

@Tjuro
Dat klopt. 3DBAG is gelicenseerd onder CC BY 4.0, niet CC0. Ik heb dit overigens ook al genoemd in de thread.

Ik heb daarnaast direct contact gehad met TU Delft hierover, en zij hebben aangegeven geen bezwaar te hebben tegen het gebruik van de 3DBAG-data voor dit doel.

Bedankt

1 Like
29

“Nothing against” is good, but probably not good enough, in particular as the choice of CC BY 4.0 would indicate that they are not aware of the consequences of the licence they chose and they might be surprised if we took “nothing against” as waiving fundamental bits of CC BY, see Use of CC BY 4.0 licensed data in OpenStreetMap | OpenStreetMap Blog I would suggest simply getting them to sign a proper waiver.

2 Likes
30

Hi Simon,

Thank you for the clear guidance and for the link to the blog post. You are right: “nothing against” is not a substitute for a formal waiver, I will get the waiver from TU Delft (3D geoinformation and 3DGI).

Appreciate you replying and looking into this.

3DBAG_CC_BY_4.0_Waiver_Request.docx (17.9 KB)

Best regards, Salim

31

Hoi emvee,
Bedankt voor je input. We hebben beide voorstellen intern bekeken.

Source URL per pand
We hebben goed gekeken of we per pand een directe source:height:url kunnen toevoegen, maar zien daarbij twee problemen:

  • De 3DBAG API serveert de huidige data, niet een specifieke release. Een URL die nu klopt, zou na een 3DBAG-update naar afwijkende data kunnen wijzen, terwijl onze OSM-tags nog op de geïmporteerde versie gebaseerd zijn. Dat zou dus snel leiden tot verouderde data.
  • We kunnen ons niet tot een reguliere refresh-cyclus toezeggen, dus zo’n URL zou een belofte impliceren die we niet kunnen waarmaken.

Roof shape
Je suggestie om naast hoogte ook roof:shape toe te voegen is interessant en we waarderen het, maar we zien dit als een apart onderwerp dat een eigen analyse en testen vereist. Voordat we ons hierop committeren willen we de mapping tussen 3DBAG roof attributes en OSM roof:shape waarden goed valideren. We zullen dit in een aparte werkstroom oppakken en komen erop terug.

Met vriendelijke groet,
Salim

32

Okay wat betreft source:height en source:height:date

Wat betreft roof:shape (en building:levels) taginfo maar eens gecheckt:

Ik heb ook de GPKG data dump maar eens binnen geladen met ogr2ogr /vsizip/3dbag_nl.gpkg.zip:

  • De 3DBAG data heeft 7 lagen
  • De pand laag heeft b3_h_maaiveld, b3_n_nok, b3_bouwlagen en de meeste andere velden
  • De lod12_2d laag heeft de b3_h_max en andere hoogte velden die niet in de pand laag zitten.
  • De lod12_2d laag heeft 10,783,944 rijen, 12397 meer dan de 10,771,547 rijen in de pand laag, waarom snap ik niet.

Het mooie van de bestaande data in OSM is dat je code kan schrijven om roof:shape en building:levels uit de 3DBAG data te genereren en die kan je dan tegen de bestaande OSM houden om te kijken hoe goed het overeenkomt.

Op de Wiki lees ik nog over b3_h_dak_max maar die kan ik niet vinden in de data.

1 Like
33

Hoi emvee,

Bedankt voor de zorgvuldige analyse, dat scheelt ons echt werk.

Je hebt gelijk: ik pas de attribuut-namen op de wiki aan (b3_h_max, b3_h_70p, b3_h_50p).

Over het rij-verschil tussen de lagen: pand is 1 rij per BAG-pand, lod*_2d 1 rij per gebouwdeel (via b3_pand_deel_id). Dat verklaart de ~12.000 extra rijen denk ik (ik hoop dat ik het goed heb).

Je validatie-idee (bestaande OSM-tags als ground truth voor afgeleide 3DBAG-waarden) is slim. Voor deze pilot blijven we strikt bij hoogtes, maar als er ooit een roof:shape of building:levels werkstroom komt, dan is dat precies hoe het zou moeten beginnen. Ik neem het mee.

Groeten, Salim

34

Hoi allemaal,

Op basis van alle waardevolle input van de afgelopen weken willen we een tweede, kleine pilot doen.

Scope: 1 3DBAG-tegel (10-434-712), 518 panden in Amsterdam Zuid (De Pijp / Rivierenbuurt).

Wat we importeren:

  • Alleen height=* op bestaande OSM-panden
  • Geen geometrie-wijzigingen, geen nieuwe panden
  • Bestaande height of building:levels worden overgeslagen
  • Filtering van 3DBAG-kwaliteitsindicator en de min-hoogte van 3m blijft staan

We blijven bewust klein: het idee is om de community feedback die we tot nu toe gekregen hebben in de praktijk te toetsen voordat we überhaupt aan grotere schaal denken.

Revert-belofte: als er iets niet klopt, draaien we het terug per changeset. De TTmechanicalupdates-account is dedicated, dus de scope is duidelijk.

Bijgevoegd:

  • De GeoJSON/CSV met het exacte importgebied
  • Een PNG met visuele context

Feedback of bezwaren zijn welkom, ook achteraf. Pas als hierop geen problemen blijken te zijn kijken we verder.

Groeten,
Salim

image-20260511-102416
image-20260511-102416713×577 260 KB

AMS_heights_import_tile_10_434_712.csv (67.1 KB)