Idee om wat met BAG te gaan doen

Op 16 november wordt een meeting gehouden over het importeren van de BAG, met de bedoeling om dan besluiten te nemen over die import. Als je een mening hebt over het importeren van adressen en panden in Nederland
kun je die, bij voorkeur dus voor de 16e, kwijt op http://wiki.openstreetmap.org/wiki/Talk:BAGimport

Vandaag heeft een meeting plaatsgevonden over de BAG. Aanwezig waren Olé, Colin, Nick, Frank, Bas, Peter, Gert-Jan, Gertjan, Myckel, Oliver, Floris, Ruud en Johan. Resultaten kun je vinden op http://wiki.openstreetmap.org/wiki/Talk:BAGimport. De komende weken gaan diverse deelnemers aan de meeting testen of de gemaakte afspraken uitvoerbaar zijn.

Cheers, Johan

Ik ben gisteren begonnen om een Import van Bag te maken.

Stap 1: Contact opnemen met mappers die al adressen hebben toegevoegd. Afgelopen zaterdag heb ik me redelijk kunnen oriënteren op de BAG-meeting. De mogelijkheden zijn me in grote lijnen duidelijk geworden.

Stap 2: Download recente versie van de BAG is afgerond

Stap 2.1 Exporteer BAG naar SHP met GEON Bag Extract conversie 4.0 is afgerond

Stap 2.2 Panden SHP bewerken (juiste velden en validator proof maken) voor import in OSM, hier heb ik een vraag over.

[alleen het atribuut BOUWJAAR en GEBR_DOEL1 zijn nuttig]
Vraag:
De kolom GEBR_DOEL1 in de** Panden1 layer** is bij mij niet aanwezig in pandenvbo.shp, doe ik misschien iets fout?
Deze kolom is wel aanwezig in de vbo layer, maar ik neem aan dat het in de pandenvbo.shp hoort te zitten.

Vanaf hier wordt een sprintje getrokken, en ik kan hier helaas niet bijblijven.
Vanaf de sectie h) is meer informatie gewenst.

Er wordt bij j) verondersteld dat je de grass plugin kunt openen.

Mapset Openen … plugins → grass → mapset openen, je krijgt nu een dialoogvenster om een GRASS-mapset te openen. Maar via welk pad, waar staat deze mapset en hoe heet het? (zie afbeelding)

Dit is een erg omslachtige procedure die ik niet kan aanraden om een import mee te doen. De tools die in ontwikkeling zijn leveren kant en klare data voor OSM aan zonder dat je nog alle conversie slagen zoals in deze experimentele procedure van It’s so funny moet doen.

Is er iemand die mij een .osm file kan aanleveren voor een gemeente?

Graag nog enkele weken geduld Commodoortje, ik moet de afgesproken tagging nog netjes uitwerken op de Wiki en een Engelse versie via de importlijst laten checken (dat lukt me pas over een paar dagen, ik heb het taggen van de Filipijnen voorrang gegeven). Pas na de comments op de importlijst kunnen we aan de slag gaan met de BAG (ik schat na Sinterklaas). Hopelijk zijn de preprocessing tools dan ook wat verder.

Cheers, Johan

Mijn bedoeling was niet om druk te leggen, natuurlijk heb ik geduld, ik wacht rustig af.

Beste BAG collega’s,

Naar aanleiding van de bijeenkomst op 16 november heb ik nog een wijzigingsvoorstel en een aanvulling. Ik weet niet zeker of dit de juiste plek is om dit te posten, maar de wiki is dat volgens mij ook niet.

