[OSM-talk-nl] Het taggen van BAG data.

Sun Oct 21 09:36:15 UTC 2012

Lijkt me de goede benadering.  Hugo
Op 21 okt. 2012 11:07 schreef "Gertjan Idema" <g.idema at zonnet.nl> het
volgende:

> **
> On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
>
> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de
> BAG viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt:
> 0397100000014064, vind je een huis en adres  in Heemstede waarvan de bouw
> nog niet eens begonnen is. Verder weet ik dat de bouw vergunning aan
> verandering onderhevig is. Gaan we met bulk up-loads nu de mogelijk
> toekomstige kaart van Nederland maken of is het wijsheid om de locaties
> waarvan de status is: “bouwvergunning verleend” er nog uit laten?
>
>
>
>  Hugo
>
>
> Mijn insteek op dit moment is om gebouwen met status  "Bouw gestart" te
> taggen als building=construction. Voor "Bouwvergunning verleend" kan je
> overwegen om dat ook te doen, om wat meer informatie te geven aan een
> mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg ik
> een tag "bag:status" toe.
>
> Gertjan
>
>
>
>  *From:* Gertjan Idema <g.idema at zonnet.nl>
>
>  *Sent:* Saturday, October 20, 2012 8:54 PM
>
>  *To:* talk-nl at openstreetmap.org
>
>  *Subject:* Re: [OSM-talk-nl] Het taggen van BAG data.
>
>
>
>  On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:
>
> Beste Gertjan e.a,
> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week ververst met versie 8 sept en 8 okt:
>
>  Fijn dat je meedenkt :-)
>
> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml (Atom).e.e.a. moet ook simpeler worden in de toekomst:http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
>
> On 17-10-12 13:11, Gertjan Idema wrote:> Er is een aantal initiatieven gaande voor het opnemen van BAG data in> Openstreetmap.> - ruudblank heeft veel werk verricht in Gorinchem.> - rullzer in de omgeving Purmerend> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee> (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig>    aan het testen zijn.> - en ongetwijfeld nog meer.>> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan> en besproken is over het taggen van data afkomstig uit de BAG.> Vervolgens hoop ik dat we het samen eens kunnen worden over een> standaard. Deze kan dan opgenomen worden op de Wiki pagina en> geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel> mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit> consistent gebeurt.>> Eerst maar eens een inventarisatie:>> Adres tags op pand of losse nodes> =============================> De BAG maakt onderscheid tussen panden, verblijfsobjecten en> nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), maar moet daarvan nog voorbeeld zien.
>
>  Hier is een mooi voorbeeld: VBO 0344010000091735 (Ambachtsweg 52,
> Utrecht) ik heb ook nog even geen
> idee hoe we dit het beste in OSM zouden kunnen mappen.
> Een ander voorbeeld is VBO 0344100000054743 (Hoogravenseweg 140A). Hier
> zijn 2 panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
> Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met
> 2 panden per VBO.
>
> > Tot nu toe heb ik de adressen als volgt getagd:> Voor panden met een enkel verblijfsobject heb ik de adres tags> (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld> met in tag "ref:bagid" het BAG id van het pand.> Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen> adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De> adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het> BAG id van de nummeraanduiding.>> ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te> koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van> het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id> van het pand in "bag:pand_id".>> rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met> meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, Door-to-door navigation. En verder aansluiten bij algemene OSM-conventies voor adressen.
>
>  Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
> ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
> relaties amper gebruikt worden vanwege de complexiteit, denk ik dat een
> eventuele associatedBuilding relatie het niet gaat redden.
> Voor de meeste toepassingen zal een relatie tussen pand en adres niet echt
> belangrijk zijn, hoewel Cartinus aangaf dat de relatie tussen hoofdadres en
> nevenadressen (leveranciersadressen) in de transportsector wel gebruikt
> wordt.
>
>  >> AssociatedStreet relaties> =====================> AssociatedStreet relaties bieden veel voor en nadelen en het laatste> woord is er nog niet over gesproken. Een voordeel dat in mijn ogen> onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde> straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen> straten in OSM en straten uit andere bronnen. Dat gaat echter alleen> werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het> invoeren, zie ik dat nog niet zo snel gebeuren.> De osmosis plug-in waarmee ik bezig ben bied een optie om> associatedstreet relaties te genereren, inclusief BAG openbareruimte id.> Vanwege de complexiteit bij het invoeren zijn we er echter vanaf gestapt> om die te gebruiken.> Ook ruudblank en rullzer lijken geen associatedstreet relaties toe te> voegen.>> addr:city en addr:country tags> =========================> Toevoegen van addr:city en addr:country tags aan adressen gaat bij het> importeren van BAG data in een moeite mee. De vraag is of het wenselijk> is om dat ook te doen. Het zorgt voor erg veel redundantie.> ruudblank voegt addr:city toe, rullzer niet.> Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar> om addr:city toch maar te gaan toevoegen.City is dan Woonplaats neem ik aan. Gemeente en provincie?
>
>  City is dan inderdaad woonplaats. Gemeente, Provincie, (Land,
> Werelddeel, EU?) in een tag aan elk adres toevoegen gaat mij persoonlijk te
> ver en is voor zover ik weet ook niet gebruikelijk binnen OSM. Binnenkort
> wil ik eens in de Franse kadastre discussie (hopelijk ook in het engels)
> duiken om te kijken welke keuzes daar gemaakt worden.
>
> >> Huisnummers> ===========> De BAG bevat de kolommen huisnummer, huisletter en huisnummertoevoeging.> OSM gebruikt alleen de tag "addr:housenumber". Hier is dus een vertaling> nodig waarbij je kunt kiezen om wel of geen spaties tussen de> verschillende delen van het huisnummer te plaatsen.> De BAG laat gemeenten vrij in het gebruik van hoofd en kleine letters.>> rullzer: gebruikt geen spatie tussen huisnummer en huisletter> (huisnummertoevoeging kom ik in zijn gebied niet tegen).> ruudblank: gebruikt een spatie tussen huisnummer en huisletter en lijkt> huisnummertoevoeging weg te laten.> bagviewer.geodan.nl: gebruikt een spatie na het huisnummer en niet> tussen huisletter en huisnummertoevoeging.Offiële URL is http://pdok.nl/bagviewer (is nu nog dezelfde app).> http://www.kadaster.nl/BAG/producten/web.html: gebruikt geen spatie> tussen huisnummer en huisletter, maar wel tussen huisletter en> huisnummertoevoeging.>> Zelf gebruik ik de laatste conventie. Die is ook het beste leesbaar.> (Vergelijk "42 abov" met "42a bov")>> De adressen in de BAG komen ook niet altijd overeen met die op de gevel,> alleen al bij mij in de buurt:> BAG: 19 BSA, gevel: 19 BIS A> BAG: 100A A, gevel: 100 AA..>> Versiebeheer> ===========> De BAG id code op zich is niet voldoende om te kunnen zien of een BAG> object in OSM nog actueel is. Daarvoor heeft de BAG 2 extra velden:> begindatumtijdvakgeldigheid en aanduidingrecordcorrectie.> begindatumtijdvakgeldigheid bepaalt vanaf welk moment een object een> bepaalde status heeft. Bijvoorbeeld 'Bouw gestart'> (building:construction) of 'Pand in gebruik' (building:yes). Deze waarde> kan als extra tag in OSM worden toegevoegd (Ik gebruik nu> "bag:begindatum", met "yyyy-MM-dd hh:mm:ss" als datum formaat).> aanduidingrecordcorrectie geeft aan dat er fouten gecorrigeerd zijn in> de BAG data. Helaas krijgt het meest recente record niet de hoogste> waarde voor 'aanduidingrecordcorrectie', maar de waarde 0. Het opslaan> van deze waarde in een OSM tag heeft dus niet zo veel zin. Ik denk dat> je de maximum waarde van 'aanduidingreccordcorrectie' in een OSM tag zou> moeten zetten, maar omdat ik dit proces nog niet helemaal doorgrond, heb> ik dat tot nu toe niet gedaan. Ook zou de betekenis van die tag zonder> grondige documentatie alleen maar voor verwarring zorgen. Daarom heb ik> er voorlopig voor gekozen om een tag "bag:extract" toe te voegen met> daarin de naam van het zip bestand waaruit de BAG data afkomstig is.> Daarmee is in ieder geval de versie van de BAG data af te leiden.
> Volgens mij zijn er 2 begrippen in de BAG om "aktieve"-non-duplicate records te krijgen: "actueel" en "bestaand". Heeft ook te maken dat er nooit iets wordt weggegooid uit de BAG, inclusief invoerfouten. Binnen NLExtract-BAG baseren we daar ook de SQL VIEWs op:
> - actueel: bepaald door de velden: begin/einddatumtijdvakgeldigheid en aanduidingrecordinactief- bestaand: bepaald door "status" veld bijv 'Pand gesloopt'
> Hieronder een stukje SQL voor pandactueelbestaand VIEW:    WHERE      pand.begindatumtijdvakgeldigheid <= LOCALTIMESTAMP      AND (pand.einddatumtijdvakgeldigheid is NULL OR pand.einddatumtijdvakgeldigheid >= LOCALTIMESTAMP)      AND pand.aanduidingrecordinactief = FALSE      AND pand.geom_valid = TRUE      AND (pand.pandstatus <> 'Niet gerealiseerd pand' AND pand.pandstatus  <> 'Pand gesloopt' );
>
>  Ik gebruik nagenoeg dezelfde SQL in mijn queries, maar met > in plaats
> van >= voor einddatumtijdvakgeldigheid. Dat voorkomt dubbele resultaten in
> het (erg zeldzame) geval dat einddatumtijdvakgeldigheid = LOCALTIMESTAMP.
> De queries zouden nog iets simpeler kunnen bij gebruik van  'infinity' in
> plaats van 'null' voor niet ingevulde waarden van
> einddatumtijdvakgeldigheid.
>
> aanduidingreccordcorrectie heb ik nooit iets mee gedaan...
>
>  Uit 'Handreiking voor afnemers van de BAG' versie 2009:
> 'De werking van het synchronisatiemechanisme en de toepassing van het
> attribuut ‘aanduidingRecordCorrectie’ zijn nog onderwerp van onderzoek. In
> een
> toekomstige release zal dit mechanisme mogelijk gaan veranderen en dit
> attribuut niet meer worden toegepast.'
>
> Ik hoop dat dit onderzoek binnenkort een bruikbaardere oplossing bied.
>
> Nu ik de BAG extract van 08102010 heb, ga ik experimenteren met updates
> voor de gebieden waar al wat BAG data is ingevuld. Ik hoop daaruit blijkt
> dat ik het attribuut aanduidingRecordCorrectie niet nodig heb. Ik vind het
> nogal vaag omschreven.
>
>
>  En dan is er nog INSPIRE Addresses voor wie nog leestijd over heeft :-) :http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.1.pdfHet Adres-model is overly complex GML maar aan eind van document staat wel goed uitgelegd hoe adres-conventies in verschillende landen werken.
>
>  Bedank voor de link. Als ik tijd vind ga duik is er eens in.
>
> Groeten, Gertjan
>
> groeten,
> Just van den Broeckewww.justobjects.nlwww.nlextract.nl
>
> >> Gertjan Idema>>>> _______________________________________________> Talk-nl mailing list> Talk-nl at openstreetmap.org> http://lists.openstreetmap.org/listinfo/talk-nl>
>
>
>
>
> _______________________________________________Talk-nl mailing listTalk-nl at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-nl
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
>
> _______________________________________________
> Talk-nl mailing listTalk-nl at openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-nl
>
>
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20121021/5bfb322e/attachment.htm>