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

Floris Looijesteijn osm at floris.nu
Wed Oct 17 13:29:10 BST 2012


Is het misschien een idee om hier een keer een avond/middag voor bij elkaar
te komen?
Dat gaat alleen werken als de hoofdrolspelers allemaal aanwezig kunnen zijn
natuurlijk.

Groet,
Floris

2012/10/17 Floris Looijesteijn <osm op floris.nu>

> Ik zit ook te wachten op duidelijke regels voordat ik Haarlem ga
> importeren, goed initiatief.
>
> Klein opmerking over de huisnummer toevoegingen. Waarschijnlijk kan de
> toevoeging ook wel eens een nummer zijn.
> Het zal niet de eerste keer zijn dat een pakketje bestemd voor 11 2 (of
> 11-2) naar huisnummer 112 wordt gestuurd.
> Dus minstens een spatie wat mij betreft. Of controleren of het alleen
> letter is en de spatie weglaten.
>
> Ik ben benieuwd hoe de data voor mijn pand is, op mijn gevel hangt een
> bordje met A terwijl men in Haarlem met 'Zwart' en 'Rood' werkt.
>
> Groet,
> Floris
>
> 2012/10/17 Gertjan Idema <g.idema op zonnet.nl>
>
>> **
>> 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.
>> 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.
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> Gertjan Idema
>>
>>
>> _______________________________________________
>> 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/20121017/c3fb797b/attachment.html>


More information about the Talk-nl mailing list