1: source versie.
Het huidige voorstel is nu om de bron (bag-extract) versie vast te leggen in de source Tag: (“source”=“BAG extract 01-09-2013”).
Dat heeft in mijn ogen een paar nadelen, waarvan de grootste is dat het niet echt gestandaardiseerd is.
Mijn voorstel is: “source”=“BAG”, “source:date”=“2013-09-01”
Ten eerste is de “source:date” tag een behoorlijk breed geaccepteerde osm standaard: http://wiki.openstreetmap.org/wiki/Key%3Asource%3Adate en ten tweede geeft het minder kansen op verwarring met de data. Voor een nederlander is “01-09-2013” 1 september, maar OSM is een internationale site, met engels als hoofdtaal. Dan wordt “01-09-2013” het al gauw gezien als 9 januari.

  1. complexe gebouwen
    Voor complexe gebouwen als ondergrondse parkeergarages met woontorens er op, of bijvoorbeeld het hoofdkantoor van de rabobank in Utrecht stel ik voor om gebruik te maken van de “building:part” tags. De omtrek van het gehele gebouw worden dan getagd met building=yes en hebben de zelfde countour als in de BAG. Bij vergelijking is het dan hetzelfde gebouw. Delen binnen het gebouw met andere eigenschappen kunnen apart aangegeven worden met andere attributen.
    Als voorbeeld heb ik dat gedaan met dit gebouw: http://www.openstreetmap.org/?mlat=52.08172&mlon=5.11907#map=18/52.08172/5.11907&layers=N, maar zoals je ziet wordt dat niet gerenderd door mapnik. Vergeet ik een tag? Of wordt dit niet ondersteund door mapnik?

+1. Ik ben ook geen voorstander om de BAG extract datum in de source tag op te nemen. Een aparte tag voor de extract datum zoals de voorgestelde source:date of bag:extract zoals door de bag4osm osmosis plugin werd gegenereerd heeft mijn voorkeur.

De BAG building had layer=-1 = yes als tag, dit heb ik aangepast naar layer=-1. Dit lijkt echter geen effect op de rendering te hebben, dus ik vermoed dat building:part niet door mapnik ondersteund wordt.

+1

hi deze heb ik ooit gemaakt http://www.openstreetmap.org/#map=18/52.31691/4.94893, misschien niet conform, maar niet voor de renderer getagt. De garage is gelijkvloers en de woontorens staan er zo in.

Ik heb de wiki pagina over de BAG import bijgewerkt op basis van de beslissingen die we vorige week zaterdag hebben genomen: https://wiki.openstreetmap.org/wiki/BAGimport. Willen jullie die pagina svp checken? Specifiek punt: qua namen voor de combi NLExtract en JOSM plugin heb ik Gertjan en Gert-Jan gehanteerd op de wiki, met mijzelf als (tijdelijke) fallback op basis van GEON/QGIS totdat de plugin klaar is. Als er meer/andere OSM’ers zijn die willen helpen met het beschikbaar stellen van data naast GJ en GJ, dan hoor/lees ik het graag. Ik voel namelijk veel voor een gecontroleerd proces, en niet een proces waarbij iedereen in Nederland ongecontroleerd los kan gaan met de BAG data. Over de JOSM plugin zullen zeker vragen gesteld gaan worden door de mensen op de import list, dus graag (Gertjan) dat gedeelte verbeteren op de wiki, want volgens mij heb ik het nog niet helemaal goed beschreven.

Ik zou deze wiki pagina bij voorkeur donderdag willen aanbieden aan de import mailing list, dus zou het mooi zijn als jullie de check uiterlijk woensdagavond hebben afgerond. Op de importlist wordt momenteel trouwens flink gediscussieerd op basis van de adresimport van onze zuiderburen.

Ik kan ook data aanleveren vanuit mijn de NLExtract BAG database. Op het moment heb ik hier alleen voor de woonplaatsgrenzen de web services gereed, voor de panden en adressen zijn die nog in ontwikkeling.

hi, Its so funny, soms staan panden met de aantekening bouwaanvraag dd 2011/2012 in het BAG, maar nu 2013/2014 geen activiteiten te zien ? Zie 7601hm in BAG vieuwer. Hoe gaan we dat tekkelen ?

Ik zat even te zoeken naar een fijn proefgebied.

