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

Pee Wee piewie32 at gmail.com
Sat Oct 20 11:46:19 UTC 2012


Op
https://www.kadaster.nl/particulier/producten/bestel.asp?soort=terugmelding_br
kun je ook een melding maken.

Zie ook http://pdok.nl/bagviewer/  de Terugmelding of Correctieverzoek

Op 20 oktober 2012 13:38 schreef Just van den Broecke
<just at justobjects.nl>het volgende:

> Beste Pander,
>
> Heb je de standaard terugmelding per email al geprobeerd:
> bag at kadaster.nl
> zie
> http://bag.vrom.nl/de_bag_**gebruiken/terugmelden<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 at 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<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<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<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<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 at openstreetmap.org
>>>> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Talk-nl mailing list
>>> Talk-nl at openstreetmap.org
>>> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl>
>>>
>>
>>
>> ______________________________**_________________
>> Talk-nl mailing list
>> Talk-nl at openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl>
>>
>>
>
>
>
>
>
>
>
> ______________________________**_________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20121020/abb39978/attachment.htm>


More information about the Talk-nl mailing list