Talk:BAGimport

From OpenStreetMap Wiki
Jump to navigation Jump to search

Onderstaand een agendavoorstel voor de meeting over de import van de BAG op zaterdag 16 november in Utrecht. Je punten bij voorkeur bij de onderwerpen invoegen om de discussie overzichtelijk te houden.

De agenda, een beschrijving van een import en een vergelijking met diverse imports kun je hier downloaden: BAGimport


2013-2014 BAG import Nederland

Waarom willen we data uit de BAG importeren

  1. Routing
  2. Osm.org
  3. Niet nodig, kan ook via bypass (Nominatim, adresbestand tbv mkgmap) en het kost enkele vrijwilligers heel veel tijd
  4. Risico dat OSM over enkele jaren met een adres- en pandenlayer gaat werken waardoor deze import overbodig wordt

Meeting NL community: 16-11-2013: wel importeren. Er is open data. Je houdt niet tegen dat mappers deze data gaan importeren. Als er geïmporteerd wordt kun je beter een standaardmethode hebben voor het importeren. Importeren is nuttig voor routeren. Adresinfo is een toevoeging op de huidige info. De BAG panden zijn nuttig omdat de kwaliteit veel hoger is dan de 3DShapes.

Welke data uit de BAG willen we uiteindelijk in OSM hebben.

  1. Panden/standplaatsen/ligplaatsen, en zo ja welke (alleen panden in gebruik?)
  2. Adressen
  3. verblijfsobject
  4. Welke velden

Meeting NL community: 16-11-2013: Panden, adressen, ligplaatsen, standplaatsen. Gebruiksfunctie (vbo) tag bag:gebruiksfunctie. Panden: bouwjaar en bagid (volledig). Adressen: straat, huisnummer, postcode, woonplaats. Source BAG extract 01-09-2013

In een pand of standplaats of ligplaats bevinden zich verblijfsobjecten. Verblijfsobjecten hebben een postcode, huisnummer, huisnummertoevoeging en een huisletter voor het hoofdadres (en mogelijk nevenadres). Deze verblijfsobjecten zijn gekoppeld aan een straat (zgn. openbare ruimte) en een woonplaats. Zo kunnen uiteindelijk een volledig adres worden samengesteld.

Hoe willen we de data uiteindelijk in OSM hebben.

  1. één pand één adres: adres op pand of of losse node
  2. één pand twee of meer adressen (flats/appartementen): individuele nodes of mergen?
  3. willen we tags voor id's (voorstel: nee, niet onderhoudbaar en ook niet robuust. De combinatie straatnaam/huisnummer/toevoeging zou uniek moeten zijn in een woonplaats)
  4. welke tags
  5. postcode met of zonder spatie (BAG: zonder)
  6. associated:street relation wel of niet (BAG: niet in voorzien)
  7. Hoe gaan we om met ondergrondse of overlappende gebouwen.
  8. building=yes voor alle panden of uitsplitsen naar BAG gebruiksdoel (bv building=residential voor "woonfunctie")
  9. idem, maar hoe omgaan met meerdere gebruiksdoelen binnen één pandcontour

Meeting NL community 16-11-2013: Eén pand én adres: losse node. Want: informatieverlies. Adresnode staat al in de buurt van de voordeur. Eén pand meer nodes: nodes los. Postcode: zonder spatie. Geen associated street. Lastig voor mappers, zeker beginnende. Overlappende gebouwen: overlap verwijderen. Ondergrondse gebouwen: handmatig checken.

Hoe krijgen we data in OSM (hier kunnen verschillende scenarios naast elkaar gebruikt worden.)

  1. Genereren en klaarzetten van .osm bestanden per gemeente/woonplaats/ander gebied en/of per bouwjaar/periode.
  2. Rechtstreeks met bijvoorbeeld Josm uit een webserver halen voor kleine gebieden
  3. Bulk import (erg weinig voorstanders)
  4. Panden en adressen tegelijk invoeren/eerst adressen dan panden/eerst panden dan adressen
  5. Wat doen we met huidige adresdata op gebouwen en/of POI’s
  6. Vervangen en aanvullen in één changeset
  7. ook binnen de scenarios kan je stappen opsplitsen. Zo kan je bijvoorbeeld eerst panden en adressen onafhankelijk van elkaar toevoegen, om vervolgens met een scriptje daar waar mogelijk adressen aan panden te knopen.
  8. Wie wil importeren
  9. Hoeveel maanden/jaren vinden we gewenst voor de import van heel Nederland


Het project NLExtract is heel relevant als tool om de BAG in te lezen. Het is namelijk open source en op het forum er wordt veel informatie gedeeld over de BAG. Wij hebben er zelf al veel ervaring mee. Met deze tool kan de BAG in 1x in een PostGIS database worden geladen. Hier kan de pre-processing worden gedaan, waarna een export naar OSM-bestanden moet worden bedacht. Bijv: PostGIS --> Shape --> OSM?