Duivendrecht is een kleine woonplaats (3000 adressen), waardoor het gemakkelijk in de BAG te “isoleren” is.
Een deel (Kloosterstraat e.o.) is al “met de hand” gehuisnummerd is.
Bovendien gaat er binnenkort een flink deel van het (winkel-)centrum op de schop zodat ook de mutaties daar snel merkbaar zijn.
Verder zit er allerlei soorten bebouwing: rijtjeshuien, 3-hoog galerijflats, portiekflats en 10-hoog galerijflats, maar ook kantoren, bedrijfshallen, een NS-station met meerdere niveaus, een volkstuinenpark en een stadion (de Toekomst: jong Ajax)
Alleen voor de gevreesde toren-bovenop-parkeergarage moeten we naar het naastgelegen Amsterdam-Zuidoost (Bijlmerplein, Arena) uitwijken.

Bovendien is Duiendrecht voor een in reaf life visite handig bereikbaar vanuit vele richtingen.

Maar eens op zoek gaan naar een “OSM-clubhuis” (zonder voorgrondmuziek, met internet, zonder heks) in die contreien?

Gert-Jan

ps. Mijn BAG-voor-dummies van de 16e prak ik nog wel even op de Wiki

Wat dacht je van cafe Brugzicht in de Kloosterstraat of Lotgenoten, dichtbij station Duivendrecht, aan de andere kant van t dorp ? En nee nog niet langs geweest , maar bellen kan ook.

Ik heb nog een opmerking over de tags:
Het voorstel is nu om het bag id van de panden te taggen met bag:id.
Zelf had ik tot nu toe ref:bagid gebruikt, omdat de ref:… tag een standaard is binnen osm. Ik heb nog even weer naar de wiki gekeken http://wiki.openstreetmap.org/wiki/Key:ref, en realiseerde me toen dat ref:bag eigenlijk netter is, omdat ref al aangeeft dat het om een id gaat.

Meest voorkomende tags op dit moment:
ref:bagid (75794)
bag:pand_id (37761)
bag:nummer_id (1087)
bag:vbo_id (18055)

Wat heeft jullie voorkeur?

In de Josm Plug-in komt functionaliteit om oude tagging om te zetten naar de nieuwe standaard. Ik aarzel nog even over wat te doen met bestaande tags als vbo_id en bag:status, die waarden bevatten waarover we hebben afgesproken om ze niet op te nemen.

Gertjan

@GeeJee
In Duivendrecht heeft gebruiker rullzer naast adressen ook associated streets toegevoegd. Hij lijkt me goed om onze plannen eerst met hem kort te sluiten en niet ‘zomaar’ zijn associated street relaties er uit te gooien.

In zwolle, is ook een bag tagger actief onder eigen naam, waarbij niet alle pandcontouren worden overgenomen, nemen jullie contact op met reeds actieve taggers,…

@ Gertjan ref:bag voor het veld pand_id vind ik prima. Als er vanavond verder geen reacties komen verander ik het voorstel aan de DWG in ref:bag

@ Hendrikklaas & GeeJee: lijkt me leuk. Wil een van jullie dit organiseren? Interessant lijkt mij vooral als de plugin dan draait, dan kan ik die ook uitproberen. Conform de instructie die nu op de WIKI staat nemen we contact op met mappers die in een gebied > 100 adressen hebben toegevoegd met een reactietermijn van minimaal 7 dagen. Het is dus wel netjes (zie ook de posting van Gertjan) als een van jullie beiden tijdig een mail stuurt aan rullzer

@ Hendrikklaas: we hebben afgesproken om ‘Bouw gestart’, ‘Pand in gebruik’ en ‘Pand in gebruik (niet ingemeten)’ op te nemen in de te importeren dataset bij de preprocessing van de OSM files. Dat zou moeten afvangen dat wel een vergunning is verleend (is een aparte status in de BAG) maar geen bouw is gestart.

@ Allroads: ja, dat is bekend. Dank voor de signalering!

Cheers, Johan