Start_date=1900 bij oudere gebouwen

Naast gesloopte gebouwen bevat de BAG bevat ook niet-gerealiseerde gebouwen en gebouwen met een bouwvergunning die nog niet in OSM staan.
De Voortgangsrapportage meldt 11797K panden totaal, 259K ontbrekend in OSM en 177K gesloopt, maar nog niet verwijderd uit OSM.
Bij het totaal van 11797K staan blijkbaar ook nog de gesloopte, niet gerealiseerde etc.

De BAG status kolom biedt de volgende informatie:

status;identificatie
Bouw gestart;48314
Pand in gebruik;10665840
Niet gerealiseerd pand;114600
Pand gesloopt;891334
Bouwvergunning verleend;85110
Pand buiten gebruik;499
Sloopvergunning verleend;16255
Verbouwing pand;36654
Pand in gebruik (niet ingemeten);21936
Pand ten onrechte opgevoerd;42614

Er zijn 10.875K BAG panden met een status anders dan ‘Pand gesloopt’, ‘Niet gerealiseerd pand’ of ‘Pand ten onrechte opgevoerd’.
Jij hebt 10.800K gebouwen met “ref:bag” gevonden in OSM. Na verrekenen van de achterstand kom ik op 10800 + 259 (ontbreekt volgens voortgangsrapportage) - 177 (gesloopt, maar nog in OSM volgens voortgangsrapportage) = 10.882K. Dat komt dus aardig in de buurt.

De ruis zal onder anderen zitten bij ‘Pand ten onrechte opgevoerd’. Die status bestond nog niet toen de BAG import plug-in gemaakt werd. Een deel van deze panden valt wel binnen de OSM definitie van een gebouw. Of we dan “ref:bag” moeten verwijderen of laten staan durf ik niet te zeggen.
Ook lig- en standplaatsen kunnen verschillen opleveren. Heb jij die mee geteld?

Inderdaad. Toevoegen van de status als tekst veld helpt dan ook niet :wink: Tijd voor een database oplossing.

Ik had geen idee dat het zo ingewikkeld zou zijn. Ben zeer onder de indruk ook al kan ik t niet meer allemaal volgen.

Een gebouw zonder start_date kan ook een woonwagen (building=static_caravan) zijn. Waarschijnlijk geldt dit ook voor een woonboot.

Alle objecten met de tag “ref:bag” zijn mee geteld.

Heb nog wat optimalisatie gedaan. Ik kan nu alle 10M osm objecten met alle tags die deze objecten hadden samen met de BAG objecten met status en bouwjaar verwerken met een maximaal geheugengebruik van 3.4GB. Daarvoor was dat rond de 14GB.

Ik was zelf van plan om nog een extra forum post over te maken om te kijken hoe het updaten van al deze start_date’s het beste gedaan zou kunnen worden, maar ik zag dat @CartoKees hier al mee bezig was op de kaart. Erg mooi om te zien hoe snel mensen dit doen. Maar nu weet ik niet wat het slimst is om hier mee verder te gaan. Laat me weten wat jij denkt dat het beste is, en of je hier hulp bij kunt gebruiken.

1 Like

Ik weet niet wat in zijn algemeenheid werkt. Ik kan wel vertellen wat voor mij werkt in een aantal stappen:

  1. Uit de bouwjaren analyse heb ik een selectie gemaakt waarvan ik bijna zeker wist dat het klopt (bijvoorbeeld een start_date heeft vier getallen in OSM.
  2. Deze selectie heb ik opgeknipt in GeoJSON bestanden van 750 panden en in regio’s. Dit voor gemak, overzicht en makkelijke verweking.
  3. Het GeoJSON geopend in JOSM en gebruikt voor downloaden van OSM panden en de nieuwe bouwjaren naar OSM overgezet.
  4. Uploaden resultaat
  5. De uitzonderingen uit stap 1. Bekijk ik 1voor 1 en pas handmatig aan

Bij elke stap controleer/check ik gegevens/kaart of het nog klopt wat er gebeurt en niet iets verkeerd gaat. Of er toch niet een uitzondering is. Of er iets opvalt. Als het verkeerd lijkt gegaan te zijn, dan stop ik. En begin opnieuw.

Door stukje voor stukje te doen is uiteindelijk alles gedaan. Als ik dit vol blijf houden is het vooral tijd investeren.

De analyse van @Thiskal helpt als controle of ik niet een deel vergeet of per ongeluk compleet verkeerd aanpas.

Heb je ook meer info over dat Geojson gedeelte? Hoe krijg je die betanden?

Ik gebruik ETL (Extract Transform Load) GIS-software om de data te bewerken en weg te schrijven als GeoJSON. Op zich zou dit ook met QGIS moeten kunnen, maar dan als handmatige stappen. Hoe en of Python dit ook kan, weet ik niet.

Voor de data zorg ik dat de geometrie van het pand uit OSM in de GeoJSON komt. Verder koppel ik aan elk pand een regio en een x-coördinaat. En een volgnummer voor een pand per regio (na sorteren op regio en coördinaat). Het volgnummer gedeeld 750 en afgerond naar beneden zorgt ervoor dat het geheel op is te splitsen in bestanden van 750 panden per regio.

oor het opknippen en sorteren. Doe ik drie dingen: 1. Panden koppelen aan een GIS bestand met regio’s/provincies 2. ik bapaal per pand het middelpunt, de x-coördinaat gebruik ik voor het opknippen. 3a Ik sorteer alle panden op regio en x-coordinaat. Vervolgens

Afgelopen week heb ik de laatste bouwjaar verschillen tussen BAG en OSM opgelost. Natuurlijk zijn er een aantal uitzonderingen, die heb ik laten staan.

Een mooie test zou zijn als @Thiskal zijn scripts draait. Als er dan weinig verschillen zijn, dan is het goed gegaan.

4 Likes

Helemaal top om te horen.

Ik ben momenteel op vakantie. Maar volgende week ben ik weer terug. Ik zal dan eens kijken.