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

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.

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.

2 Likes

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

Ohsome voor building:part

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.

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

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

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

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

2 Likes

Changeset 182242209 geladen in OSMCha en daar zie ik:

Screenshot_20260506_064820-1

Dat kan beter.

Drie tags toegevoegd:

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:

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

@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

“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

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

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

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

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

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


AMS_heights_import_tile_10_434_712.csv (67.1 KB)

Hoi allemaal,

Korte update op de tweede kleine pilot die we vorige week aangekondigd hebben: hij is afgerond.

Tegel 10-434-712, 518 panden in Amsterdam Zuid (De Pijp / Rivierenbuurt). Alleen hoogtes, op bestaande OSM-panden, volgens de conventies die we eerder in deze thread hebben afgesproken.

Changeset: Changeset: 182589231 | OpenStreetMap

Interne kwaliteitscontrole gaf een schoon beeld: attributen correct toegekend aan de objecten, hoogtes kloppen, en de source-tag in de changeset is nu correct (dit was een bevinding uit de eerste pilot die we hebben hersteld).

Een kleine technische observatie: upload duurde 2 seconden, wat sneller was dan we aan de OSM-kant hadden verwacht.

Feedback of zorgen zijn welkom. Zoals eerder: we draaien per changeset terug als er iets niet blijkt te kloppen.

Groeten, Salim

1 Like

Hoi allemaal,

Korte update over de 3D BAG hoogte import in Amsterdam, met een vraag aan @SimonPoole erbij.

De twee pilots zijn afgerond, geen reverts, geen klachten:

  • Pilot 1 (5 mei): 17 gebouwen, 5 changesets, verspreid over het testgebied (Amsterdam plus 2 polygonen in Weesp).
  • Pilot 2 (13 mei): 518 gebouwen in Amsterdam-Zuid (De Pijp / Rivierenbuurt), changeset 182589231.

Samen 535 gebouwen via het account TTmechanicalupdates. Alleen height tags op bestaande gebouwen, geen geometrie aanpassingen, geen nieuwe gebouwen, en geen bestaande height waardes overschreven.

We zijn klaar om door te gaan met de rest van Amsterdam, in 6 fasen. Per fase een aparte changeset of set changesets, 2 dagen tussen aankondiging en daadwerkelijke import, en een korte rapportage in deze thread na elke fase.

Fase Gebied Aantal gebouwen Risico Import QC eind Toelichting
0 Validatie + aankondiging .. .. 22.05 .. Wiki + forum / talk-nl bericht
1 Amsterdam-Noord + Nieuw-West 47.129 Laag n.t.b. n.t.b. Goede start voor opbouwen vertrouwen
2 Zuidoost + Westpoort + Weesp 22.313 Laag / Middel n.t.b. n.t.b. Voornamelijk wonen + industrie
3 Oost + West 32.383 Middel n.t.b. n.t.b. Dichter stedelijk weefsel
4 Zuid 20.113 Middel / Hoog n.t.b. n.t.b. Actieve OSM community in dit gebied
5 Centrum 14.115 Hoog n.t.b. n.t.b. Complexe gebouwen, extra monitoring
6 Schiphol omgeving 173 Speciaal n.t.b. n.t.b. Optioneel

Aantallen op basis van 21 mei. Er kan nog wat afvallen na een laatste cleanup voor elke fase. De data is afhankelijk van de uitkomst van de consultatie hierboven en de afronding van de waiver.

WAT WE WEL EN NIET DOEN

  • Wel: height tag toevoegen op bestaande gebouwen die nog geen height hebben.
  • Niet: geometrie aanpassen, nieuwe gebouwen toevoegen, bestaande tags overschrijven, of iets aanraken zonder ref:bag.

Per changeset is een revert mogelijk als er iets niet klopt. De wiki:

VRAAG AAN @SimonPoole

De CC BY 4.0 waiver voor 3DBAG ligt bij twee partijen: 3DGI (data engineering kant) en TU Delft (academische kant).

  • 3DGI: getekend, klaar.
  • TU Delft: de inhoudelijk verantwoordelijke heeft per e-mail bevestigd akkoord te zijn. De formele handtekening loopt nog bij de juridische afdeling en is een procedurele stap, geen inhoudelijke review.

Mijn vraag: ben jij akkoord dat wij met fase 1 starten op basis van de getekende 3DGI waiver plus de e-mail bevestiging van TU Delft, terwijl de formele handtekening wordt afgerond? Of liever wachten tot ook die binnen is?

