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

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


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.


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
>







More information about the Talk-nl mailing list