Idee om wat met BAG te gaan doen

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

Volgens de BAGimport wiki is het plan om source=BAG toe te voegen aan alle panden en adressen. Is er overwogen om in plaats daarvan de source tag te koppelen aan de changeset? Dat gebeurt o.a. bij de Belgische CRAB import en bij Amerikaanse imports zoals Chicago en Massachusetts (http://wiki.openstreetmap.org/wiki/MassGIS_Import_Tag_Cleanup_2013).

JOSM krijgt binnenkort een update waarbij om een source tag wordt gevraagd bij het uploaden van een changeset (http://josm.openstreetmap.de/ticket/6381).

k Maak er werk van. Vragen :
is er budget of op consumpties ?
hoelang of welke tijdnemen we ?
Wat gebeurt er trouwens bij import met al eerder ingebrachte en gedetailleerde gebouwen ?

Gert Jan misschien heeft rullzer ook nog een lokaal idee. Hebben we een mailadres ?

Onze beslissingen over de import van de BAG heeft op de importlijst geleidt tot reacties op de source(datum), op de bagid en op de gebruiksfunctie.

  1. Source/source:date
    Reactie houdt in dat het beter is om dit in de changeset op te nemen (conform opmerking Cavit). Ik heb het op de Wiki teruggezocht hoe dit zit, en er zijn inderdaad diverse opmerkingen gemaakt dat dit op de changeset zou moeten. Ik heb geen bezwaar tegen deze aanpassing

  2. bagid.
    Reactie houdt in dat de bagid never nooit gebruikt zal worden, dat is nl. nog nooit gelukt in de historie van OSM. Ik zou de bagid (= PAND-ID in de bag) wel willen behouden. De BAG wordt immers maandelijks ververst, je weet maar nooit hoe we in de toekomst de verschillen willen opzoeken.

  3. gebruiksfunctie.
    Reactie houdt in dat het onduidelijk is wie dit dan in de toekomst zou moeten gebruiken. Mijn voorstel is om terug te grijpen op het voorstel dat ik eerder had gedaan, namelijk waar mogelijk op de pandcontour building=yes aanpassen in bv building=residential (obv GEBR_DOEL1 uit de BAG)

Ik zou dit morgenavond zo willen posten naar de importlist inclusief een bijbehorende aanpassing van de Wiki pagina. Laat svp uiterlijk morgenmiddag weten als je iets anders wilt

Cheers, Johan

ps @Hendrikklaas rullzer is te mailen via zijn OSM account; budget is een kwestie van een gezamenlijke pot; eerder ingebrachte gebouwen die mooier zijn gedetailleerd dan de BAG moeten zeker behouden blijven

Ik ben geen voorstander van Source/source:date de changeset. Dit voegt in mijn ogen veel onnodige complexiteit toe.
In de plug-in kan ik nu met 1 download de osm gegevens van een gebied ophalen om ze te vergelijken met BAG gegevens. Als source en source:date tags op de changeset zitten, moet ik na het ophalen van de osm gegeven alle panden en adressen doorlopen om te kijken welke changeset er bij hoort. Vervolgens moet ik al die changesets ophalen van de osm server en koppelen aan het bijbehorende pand/adres voordat de source en source:date tags beschikbaar zijn.