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

Gertjan Idema g.idema at zonnet.nl
Thu Oct 18 16:50:21 BST 2012


Nog een toevoeging naar aanleiding van Cartinus:
Het veld huisletter in mijn BAG database (8-8-2012) bevat alleen maar
hoofd- en kleine letters, dus geen cijfers.

Gertjan
On Thu, 2012-10-18 at 17:39 +0200, Gertjan Idema wrote:

> 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 
> 
> _______________________________________________
> 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/20121018/3588af6e/attachment-0001.html>


More information about the Talk-nl mailing list