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

Gertjan Idema g.idema at zonnet.nl
Sat Oct 20 16:01:22 BST 2012


Beste Pander,

Als je mij een lijstje met correcties stuurt, wil ik wel kijken of ik er
BAG id's aan kan koppelen. 

Gertjan

On Sat, 2012-10-20 at 13:54 +0200, Pander wrote:

> On 2012-10-20 13:38, Just van den Broecke wrote:
> > 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."
> 
> Dank je wel. Alleen heb ik niet een overzicht van die ID's. Doe moeten
> er bijgezocht worden als mijn correcties worden uitgevoerd. Aangezien ik
> correcties doe nadat het ID gestript is is dat een hoop extra werk.
> 
> Is er iemand die veel met BAG-gegevens werkt en al bestaande scripts
> heeft die mijn lijst van correcties als een filter op wil nemen en zo
> rapportjes kan genereren om terug te zenden naar het Kadaster.
> 
> Voordeel als je hiermee aan de slag gaat is dat de gecorrigeerde
> BAG-gegevens van veel hogere kwaliteit zijn. Vanuit OpenTaal ga ik door
> de BAG-gegevens voor spellingcontrole maar de geografische informatie
> interesseert ons verder niet. Dit ligt om die reden buiten ons domein.
> Vandaar de zoektocht naar een BAG-liefhebber om het stokje aan door te
> geven.
> 
> > 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
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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


------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20121020/5fecb7a5/attachment-0001.html>


More information about the Talk-nl mailing list