Het doel is om ontbrekende height=* en/of building:levels=* tags toe te voegen aan gebouwen, gebruikmakend van de juiste bronnen. We trappen af met een selectie in Amsterdam, met de intentie om dit in de nabije toekomst uit te breiden naar andere gebieden.
Gebouwhoogtes in OSM zijn waardevol voor diverse toepassingen, zoals 3D-routering, stedelijke planning (digital twins), dronevluchten en overstromingsmodellen.
Hoe de taken zijn opgezet:
De taken zijn gegenereerd door gebouwen te filteren die zowel height=* als building:levels=* missen. De hoogtes zijn berekend op basis van de 3D BAG dataset via:
height = b3_h_dak_max − b3_h_maaiveld (gemeten van de hoogste dakwaarde in LoD2.2 tot aan het maaiveldniveau uit de AHN-puntenwolk).
De berekende hoogtewaarde staat telkens al in het instructiepaneel van de taak.
Het aantal verdiepingen (building:levels) maakt strikt genomen geen deel uit van deze automatische berekening, maar kan worden toegevoegd op basis van “street level Imagery sources” of andere open bronnen als je dat wilt.
Vraag over “Source Tag”: We horen graag welke source-tags jullie aanraden voor deze bewerkingen. Laat ons weten welke specifieke tags jullie voorkeur hebben.
Voorlopig staat de challenge op het niveau “Expert”, omdat enige kennis van de onderliggende datasets vereist is. We staan er echter voor open dit aan te passen op basis van jullie suggesties.
Markeer taken zoals altijd als “Already Fixed” of “Not an Issue” waar van toepassing.
Reageer gerust hieronder of neem direct contact met me op.
Not Google StreetView surely? Because this is not permitted and would open up OpenStreetMap to legal liability.
The Google Maps Terms of Use explicitly forbid using Google Maps content - both map data and Google Street View - for making any other content. This includes using them for OSM mapping.
(c) No Creating Content From Google Maps Content. Customer will not create content based on Google Maps Content. For example, Customer will not: (i) trace or digitize roadways, building outlines, utility posts, or electrical lines from the Maps JavaScript API Satellite base map type; (ii) create 3D building models from 45° Imagery from Maps JavaScript API; (iii) build terrain models based on elevation values from the Elevation API; (iv) use latitude/longitude values from the Places API as an input for point-in-polygon analysis; (v) construct an index of tree locations within a city from Street View imagery; or (vi) convert text-based driving times into synthesized speech results.
So, what is stopping you from coordinating with the BAG plugin developer and the wider Dutch community to see if this can’t be automatically imported? Is the data not accurate enough? Doing this by means of user challenges seems like a massive waste of effort. Do you know how many building=* the Netherlands has?
My thoughts exactly, and the BAG import plugin idea as well, if the BAG has this info in a usable way. I for one am not going to participate in this challenge, because I can’t see the end of it.
Vraagje: hoe tel je de levels bij een dijkhuis? (1 ingang bovenop de dijk naar een woonlaag die boven de dijk uitsteekt, en 1 ingang aan de polderkant naar de woonlaag die tegen de dijk aangebouwd is).
Als ik moest kiezen, zou ik de polderlaag als bovengronds level meetellen.
Good point @JeroenHoek
we did have a brief conversation with the BAG plugin maintainers, and our understanding is that there is currently no current capacity to implement height in the BAG plugin, whether due to time constraints or technical limitations. however, if this thread helps for a broader case or discussion for it and a clear need, I think it would be worth exploring how we together with the community might be able to support that effort in some way. We’d love to hear any thoughts on that.
@JeroenHoek Yes, the number of buildings is indeed enormous. I have looked at the BAG quite a few times already, which is actually what got me thinking about how building heights could realistically be implemented if the BAG plugin development might not be possible.
@Peter_Elderson valid point, the selected area with the MapRoulette challenge as mentioned was my way to seek your consultation and see how to add the height information is possible with the possible either technical, time or any other limitation/s.
I’ve had a look at the list BAG details of buildings, and I think only a few details are required or wanted for most buildings. All the details which mappers can not see when looking at the building, are not eligible, I think.
However, I only looked at what the 3D BAGviewer offered, and I did not fully understand exactly what each attribute means. Height, I did not see that. I did see a number of levels, but I don’t know how this number is counted, in relation to underground floors and attic floors.
Een initiatief als dit zou eigenlijk of via een import moeten gaan, of via integratie met de BAG-plugin. Als de BAG-plugin niet doorontwikkeld kan worden of geen tijd kan schenken aan dit initiatief, is een import een geschikte oplossing.
Het is onzinnig om dit in StreetComplete te gooien. Mensen die van die tool gebruik maken verwachten iets nuttigs te doen, maar als je voor elk gebouw in Nederland (ik ga niet eens opzoeken hoeveel dat er zijn) gaat zitten vragen of de hoogte die je uit een specifieke bron haalt correct is… De enige reden die ik daarvoor kan ik bedenken is omdat het gratis arbeid is als je zulke data zo graag in OSM wil hebben, alleen kun je nooit opschalen naar een landelijke dekking (of zelfs heel Amsterdam) en claim je aandacht die beter naar andere taken had kunnen gaan.
Of de data is kwalitatief goed genoeg om te importeren (aannemelijk in dit geval), of niet en dan kunnen we er niet zoveel mee.
Voor verdiepingen zou je wel zulke taken kunnen aanmaken, maar ook dan zie ik niet hoe je in de buurt van een beetje redelijke dekking kan komen.
If the BAG-plugin is accepting outside contributions, consider submitting a patch.
If this is not possible (and that is totally up to the maintainer), then:
Ik zie wel een voordeel om het in StreetComplete te gooien.
Als ik een wijk wil complementeren en een survey wil doen dan kan ik enkele huizen/appartementen/gebouwen met StreetComplete invoeren waarna ik de rest van het rijtje/blok kan bijwerken door de data van dat ene gebouw te kopiëren.
Agreed with the others that doing this via MapRoulette is not the way to go, given the data is already available per BAG object an import is the only good option if you want to get some coverage.
Anyone who has a serious desire to make building heights/levels complete should make sure there is a map available that shows for every building if it has the required data or not. With that you can get an overview of what is needed.
Salim to support your building:level request I will add in residential construction areas the website:map key from now on, so as soon as the building(s) are completed this info can be implemented. Example
Het gebouw staat al in OSM (onder constructie) waarom dan een link aan het gebouw toevoegen naar een pagina met info, terwijl je die info ook direct op het gebouw kan invoeren?
Ik heb wat ervaring opgedaan door de 3D mapping voor mij buurt bij te werken, building:levels, roof:shape (95% flat), roof:levels, building=shed/house/apartments, building:part. S&P Oblique is zelfs handiger dan een survey.
Gebouwen met maar één niveau hebben zijn simpel en snel, maak een selectie met Lasso select, selecteer vervolgens alleen de gebouwen (en niet de nodes etc.) met Ctrl-+F building=* + “find in selection” en werk dan de tags voor alle geselecteerde gebouwen bij..
Voor gebouwen met verschillende niveau lijkt de makkelijkste method te zijn:
Eerst de bestaande outline over te trekken met F (Follow Line) daarop building:part=yes/house/school/*, building:levels, roof:shape, roof:levels.
Daarna een lijn tekenen op de grens van twee delen
Lijn en het building:part object selecteren en dan op te splitsen in twee objecten met Alt-x (Split Object)
Vervolgens het deel dat andere tags selecteren en de tags bijwerken
Eventueel herhalen vanaf stap 3 wanneer er nog meer delen zijn
I think updating the 3D tagging is not something that should be part of the BAG plugin as the BAG plugin is mainly for new objects and the 3DBAG data is based on AHN, that data is only acquired quite some time after the object has been build/changed.
A separate 3DBAG plugin would make sense to me. It should provided the functionality to get the 3D tagging for all the selected buildings. Under the hood the plugin should send the BAGID’s to a server that has the preprocessed data and the pluging data should combine that data with the selected buildings after which the user can review things and upload the data.
I think we should shoot to more than height and building:levels:
Also buildings that have multiple levels should be supported using building:part
Also roof data should be added, roof:levels and roof:shape and preferably roof:direction
That will need development, maybe something some the 3D geoinformation group of the TU Delft can help with?
Would be nice to make a Wiki page with example buildings, een link to the BAG OSM data, the 3DBAG data, a photo and the resulting 3D tagging.
@emvee : Thank you for the suggestions and the really valuable input on how 3D tagging can work in OpenStreetMap.
I have already reached out by email to the TU Delft 3D Geoinformation group to explore whether they can support this and I am also waiting to hear back from community members working on the BAG plugin to get their take on the best approach.
The Wiki page idea also makes a lot of sense to me. I would love to see if this is an effort we can maybe contribute to
my ongoing work on importing SIOSE Landuse/Landcover in Spain [3]
Although all different datasets, these approaches have in common that the data to import is “pre-cooked”, i.e. converted into OSM-importable files like “mutation files”. That is not to say that this should result in automated bulk imports. The conversion files (.osm) are divided in some way, e.g. per municipality, or grid, or in our case maybe per neighborhood (CBS Buurt) and usually imported as a Layer in JOSM.
The Spanish Import of Buildings and Addresses [1] generates these pre-cooked .osm files via a conversion API. Then a website to create projects [4] (usually import per municipality) for a vanilla (unmodified) HOT Task Manager “Gestor de Tareas” [5]. HOT TM can also work with polygons i.s.o. the usual “grid squares”. This creates a structured way of working with progress measurement. At least more than StreetComplete, MapRoulette, and sorry to say: the very ad-hoc updating of BAG data on forum requests using the BAG-plugin.
Off course the above conversion-functionality, and more, is also internal within the BAG Plugin, only the HOT-TM approach allows to work in JOSM without specialized plugins. JOSM is launched from within the HOT TM per-area with the small .osm dataset as a separate Layer. The import is then largely manual also to deal with ‘conflation’.
The Spanish Buildings btw already have basic 3D info, like building:part according to the general OSM 3D Buildings conventions [6].
Ok, the above may be a bit hard to grasp but in the simplest workflow one could generate offline Tasks per area with small “OSM Change” files for JOSM to add basic 3D info to existing building=* Ways in OSM based on BAG 3D data. Using an instance of the HOT TM will make it more structured though.
