1

Zoals de titel doet vermoeden gaat het in dit stuk over gebouwhoogtes.
Misschien eerst maar even de vraag, zit iedereen te wachten op de implementatie van gebouwhoogtes in OpenStreetMap?
Ik zelf zie de dataset als een grote toevoeging voor het in 3d tonen van de gebouwen. Onder de architecten wordt het bijvoorbeeld gebruikt om een situatie snel te visualiseren.

In dit forumtopic (2015) werd er gesproken over gebouwhoogtes. Maar dit heeft niet geresulteerd in concrete implementatie.
Na schriftelijke toestemming voor het gebruik van de AHN Arcgis service lagen (1), kwam ik met een vraag over de gebouwhoogtes.
De gebouwhoogtes zijn immers gebaseerd op deze AHN lagen.
In de mailwisseling met Esri werd echter gezegd dat men tegenwoordig de berekeningen van de TU Delft gebruikt, zodat deze gecombineerd kunnen worden met hun eigen geometrie. (Wat vervolgens wordt omgezet in een door Esri aangedragen OGC 3D webformaat I3S.)
Logischerwijs kan Ersi ons geen toestemming geven voor het gebruik van deze gebouwhoogtes en verwees me door naar 3D BAG.

3D BAG heeft via de mail laten weten open te staan voor de impelentatie van hun dataset in OpenStreetMap. En hij is benieuwd hoe we dit aan gaan pakken.
Deze dataset valt onder de CC-BY licentie, ondanks deze CC-BY licentie is er overeenstemming om toch te voldoen aan de ODbl licentie van OpenStreetMap, zo hoeven de gebruikers geen attributie te geven.
Ten behoeve van de attributie wordt er alleen gevraagd om bij de bron “source=3D BAG by TU Delft” te gebruiken.

De gebouwgeometrie krijgt in dit geval als toevoeging:

Nu er een akkoord is kunnen we, mits de community dit wil, overgaan tot implementatie.
De 3D BAG wordt maandelijks geĂŒpdatet, de gebouwhoogtes zijn dus helaas niet gelijk beschikbaar met de BAG import.
Is er een mogelijkheid deze dataset toch te combineren met de BAG import (via de ref:bag=*)?
En zo ja / nee wie heeft er hier meer verstand van het implementeren van zo’n dataset?

-E de Wit

2

Het combineren is geen probleem. Zoals ik kan zien staan in de download van de 3D BAG ook alle identificatienummers van de panden erbij. Het moet makkelijk lukken om aan de hand daarvan voor ieder gebouw dat al in de OSM database staat de juiste 3D BAG hoogte te vinden.

Het vervelendste gaat zijn als gebouwen opnieuw geĂŻmporteerd worden. Dan moet de ingestelde hoogte er opnieuw opgezet worden. Zo nu en dan moet alles weer geĂŒpdate worden.

