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

theun theun.mail at gmail.com
Sun Oct 21 11:51:27 UTC 2012


Ik zou me kunnen voorstellen dat je dat pas doet vanaf "bouw gestart". 
Hier in de buurt zag ik ook al een groot pand staan waar de 
bouwvergunning is verleend, al op het moment dat de BAG data vrijkwam. 
Dan is het in deze tijd natuurlijk nog wel nodig om de financiering etc. 
rond te krijgen en het pand daadwerkelijk te bouwen. De kans bestaat dus 
dat het pand als "niet gerealiseerd pand" eindigt. Die data lijkt mij 
niet nuttig voor OSM.

Op 21-10-2012 13:17, Gertjan Idema schreef:
> On Sun, 2012-10-21 at 11:52 +0200, Frank Steggink wrote:
>> Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al
>> met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de
>> BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?
> Het klopt dat de bouw meestal niet start zodra de bouwvergunning is 
> verleend. Mijn overweging om zo'n gebouw toch aan aan een .osm file 
> toe te voegen is de volgende:
> In de praktijk zal er tijd zitten tussen het moment van genereren van 
> een .osm file en het moment dat een mapper er mee aan de gang gaat. 
> Door het pand als "building=construction" toe te voegen, weet de 
> mapper dat er op die plek iets gaat gebeuren en kan hij bijvoorbeeld 
> in de BAG web kijken wat de huidige status van het pand is.
> Iets als "building=planned" is volgens mij niet gedocumenteerd in OSM 
> en zal door Mapnik cs als bestaand pand gerenderd worden.
>
> Sloop vergunningen staan ook in de BAG. Hier is het complete lijstje:
> Bouwvergunning verleend
> Niet gerealiseerd pand
> Bouw gestart
> Pand in gebruik (niet ingemeten)
> Pand in gebruik
> Sloopvergunning verleend
> Pand gesloopt
> Pand buiten gebruik
>
> Groeten, Gertjan
>> Groeten,
>>
>> Frank
>>
>> On 21-10-2012 11:36, Hugo Hölscher wrote:
>> >
>> > Lijkt me de goede benadering. Hugo
>> >
>> > Op 21 okt. 2012 11:07 schreef "Gertjan Idema" <g.idema at zonnet.nl  <mailto:g.idema at zonnet.nl>  
>> > <mailto:g.idema at zonnet.nl>> het volgende:
>> >
>> >     On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
>> >>     Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
>> >>     ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
>> >>     deze id zoekt: 0397100000014064, vind je een huis en adres in
>> >>     Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
>> >>     ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
>> >>     met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
>> >>     maken of is het wijsheid om de locaties waarvan de status is:
>> >>     "bouwvergunning verleend" er nog uit laten?
>> >>     Hugo
>> >
>> >     Mijn insteek op dit moment is om gebouwen met status "Bouw
>> >     gestart" te taggen als building=construction. Voor "Bouwvergunning
>> >     verleend" kan je overwegen om dat ook te doen, om wat meer
>> >     informatie te geven aan een mapper die ziet dat er wat gaande is
>> >     op een stukje grond. Daarnaast voeg ik een tag "bag:status" toe.
>> >
>> >     Gertjan
>> >>     *From:*Gertjan Idema <mailto:g.idema at zonnet.nl>
>> >>     *Sent:*Saturday, October 20, 2012 8:54 PM
>> >>     *To:*talk-nl at openstreetmap.org  <mailto:*talk-nl at openstreetmap.org>  <mailto:talk-nl at openstreetmap.org>
>> >>     *Subject:*Re: [OSM-talk-nl] Het taggen van BAG data.
>> >>     On Sat, 2012-10-20 at 13:21 +0200, 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:
>> >>     Fijn dat je meedenkt :-)
>> >>>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.
>> >>     Hier is een mooi voorbeeld: VBO 0344010000091735 (Ambachtsweg 52,
>> >>     Utrecht) ik heb ook nog even geen
>> >>     idee hoe we dit het beste in OSM zouden kunnen mappen.
>> >>     Een ander voorbeeld is VBO 0344100000054743 (Hoogravenseweg
>> >>     140A). Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in
>> >>     7 verblijfsobjecten.
>> >>     Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de
>> >>     meesten met 2 panden per VBO.
>> >>>     > 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.
>> >>     Relaties tussen panden en verblijfsobjecten/adressen worden voor
>> >>     zover ik weet niet gebruikt in OSM. En gezien het feit dat
>> >>     associatedStreet relaties amper gebruikt worden vanwege de
>> >>     complexiteit, denk ik dat een eventuele associatedBuilding
>> >>     relatie het niet gaat redden.
>> >>     Voor de meeste toepassingen zal een relatie tussen pand en adres
>> >>     niet echt belangrijk zijn, hoewel Cartinus aangaf dat de relatie
>> >>     tussen hoofdadres en nevenadressen (leveranciersadressen) in de
>> >>     transportsector wel gebruikt wordt.
>> >>
>> >>>     >
>> >>>     > 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?
>> >>     City is dan inderdaad woonplaats. Gemeente, Provincie, (Land,
>> >>     Werelddeel, EU?) in een tag aan elk adres toevoegen gaat mij
>> >>     persoonlijk te ver en is voor zover ik weet ook niet gebruikelijk
>> >>     binnen OSM. Binnenkort wil ik eens in de Franse kadastre
>> >>     discussie (hopelijk ook in het engels) duiken om te kijken welke
>> >>     keuzes daar gemaakt worden.
>> >>>     >
>> >>>     > 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  <http://bagviewer.geodan.nl>: gebruikt een spatie na het huisnummer en niet
>> >>>     > tussen huisletter en huisnummertoevoeging.
>> >>>     Offiële URL ishttp://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' );
>> >>     Ik gebruik nagenoeg dezelfde SQL in mijn queries, maar met > in
>> >>     plaats van >= voor einddatumtijdvakgeldigheid. Dat voorkomt
>> >>     dubbele resultaten in het (erg zeldzame) geval dat
>> >>     einddatumtijdvakgeldigheid = LOCALTIMESTAMP.
>> >>     De queries zouden nog iets simpeler kunnen bij gebruik van
>> >>     'infinity' in plaats van 'null' voor niet ingevulde waarden van
>> >>     einddatumtijdvakgeldigheid.
>> >>>     aanduidingreccordcorrectie heb ik nooit iets mee gedaan...
>> >>     Uit 'Handreiking voor afnemers van de BAG' versie 2009:
>> >>     'De werking van het synchronisatiemechanisme en de toepassing van het
>> >>     attribuut 'aanduidingRecordCorrectie' zijn nog onderwerp van
>> >>     onderzoek. In een
>> >>     toekomstige release zal dit mechanisme mogelijk gaan veranderen
>> >>     en dit
>> >>     attribuut niet meer worden toegepast.'
>> >>
>> >>     Ik hoop dat dit onderzoek binnenkort een bruikbaardere oplossing
>> >>     bied.
>> >>
>> >>     Nu ik de BAG extract van 08102010 heb, ga ik experimenteren met
>> >>     updates voor de gebieden waar al wat BAG data is ingevuld. Ik
>> >>     hoop daaruit blijkt dat ik het attribuut
>> >>     aanduidingRecordCorrectie niet nodig heb. Ik vind het nogal vaag
>> >>     omschreven.
>> >>
>> >>
>> >>>     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.
>> >>     Bedank voor de link. Als ik tijd vind ga duik is er eens in.
>> >>
>> >>     Groeten, Gertjan
>> >>>     groeten,
>> >>>
>> >>>     Just van den Broecke
>> >>>www.justobjects.nl  <http://www.justobjects.nl>   <http://www.justobjects.nl>
>> >>>www.nlextract.nl  <http://www.nlextract.nl>   <http://www.nlextract.nl>
>> >>>
>> >>>
>> >>>     >
>> >>>     > Gertjan Idema
>> >>>     >
>> >>>     >
>> >>>     >
>> >>>     > _______________________________________________
>> >>>     > Talk-nl mailing list
>> >>>     >Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>   <mailto:Talk-nl at openstreetmap.org>
>> >>>     >http://lists.openstreetmap.org/listinfo/talk-nl
>> >>>     >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>     _______________________________________________
>> >>>     Talk-nl mailing list
>> >>>Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>   <mailto:Talk-nl at openstreetmap.org>
>> >>>http://lists.openstreetmap.org/listinfo/talk-nl
>> >>
>> >>
>> >>
>> >>     ------------------------------------------------------------------------
>> >>
>> >>     _______________________________________________
>> >>     Talk-nl mailing list
>> >>Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>  <mailto:Talk-nl at openstreetmap.org>
>> >>http://lists.openstreetmap.org/listinfo/talk-nl
>> >>
>> >>     _______________________________________________
>> >>     Talk-nl mailing list
>> >>Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>   <mailto:Talk-nl at openstreetmap.org>
>> >>http://lists.openstreetmap.org/listinfo/talk-nl
>> >
>> >
>> >     _______________________________________________
>> >     Talk-nl mailing list
>> >Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>  <mailto:Talk-nl at openstreetmap.org>
>> >http://lists.openstreetmap.org/listinfo/talk-nl
>> >
>> >
>> >
>> > _______________________________________________
>> > Talk-nl mailing list
>> >Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>
>> >http://lists.openstreetmap.org/listinfo/talk-nl
>>
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Talk-nl at openstreetmap.org  <mailto:Talk-nl at openstreetmap.org>
>> http://lists.openstreetmap.org/listinfo/talk-nl
>
>
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20121021/804e0054/attachment.htm>


More information about the Talk-nl mailing list