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

Gertjan Idema g.idema at zonnet.nl
Thu Oct 18 16:39:07 BST 2012


On Wed, 2012-10-17 at 20:06 +0200, Cartinus wrote:

> On 10/17/2012 01:11 PM, Gertjan Idema wrote:
> > 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.
> 
> Hoe nuttig is het BAG id van de nummeraanduiding voor adres nodes (voor
> OSM)? In principe zou in Nederland de combinatie postcode en huisnummer
> uniek moeten zijn, dus daarmee zou je dan terug kunnen koppelen aan die
> BAG tabel.
> 
> Als je het BAG id van het verblijfsobject gebruikt, dan kun je in OSM
> zelf zien dat bijv. de verschillende adressen van de voordeur en de
> achterdeur bij hetzelfde verblijfsobject horen. (Ik werk voor een
> transportonderneming en dat vinden wij interessante informatie.) Zeker
> als je op één of andere manier in de tag of de waarde duidelijk maakt
> dat het om een verblijfsobject id gaat. (Ik weet dat ze allemaal uit één
> reeks komen, maar dan moet ik weer in de BAG zelf kijken en niet in OSM.)

Het Bag id van het verblijfsobject is inderdaad misschien logischer. Op
een pand met een enkel verblijfsobject zouden deze misschien ook kunnen zetten:

bag:vbo_id en bag:pnd_id (of bag:pand_id zoals in Gorinchem)

> > AssociatedStreet relaties
> > =====================
> 
> Gewoon weglaten. Ik heb ze zelf in het verleden ook aangemaakt, maar het
> is te foutgevoelig en te lastig bij te houden bij handmatig mappen.
> 
> > 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.
> 
> In Denemarken hebben ze ooit alle adressen geïmporteerd. Daar hadden ze
> wel addr:city toegevoegd, omdat ze (toen) niet zo'n complete set grenzen
> hadden als nu in Nederland. De tag addr:country hadden ze weggelaten.
> Later kwam er iemand van buiten Denemarken en die voegde dat alsnog toe.
> Gevolg: stel boze Denen. Geen idee of het is teruggedraaid of niet.

De woonplaatsgrenzen zijn nog zeker niet compleet in OSM in Nederland,
maar via de BAG wel beschikbaar.

> 
> Bij met de hand adressen taggen heb ik nergens addr:city toegevoegd. Ik
> kan namelijk maar twee situaties bedenken waarbij je addr:city m.b.v. de
> grenzen niet automatisch zou kunnen toevoegen.

Als je hier bedoeld om ze uiteindelijk wel in OSM te zetten, kunnen we
het in mijn ogen beter meteen doen.
Als we het niet doen en besluiten om de link te leggen via de
woonplaatsgrenzen, is dat natuurlijk wel complexer en bewerkelijker.

> 
> 1) Het postadres ligt niet in dezelfde woonplaats als het pand.
> 2) Het pand staat op de grens en ligt dus in twee woonplaatsen.

Als ik het goed begrepen heb kan 1 officieel niet.

> Ik weet niet of 1) kan in Nederland. 2) zie je bij het met de hand
> taggen, dus dan tag je addr:city alleen in het geval van deze uitzondering.
> 
> Bij een import weet ik niet wat de beste keus is. Testen op conditie 2)
> of gewoon allemaal taggen. Dat laatste kost immers geen moeite.
> 
> > 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")
> 
> Hoe "schoon" is de BAG data m.b.t tot het huisletter veld? M.a.w. staat
> er echt nergens een cijfer in? Als het schoon is, dan "42a bov", anders
> "42 a 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 
> 
> Data kwaliteit blijft altijd een probleem en toch alleen te fixen met
> nacontrole in het veld. Ik zou het in dit geval negeren.

Helemaal mee eens. Het was meer bedoeld ter indicatie. Het is iets om
rekening mee te houden als je probeert adressen op basis van
postcode/huisnummer te vergelijken.

> 
> > Versiebeheer
> > ===========
> 
> Klikt goed.
> 
> ---
> m.v.g.,
> Cartinus
> 
> _______________________________________________
> Talk-nl mailing list
> Talk-nl op openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl

Gertjan
------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20121018/fd18dad8/attachment.html>


More information about the Talk-nl mailing list