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

Just van den Broecke just at justobjects.nl
Sat Oct 20 12:38:04 BST 2012


Beste Pander,

Heb je de standaard terugmelding per email al geprobeerd:
bag op kadaster.nl
zie
http://bag.vrom.nl/de_bag_gebruiken/terugmelden

"Als u gerede twijfel heeft over de juistheid van de informatie in de 
BAG, dan kunt u dit per e-mail melden op bag op kadaster.nl. In het 
onderwerpveld van de e-mail dient u de gemeente te vermelden waarbinnen 
het object valt. De betreffende object ID('s) dient u te vermelden in uw 
bericht, plus hetgeen u over twijfelt. Voor private afnemers geldt geen 
terugmeldingsplicht. Bij gerede twijfel kan er rechtstreeks bij de 
bronhouder teruggemeld worden."

groeten,

Just
On 20-10-12 13:32, Pander wrote:
> On 2012-10-20 13:21, 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:
>> 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.
>
> Voor wie interesse heeft: ik heb nog een hele lijst van correcties op de
> BAG-gegevens. Met name coderings- en typefouten zitten er redelijk wat in.
>
> Ook zou het handig zijn als het Kadaster er iets mee zou willen doen?
>
> Ik heb ze al eens geschreven over fouten in toponiemen uit 1:25.000
> kaarten (TOP25) maar toen hadden ze geen interesse. Hun reden was dat ze
> er zelf al mee aan de slag waren.
>
> Voor BAG denk ik niet dat ze op de hoogte zijn van deze fouten, ook
> omdat het een gigantische collectie is. Heeft iemand een ingang
> hiervoor? Volgens de wet moeten ze volgens mij openstaan voor
> terugmelding van correcties.
>
>> 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.
>>> 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.
>>>
>>> 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?
>>>
>>> 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' );
>>
>> aanduidingreccordcorrectie heb ik nooit iets mee gedaan...
>>
>> 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.pdf
>>
>> Het Adres-model is overly complex GML maar aan eind van document staat
>> wel goed uitgelegd hoe adres-conventies in verschillende landen werken.
>>
>> groeten,
>>
>> Just van den Broecke
>> www.justobjects.nl
>> www.nlextract.nl
>>
>>
>>
>>>
>>> Gertjan Idema
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-nl mailing list
>>> Talk-nl op openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-nl
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Talk-nl op openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-nl
>
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl op openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>










More information about the Talk-nl mailing list