Q: Ik ben op zoek gegaan naar een mogelijkheid om de BAG panden te schonen van overlappende gebouwen, en dat blijkt te lukken met GRASS omdat die een topological model blijkt te gebruiken die geen overlaps toestaat. Kunnen die overlappende gebouwen ook in PostGIS automatisch verwijderd worden?

A: PostGIS heeft een functie ST_Intersects, waarmee je kan achterhalen of objecten elkaar overlappen.

Q: in Qgis is het mij niet gelukt om nodes te verbinden aan de gebouw shapes. Het gaat namelijk fout bij alle gebouwen die meer dan 1 adresnode hebben. Kan PostGIS dat wel foutvrij uitvoeren?

A: Er is in de BAG een koppeltabel, waarin een relatie wordt gelegd tussen welke verblijfsobjecten zich in 1 of meerdere panden bevinden. Aangezien we van zowel de verblijfsobjecten en van de panden/ligplaatsen/standplaatsen een geometrie hebben, kan er in PostGIS vast wel een relatie worden aangemaakt tussen de nodes en de polygonen.

Q: Ik heb gemerkt dat gebouwen op grensvlakken problemen opleveren. Heeft PostGIS een slimme instelling om gebieden te alloceren, waarbij het ook mogelijk is om exact hetzelfde gebied in JOSM te downloaden (cq uit te snijden uit een Geofabrik extract?)

A: Hmmm... snap hier je punt denk ik niet helemaal. We doen meestal heel NL.

Hoe gaan we om met updates.

  1. Hebben we ID tags nodig, of kunnen we volstaan met vergelijken van geometrieen en tags.
  2. Hebben we versie tags nodig, of zijn er andere manieren om te zie of OSM data nieuwer is dan BAG data

Een van de nieuwste ontwikkelingen rond NLExtract is, dat er nu functionaliteit is om maandelijkse updates te kunnen verwerken. Omdat dit kleinere bestanden zijn, is het zeer snel om de maandelijkse updates te verwerken naar PostGIS.


Communicatie

  1. Forum/talk/email
  2. Import mailing list
  3. Importpagina
  4. Mappers die al adressen/panden gemapt hebben
  5. Newbie communicatie NL:Beginners'_guide aanpassen (wat is er al in NL, do’s en dont’s)


Volgens mij hebben we dan heel wat technische problemen voor een groot deel te pakken. De grootste uitdaging is de communicatie: niet alleen met OSM-mappers die al gebouwen en adressen hebben toegevoegd, maar ook met gemeenten die OSM kunnen gebruiken als mutatiesignalering. Dit is ook al opgezet voor New York op basis van de PLUTO-database. Kadaster is ook bezig met een onderzoek om OSM te gaan gebruiken voor mutatiesignalering. Momenteel is er ook een BRT-terugmeldpilot gaande.

Q: Die mutatiesignalering spreekt me ergens aan (zeker ook omdat we de community dan uitbreiden naar gemeenten) maar lijkt me ook ergens heel erg lastig. Ik heb heel veel BAG attributen in mijn gemeente gewoon weggegooid omdat ze voor OSM niet relevant zijn. Met het verwijderen van overlap van gebouwen creëer ik al verschillen. Daarnaast heeft elke adresnode een LAT/LON. Mochten we de adressen samensmelten met de gebouwen, dan verschuift de LAT/LON. Zie ook deze discussie: https://lists.openstreetmap.org/pipermail/imports/2013-October/002275.html. Dit creëert dus mutaties, puur omdat de OSM community andere definities hanteert dan de in BAG gebruikte topologie. Hoe zie jij een mutatiesignalering voor je?

A: Zodra er veranderingen plaatsvinden in OSM aan een gebouw, dan wordt dit gesignaleerd. Verschuiving van een LAT/LON-paar bij adressen lijkt me idd niet echt relevant voor een mutatiesignalering.

Tools

  1. JOSM-openservice plugin
  2. GEON / Qgis
  3. JOSM validator / OSM Inspector address view
  4. Task manager [1]
  5. Verschillen tussen BAG en OSM inzichtelijk maken
  6. Inzichtelijk maken hoeveel BAG data is geïmporteerd in een gebied. In Estonia user:Svimik used a progress tool: [2] and an import tool: [3]. Nantes address integration (FR) available and also in use for Lyon
  7. NYC script to convert addresses to buildings (+ other things) [4]


Feedback van fouten naar BAG database

  1. Handmatig via webform terugmelding

Move this page to dutch namespace on the wiki

Shouldnt this page be under the dutch namespace? That would also make it possible to create an english page explaining what this is. FredrikLindseth (talk)