Gertjan Idema (https://forum.openstreetmap.org/profile.php?id=7207) heeft het importeren vanuit de BAG mogelijk gemaakt.

3

Ik heb hier wel een paar opmerkingen over.
Allereerst lijkt mij gebouwhoogte een goede toevoeging aan osm.

Source tag

Ik zou hier van maken:

source=BAG
source:height=3D BAG by TU Delft
height=*

Vragen
Ik ben benieuwd hoe je de data wilt importeren. Er schieten mij zo een aantal vragen te binnen waar op z’n minst over nagedacht moet worden voor we tot import overgaan: Denk je aan een grote eenmalige import of meer aan tools die mensen kunnen gebruiken om de data uit 3D BAG op te halen voor individuele panden? Hoe gaan we de data up-to-date houden? Hoe gaat dit het lopende BAG-update proces beïnvloeden? Is het misschien mogelijk dit als een extra functionaliteit in de BAG-update plugin van Gertjan op te nemen?

Kwaliteit
Als laatste punt is dat ik op de 3D BAG website een aantal ondergrondse gebouwen heb gevonden die hoger dan 21m zouden zijn. Ik heb de data niet heel intensief bekeken, dus ik kan geen goed oordeel over de datakwaliteit geven, maar als er veel van dit soort problematische gegevens in zitten die we er niet op de een of andere manier uit kunnen filteren, dan lijkt mij dit reden om de data toch maar niet te importeren.

4

Ik zou de bronvermelding van de data ook hier neerzetten:
https://wiki.openstreetmap.org/wiki/Contributors#Netherlands

Voor ondergrondse gebouwen zou je kunnen kiezen als ze bijvoorbeeld een layer<0 tag hebben ze geen hoogte krijgen.

Helemaal nauwkeurig zal je de gegevens nooit krijgen. De Westpoint in Tilburg als hoogste gebouw in de stad als voorbeeld genomen. De toren is zo’n 140 meter hoog. Maar het gebouw bestaat ook nog uit een parkeergarage (10m hoog) en een kleinere flat (35m hoog). Maakt niet uit wat voor hoogte je hier kiest, het geeft altijd een wat vertekend beeld van de werkelijkheid.

Maar goed, dit soort uitzonderingen zul je altijd hebben. Voor het merendeel van de huizen ziet er volgens mij prima uit.

Over het importeren:
De data is gebaseerd op het AHN en het lijkt dat het alleen update wanneer er nieuwe hoogtedata beschikbaar is. Dat lijkt eens in de paar maanden te zijn.

Voor gebouwen nieuwer dan de AHN data op die plek is de hoogte niet beschikbaar. Het importeren van de hoogte data is enkel nodig voor gebouwen die al in OSM staan.

5

Maar wat heb je nu aan zo’n height tag?
Ik kijk even naar mijn eigen huis. Een hoekwoning met asymmetrische kap. Voorgevel is 1 verdieping hoog, achtergevel 2. Wil je dat in 3D weergeven, dan moet je dus lengte, breedte, hoogte voorgevel, hoogte achtergevel, nokhoogte en plaatsing nok hebben.
Mijn huis is nog heel simpel. Er zit ook nog een dakkapel op en daarvoor heb je dus eigenlijk ook nog data nodig.
Maar veel gebouwen zijn veel ingewikkelder, dus een simpele height tag zegt - naar mijn idee - niets.
Om werkelijk 3D te kunnen weergeven, heb je volgens mij een hele dataset nodig, anders blijft het spielerei en aannames.
Voor 3D zijn er al tags in OSM, onder andere om een wolfseind aan te duiden. Maar dat is ook een voorbeeld, dat je echt flink wat data nodig hebt om zo’n wolfseind werkelijk goed weer te geven.

En dat is mijn bezwaar om nu weer met iets nieuws te beginnen, je moet werkelijk per pand een bak gegevens invoeren en hebben en onderhouden!
Dat laatste is nog veel belangrijker dan invoeren.
Invoeren lukt nog wel, maar het bijhouden, dat is veel lastiger.

Laten we ons aub concentreren op het goed krijgen en houden van het huidige OSM, dat is al lastig en moeilijk genoeg en daarvoor is eigenlijk al te weinig menskracht aanwezig.
Er zijn zat beginnende mappers, maar de meesten hebben het na een korte tijd al bekeken en verdwijnen weer.

Simpel voorbeeld.
Gisteravond heb ik een fietspad langs de Staverdenseweg bij Elspeet uitgelijnd met de BGT. Dan blijken ook de vlakken allemaal af te wijken en zo zit je zo een uur of meer te schuiven. En dan gaat het over maar een klein stukje OSM.
En ik vraag me af hoeveel mappers er werkelijk zin en tijd hebben voor zulke peuterklussen.
Als ik rcn en rwn routes repareer, kijk ik vaak ook naar de wegen/paden en als je ziet hoeveel er nog niet goed ligt, hoeveel tagging er nog gedaan moet worden, dan hou je je hart vast.

Persoonlijk heb ik momenteel liever geen tagging voor 3D in OSM.
Ook niet zaken als rooftype en ik weet niet wat meer.
Iemand verbouwt zijn pand en wie ziet dat het daktype gewijzigd is?

Nogmaals het onderhoud, daar gaat het vaak op stuk. Dat is het saaiste wat er is, maar wel het belangrijkste.

6

Ik sta volledig, zo niet: meer dan volledig achter de argumentatie van Dick. Niet doen!
Al zijn argumenten zijn waar.

De quote

is niet van toepassing op OSM.

Geen enkele architect zal een landen/werelddekkend OSM kunnen en willen gebruiken om de architectonische details van een gebouw te willen zien of aanpassen.

Kijk wat de algemene behoefte is van mensen die OSM gebruiken: fraaie kaart, routering, landgebruik, geografische elementen als rivieren en wegen, wegklasseringen etc. Vul daartoe alle nog ontbrekende of foute/verouderde informatie aan in OSM; liefst gebaseerd op waarneming in het veld of overduidelijke bronnen als PDOK/BGT.

Meer en meer zie ik dat beschikbare digitale bronnen gebruikt worden om rĂŒcksichtlos er op los te importeren zonder de vraag te stellen of de OSM-gebruiker er wat aan heeft, maar puur omdat het kan en de bevrediging schijnbaar komt uit het importeren zelf. Ik noem lantaarnpalen, hydranten, bomen


Zo bevat OSM ook in NL gebouwen die niet in de BAG staan: schuurtjes, romneyloodsen etc.

7

Deels met je eens. Zie het als:

citymodel_levelofdetail.png1139×270 78 KB

Waarvan iedere stap exponentieel meer informatie vergt om een kloppend gebouw te maken. (Waar LOD5 een “as built” gebouw is)
OSM bestaat uit LOD0 geometrie, waarvan met de dataset LOD1 gecreëerd kan worden zonder aanvullende complexiteit.
(Die complexiteit moet je zeker niet willen in OSM)
Het hoogtebestand is niets meer dan een extrusie van de BAG geometrie en zal dus bij sterk variërende hoogte binnen hetzelde gebouw 1 hoogte aan het gebouw koppelen. Dit valt helaas niet te voorkomen. Hoewel helaas onnauwkeuriger volstaat het nog steeds voor het gebruik van LOD1.
LOD1 heeft verder wel degelijk nut voor bijvoorbeeld een structuurontwerp (pdf). Dit komt zo goed als iedere keer voor in de tenderfase en voor het maken van benodigde visualisaties.
Het is erg jammer dat dit niet direct zichtbaar is op de OSM kaart, waardoor het nut en de informatie irrelevant lijkt.
OSM wordt echter wel regelmatig geraadpleegd voor van het creĂ«ren van (zonder “height=*”, incorrecte) LOD1 geometrie.

Hier ben ik het volledig mee eens en zie het liefst een import direct met BAG LOD0, waardoor er ook geen beroep wordt gedaan op extra mankracht.
In dit geval zal de implementatie traag gaan, maar gezien de AHN3 lagen niet snel geĂŒpdatet worden zal ook de gebouwhoogte niet plots veranderen.
Als dit los gedaan moet worden van de BAG import, dan worden het bijhouden en mankracht tekort zeer zeker een probleem. (En een mijns inziens onoplosbaar obstakel)

Ik praatte dan ook over het visualiseren en niet over het gebruik om ‘architectonische details’ te willen zien, daar hebben we onze eigen methodieken wel voor. Zie het antwoord op dvdhoven over het ‘nut’ van LOD1.

Valt het creĂ«ren van een 3d map met OSM data als basis ook als een “OSM-gebruiker”?
Zo ja, dan heeft de “OSM-gebruiker” wel degelijk wat aan de dataset om een betere 3d kaart te genereren.
Denk bijvoorbeeld aan tools als SketchOSM (SketchUP).
Of rendering software die OSM als import mogelijkheid hebben (Twinmotion) (Lumion) (Unreal).

-Uiteraard blijft de consensus binnen de community van doorslaggevend belang.

8

Los van 3D-tags is hoogte is een belangrijke en veelzeggende parameter. Een bungalow is toch wel iets heel anders dan een flatgebouw. Het enige criterium is of de gegevens betrouwbaar zijn. De weerstand lijkt meer gebaseerd te zijn op opvattingen over 3D dan over de betreffende gegevens.

9

Inderdaad: de eendimensionale benoeming van de hoogte d.m.v. height=* zou je kunnen toepassen om echt hoge (flat)gebouwen anders te renderen in de standaard-rendering.
Zoals dit ook op bijvoorbeeld de Nederlandse topo gebeurt.
Dit is zinvol, want een hoog gebouw kan in het veld een ‘landmark’ zijn voor bijvoorbeeld oriĂ«ntatie.

Noem dit 2.1D-mapping. Bij BAG-updates blijft die height-tag, mits het zorgvuldig gebeurt, behouden.

Bij het ontbreken van de height-tag kunnen we dan uitgaan van laagbouw.

Een volledig arbitrair voorstel voor hoogbouw: height>35?

Dit betekent dat we dus niet alle hoogtes van alle gebouwen lukraak gaan importeren. Imho een onnodige databasebelasting.

Off-topic: nu weet ik wat een wolfseind is :slight_smile:

10

Dat 3D in de titel staat betekent niet dat de hoogte gerenderd moet worden, zoals bijvoorbeeld ook het bouwjaar niet wordt weergegeven noch gebruikt voor navigatie.

11

Ik ben in principe vóór mits het (zo goed als) volledig geautomatiseerd is, en hoogten die door mappers zelf worden ingevoerd niet automatisch overschrijft (zowel al bestaande hoogten als hoogten die later worden aangepast door mappers). In tegenstelling tot imports van andere ruimtelijke data is deze eendimensionale hoogte gekoppeld aan een BAG Pand ID veel makkelijker te automatiseren.
Ik denk dat het dan beschouwd kan worden als mooie extra data, die amper onderhoud nodig heeft omdat het geautomatiseerd wordt bijgewerkt. De database belasting zal denk ik niet echt meer zijn dan de bouwjaren die we er ook al in hebben zitten, en of bouwjaren nou veel nuttiger zijn dan LOD1 gebouwmodellen


12

Dit is inderdaad hoe ik het bedoel.
Het kwaliteit van het bouwjaar is overigens ongeveer gelijk aan die van de hoogte.
(waar bijvoorbeeld Vijversburg als bouwjaar 1930 heeft, samen met het nieuwe paviljoen in Ă©Ă©n geometrie.)

KiaaTiX heeft aangegeven te kunnen helpen met een plug-in voor JOSM die de import volledig automatisch laat verlopen.
Met de voorwaarden ben ik het volledig eens en dit zal meegenomen moeten worden.

Niet OSM gerelateerd, maar toch 1 van mijn favoriete kaarten om zien voor het gebruik van bouwjaren :slight_smile: : https://code.waag.org/buildings/