Met toestemming van 3DGI deel ik graag de getekende waiver en een screenshot van de TU Delft e-mail, hier in de thread of via DM / e-mail, wat jouw voorkeur heeft.

Iedereen alvast een fijn Pinksterweekend!

Groet,
Salim (TomTom)


ENGLISH

Hi all,

Short update on the 3D BAG building heights import for Amsterdam, with a question for @SimonPoole at the end.

Both pilots are complete, no reverts, no community concerns:

  • Pilot 1 (5 May): 17 buildings, 5 changesets, scattered across the test scope (Amsterdam plus 2 polygons in Weesp).
  • Pilot 2 (13 May): 518 buildings in Amsterdam-Zuid (De Pijp / Rivierenbuurt), changeset 182589231.

Total so far is 535 buildings via the TTmechanicalupdates account. height tags only, no geometry edits, no new buildings, and no existing height values overwritten.

We are ready to continue with the rest of Amsterdam in 6 phases. Each phase is its own changeset or set of changesets, with a 2 day gap between announcement and the actual import, and a short report in this thread after each one.

Phase Area Buildings Risk Import QC end Notes
0 Validation + announcement .. .. 22.05 .. Wiki + forum / talk-nl notification
1 Amsterdam-Noord + Nieuw-West 47,129 Low TBD TBD Good area to build confidence
2 Zuidoost + Westpoort + Weesp 22,313 Low / Medium TBD TBD Mostly residential + industrial
3 Oost + West 32,383 Medium TBD TBD Denser urban fabric
4 Zuid 20,113 Medium / High TBD TBD Active OSM community in this area
5 City Center 14,115 High TBD TBD Complex buildings, extra monitoring
6 Schiphol area 173 Special TBD TBD Optional

Counts as of 21 May. A few may drop off after a final cleanup before each phase. The dates depend on the outcome of the consultation above and the finalisation of the waiver.

WHAT WE WILL AND WILL NOT DO

  • Will: add a height tag on existing buildings that do not have one yet.
  • Will not: edit geometry, add new buildings, overwrite existing tags, or touch anything without a ref:bag.

Each changeset can be reverted individually if something is off. Wiki page:

QUESTION FOR @SimonPoole : The CC BY 4.0 waiver for 3DBAG sits with two parties: 3DGI (the data engineering side) and TU Delft (the academic side).

  • 3DGI: signed, done.
  • TU Delft: the responsible academic contact has confirmed agreement by email. The formal signature is still going through the legal department, which is a procedural step, not a substantive review.

My question: are you comfortable with us starting phase 1 on the basis of the signed 3DGI waiver plus the TU Delft email confirmation, while the formal signature gets finalised? Or would you prefer we wait until that one is in too?

With 3DGI’s consent I am happy to share the signed waiver and a screenshot of the TU Delft email, either here in the thread or via DM / email, whichever you prefer.

Enjoy the long weekend everyone!

Cheers,
Salim (TomTom)

2 Likes

Salim if the project gets green light from Simone Poole & you once again have flawless results what checking tasks can I do for a flawless result for my home town: Haarlem as next city ?

I don’t have do be comfortable with anything, I haven’t had any formal function with the OSMF for half a decade not the least due to the complete failure of the foundation to fulfill its obligations under the regulation that had its 10th anniversary yesterday. But different topic.

It would be fine with me, but you need to ask the LWG.

Hello @Dillen_GJ , Good Morning, Goedemorgen

Ik kom bij jou en anderen terug over mogelijke samenwerking. Bedankt en een fijne zonnige week.

I will be in contact with you and others on potential collaboration.
Thank you and wish you a nice sunny week.

1 Like

Val er nu pas in, maar leuk onderwerp.
Voor de Amsterdamse panden handig om te weten dat de gemeente voor in de BAG het aantal bouwlagen opneemt (nu voor ca. 24.000 van de 200.000 panden). Zie Catalogus - Data en Informatie
Ik vermoed dat enkele andere gemeenten dat ook doen, maar dat zie je niet terug in de landelijke voorziening (LV) van de BAG.

@sbaido interessant om de (tussen-)resultaten op de komende foss4g-nl (8 en 9 juli in Groningen, zie https://www.foss4g.nl) aan een opbouwend-kritisch te presenteren?

1 Like