<p>Lijkt me de goede benadering.  Hugo</p>
<div class="gmail_quote">Op 21 okt. 2012 11:07 schreef "Gertjan Idema" <<a href="mailto:g.idema@zonnet.nl">g.idema@zonnet.nl</a>> het volgende:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>


  
  

<div>
On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
<blockquote type="CITE">
    <font color="#000000">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?</font>
</blockquote>
<blockquote type="CITE">
    <font color="#000000"> </font>
</blockquote>
<blockquote type="CITE">
    <font color="#000000">Hugo</font>
</blockquote>
<br>
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.<br>

<br>
Gertjan
<blockquote type="CITE">
    <font color="#000000"> </font>
</blockquote>
<blockquote type="CITE">
    <b><font color="#000000">From:</font></b><font color="#000000"> <a href="mailto:g.idema@zonnet.nl" target="_blank">Gertjan Idema</a> </font>
</blockquote>
<blockquote type="CITE">
    <b><font color="#000000">Sent:</font></b><font color="#000000"> Saturday, October 20, 2012 8:54 PM</font>
</blockquote>
<blockquote type="CITE">
    <b><font color="#000000">To:</font></b><font color="#000000"> <a href="mailto:talk-nl@openstreetmap.org" target="_blank">talk-nl@openstreetmap.org</a> </font>
</blockquote>
<blockquote type="CITE">
    <b><font color="#000000">Subject:</font></b><font color="#000000"> Re: [OSM-talk-nl] Het taggen van BAG data.</font>
</blockquote>
<blockquote type="CITE">
    <font color="#000000"> </font>
</blockquote>
<blockquote type="CITE">
    <font color="#000000">On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote: </font>
    <blockquote type="CITE">
<pre>
<font color="#000000">Beste Gertjan e.a,</font>

<font color="#000000">Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week </font>
<font color="#000000">ververst met versie 8 sept en 8 okt:</font>
</pre>
    </blockquote>
    <font color="#000000">Fijn dat je meedenkt :-) </font>
    <blockquote type="CITE">
<pre>
<font color="#000000"><a href="http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml" target="_blank">http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml</a> </font>
<font color="#000000">(Atom).</font>
<font color="#000000">e.e.a. moet ook simpeler worden in de toekomst:</font>
<font color="#000000"><a href="http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds" target="_blank">http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds</a></font>

<font color="#000000">Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.</font>


<font color="#000000">On 17-10-12 13:11, Gertjan Idema wrote:</font>
<font color="#000000">> Er is een aantal initiatieven gaande voor het opnemen van BAG data in</font>
<font color="#000000">> Openstreetmap.</font>
<font color="#000000">> - ruudblank heeft veel werk verricht in Gorinchem.</font>
<font color="#000000">> - rullzer in de omgeving Purmerend</font>
<font color="#000000">> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee</font>
<font color="#000000">> (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig</font>
<font color="#000000">>    aan het testen zijn.</font>
<font color="#000000">> - en ongetwijfeld nog meer.</font>
<font color="#000000">></font>
<font color="#000000">> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee</font>
<font color="#000000">> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan</font>
<font color="#000000">> en besproken is over het taggen van data afkomstig uit de BAG.</font>
<font color="#000000">> Vervolgens hoop ik dat we het samen eens kunnen worden over een</font>
<font color="#000000">> standaard. Deze kan dan opgenomen worden op de Wiki pagina en</font>
<font color="#000000">> geďntegreerd in tools en scripts. Het doel hierbij is niet om zoveel</font>
<font color="#000000">> mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit</font>
<font color="#000000">> consistent gebeurt.</font>
<font color="#000000">></font>
<font color="#000000">> Eerst maar eens een inventarisatie:</font>
<font color="#000000">></font>
<font color="#000000">> Adres tags op pand of losse nodes</font>
<font color="#000000">> =============================</font>
<font color="#000000">> De BAG maakt onderscheid tussen panden, verblijfsobjecten en</font>
<font color="#000000">> nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.</font>
<font color="#000000">Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), </font>
<font color="#000000">maar moet daarvan nog voorbeeld zien.</font>
</pre>
    </blockquote>
    <font color="#000000">Hier is een mooi voorbeeld: VBO 0344010000091735 (Ambachtsweg 52, Utrecht) ik heb ook nog even geen</font><br>
    <font color="#000000">idee hoe we dit het beste in OSM zouden kunnen mappen.</font><br>
    <font color="#000000">Een ander voorbeeld is VBO </font><font color="#000000"><tt>0344100000054743 (Hoogravenseweg 140A). Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.</tt></font><br>

    <font color="#000000">Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met 2 panden per VBO. </font>
    <blockquote type="CITE">
<pre>
<font color="#000000">> Tot nu toe heb ik de adressen als volgt getagd:</font>
<font color="#000000">> Voor panden met een enkel verblijfsobject heb ik de adres tags</font>
<font color="#000000">> (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld</font>
<font color="#000000">> met in tag "ref:bagid" het BAG id van het pand.</font>
<font color="#000000">> Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen</font>
<font color="#000000">> adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De</font>
<font color="#000000">> adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het</font>
<font color="#000000">> BAG id van de nummeraanduiding.</font>
<font color="#000000">></font>
<font color="#000000">> ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te</font>
<font color="#000000">> koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van</font>
<font color="#000000">> het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id</font>
<font color="#000000">> van het pand in "bag:pand_id".</font>
<font color="#000000">></font>
<font color="#000000">> rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met</font>
<font color="#000000">> meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.</font>
<font color="#000000">Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model </font>
<font color="#000000">blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes </font>
<font color="#000000">zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In </font>
<font color="#000000">het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, </font>
<font color="#000000">Door-to-door navigation. En verder aansluiten bij algemene </font>
<font color="#000000">OSM-conventies voor adressen.</font>
</pre>
    </blockquote>
    <font color="#000000">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.</font><br>

    <font color="#000000">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.</font><br>

    <br>
    <blockquote type="CITE">
<pre>
<font color="#000000">></font>
<font color="#000000">> AssociatedStreet relaties</font>
<font color="#000000">> =====================</font>
<font color="#000000">> AssociatedStreet relaties bieden veel voor en nadelen en het laatste</font>
<font color="#000000">> woord is er nog niet over gesproken. Een voordeel dat in mijn ogen</font>
<font color="#000000">> onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde</font>
<font color="#000000">> straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen</font>
<font color="#000000">> straten in OSM en straten uit andere bronnen. Dat gaat echter alleen</font>
<font color="#000000">> werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het</font>
<font color="#000000">> invoeren, zie ik dat nog niet zo snel gebeuren.</font>
<font color="#000000">> De osmosis plug-in waarmee ik bezig ben bied een optie om</font>
<font color="#000000">> associatedstreet relaties te genereren, inclusief BAG openbareruimte id.</font>
<font color="#000000">> Vanwege de complexiteit bij het invoeren zijn we er echter vanaf gestapt</font>
<font color="#000000">> om die te gebruiken.</font>
<font color="#000000">> Ook ruudblank en rullzer lijken geen associatedstreet relaties toe te</font>
<font color="#000000">> voegen.</font>
<font color="#000000">></font>
<font color="#000000">> addr:city en addr:country tags</font>
<font color="#000000">> =========================</font>
<font color="#000000">> Toevoegen van addr:city en addr:country tags aan adressen gaat bij het</font>
<font color="#000000">> importeren van BAG data in een moeite mee. De vraag is of het wenselijk</font>
<font color="#000000">> is om dat ook te doen. Het zorgt voor erg veel redundantie.</font>
<font color="#000000">> ruudblank voegt addr:city toe, rullzer niet.</font>
<font color="#000000">> Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar</font>
<font color="#000000">> om addr:city toch maar te gaan toevoegen.</font>
<font color="#000000">City is dan Woonplaats neem ik aan. Gemeente en provincie?</font>
</pre>
    </blockquote>
    <font color="#000000">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. </font>
    <blockquote type="CITE">
<pre>
<font color="#000000">></font>
<font color="#000000">> Huisnummers</font>
<font color="#000000">> ===========</font>
<font color="#000000">> De BAG bevat de kolommen huisnummer, huisletter en huisnummertoevoeging.</font>
<font color="#000000">> OSM gebruikt alleen de tag "addr:housenumber". Hier is dus een vertaling</font>
<font color="#000000">> nodig waarbij je kunt kiezen om wel of geen spaties tussen de</font>
<font color="#000000">> verschillende delen van het huisnummer te plaatsen.</font>
<font color="#000000">> De BAG laat gemeenten vrij in het gebruik van hoofd en kleine letters.</font>
<font color="#000000">></font>
<font color="#000000">> rullzer: gebruikt geen spatie tussen huisnummer en huisletter</font>
<font color="#000000">> (huisnummertoevoeging kom ik in zijn gebied niet tegen).</font>
<font color="#000000">> ruudblank: gebruikt een spatie tussen huisnummer en huisletter en lijkt</font>
<font color="#000000">> huisnummertoevoeging weg te laten.</font>
<font color="#000000">> <a href="http://bagviewer.geodan.nl" target="_blank">bagviewer.geodan.nl</a>: gebruikt een spatie na het huisnummer en niet</font>
<font color="#000000">> tussen huisletter en huisnummertoevoeging.</font>
<font color="#000000">Offiële URL is <a href="http://pdok.nl/bagviewer" target="_blank">http://pdok.nl/bagviewer</a> (is nu nog dezelfde app).</font>
<font color="#000000">> <a href="http://www.kadaster.nl/BAG/producten/web.html" target="_blank">http://www.kadaster.nl/BAG/producten/web.html</a>: gebruikt geen spatie</font>
<font color="#000000">> tussen huisnummer en huisletter, maar wel tussen huisletter en</font>
<font color="#000000">> huisnummertoevoeging.</font>
<font color="#000000">></font>
<font color="#000000">> Zelf gebruik ik de laatste conventie. Die is ook het beste leesbaar.</font>
<font color="#000000">> (Vergelijk "42 abov" met "42a bov")</font>
<font color="#000000">></font>
<font color="#000000">> De adressen in de BAG komen ook niet altijd overeen met die op de gevel,</font>
<font color="#000000">> alleen al bij mij in de buurt:</font>
<font color="#000000">> BAG: 19 BSA, gevel: 19 BIS A</font>
<font color="#000000">> BAG: 100A A, gevel: 100 AA</font>
<font color="#000000">..</font>
<font color="#000000">></font>
<font color="#000000">> Versiebeheer</font>
<font color="#000000">> ===========</font>
<font color="#000000">> De BAG id code op zich is niet voldoende om te kunnen zien of een BAG</font>
<font color="#000000">> object in OSM nog actueel is. Daarvoor heeft de BAG 2 extra velden:</font>
<font color="#000000">> begindatumtijdvakgeldigheid en aanduidingrecordcorrectie.</font>
<font color="#000000">> begindatumtijdvakgeldigheid bepaalt vanaf welk moment een object een</font>
<font color="#000000">> bepaalde status heeft. Bijvoorbeeld 'Bouw gestart'</font>
<font color="#000000">> (building:construction) of 'Pand in gebruik' (building:yes). Deze waarde</font>
<font color="#000000">> kan als extra tag in OSM worden toegevoegd (Ik gebruik nu</font>
<font color="#000000">> "bag:begindatum", met "yyyy-MM-dd hh:mm:ss" als datum formaat).</font>
<font color="#000000">> aanduidingrecordcorrectie geeft aan dat er fouten gecorrigeerd zijn in</font>
<font color="#000000">> de BAG data. Helaas krijgt het meest recente record niet de hoogste</font>
<font color="#000000">> waarde voor 'aanduidingrecordcorrectie', maar de waarde 0. Het opslaan</font>
<font color="#000000">> van deze waarde in een OSM tag heeft dus niet zo veel zin. Ik denk dat</font>
<font color="#000000">> je de maximum waarde van 'aanduidingreccordcorrectie' in een OSM tag zou</font>
<font color="#000000">> moeten zetten, maar omdat ik dit proces nog niet helemaal doorgrond, heb</font>
<font color="#000000">> ik dat tot nu toe niet gedaan. Ook zou de betekenis van die tag zonder</font>
<font color="#000000">> grondige documentatie alleen maar voor verwarring zorgen. Daarom heb ik</font>
<font color="#000000">> er voorlopig voor gekozen om een tag "bag:extract" toe te voegen met</font>
<font color="#000000">> daarin de naam van het zip bestand waaruit de BAG data afkomstig is.</font>
<font color="#000000">> Daarmee is in ieder geval de versie van de BAG data af te leiden.</font>

<font color="#000000">Volgens mij zijn er 2 begrippen in de BAG om "aktieve"-non-duplicate </font>
<font color="#000000">records te krijgen: "actueel" en "bestaand". Heeft ook te maken dat er </font>
<font color="#000000">nooit iets wordt weggegooid uit de BAG, inclusief invoerfouten. Binnen </font>
<font color="#000000">NLExtract-BAG baseren we daar ook de SQL VIEWs op:</font>

<font color="#000000">- actueel: bepaald door de velden: begin/einddatumtijdvakgeldigheid en </font>
<font color="#000000">aanduidingrecordinactief</font>
<font color="#000000">- bestaand: bepaald door "status" veld bijv 'Pand gesloopt'</font>

<font color="#000000">Hieronder een stukje SQL voor pandactueelbestaand VIEW:</font>
<font color="#000000">    WHERE</font>
<font color="#000000">      pand.begindatumtijdvakgeldigheid <= LOCALTIMESTAMP</font>
<font color="#000000">      AND (pand.einddatumtijdvakgeldigheid is NULL OR </font>
<font color="#000000">pand.einddatumtijdvakgeldigheid >= LOCALTIMESTAMP)</font>
<font color="#000000">      AND pand.aanduidingrecordinactief = FALSE</font>
<font color="#000000">      AND pand.geom_valid = TRUE</font>
<font color="#000000">      AND (pand.pandstatus <> 'Niet gerealiseerd pand' AND </font>
<font color="#000000">pand.pandstatus  <> 'Pand gesloopt' );</font>
</pre>
    </blockquote>
    <font color="#000000">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.</font><br>

    <font color="#000000">De queries zouden nog iets simpeler kunnen bij gebruik van  'infinity' in plaats van 'null' voor niet ingevulde waarden van einddatumtijdvakgeldigheid. </font>
    <blockquote type="CITE">
<pre>
<font color="#000000">aanduidingreccordcorrectie heb ik nooit iets mee gedaan...</font>
</pre>
    </blockquote>
    <font color="#000000">Uit 'Handreiking voor afnemers van de BAG' versie 2009:</font><br>
    <font color="#000000">'De werking van het synchronisatiemechanisme en de toepassing van het</font><br>
    <font color="#000000">attribuut ‘aanduidingRecordCorrectie’ zijn nog onderwerp van onderzoek. In een</font><br>
    <font color="#000000">toekomstige release zal dit mechanisme mogelijk gaan veranderen en dit</font><br>
    <font color="#000000">attribuut niet meer worden toegepast.'</font><br>
    <br>
    <font color="#000000">Ik hoop dat dit onderzoek binnenkort een bruikbaardere oplossing bied.</font><br>
    <br>
    <font color="#000000">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.</font><br>

    <br>
    <br>
    <blockquote type="CITE">
<pre>
<font color="#000000">En dan is er nog INSPIRE Addresses voor wie nog leestijd over heeft :-) :</font>
<font color="#000000"><a href="http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.1.pdf" target="_blank">http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.1.pdf</a></font>
<font color="#000000">Het Adres-model is overly complex GML maar aan eind van document staat </font>
<font color="#000000">wel goed uitgelegd hoe adres-conventies in verschillende landen werken.</font>
</pre>
    </blockquote>
    <font color="#000000">Bedank voor de link. Als ik tijd vind ga duik is er eens in.</font><br>
    <br>
    <font color="#000000">Groeten, Gertjan </font>
    <blockquote type="CITE">
<pre>
<font color="#000000">groeten,</font>

<font color="#000000">Just van den Broecke</font>
<font color="#000000"><a href="http://www.justobjects.nl" target="_blank">www.justobjects.nl</a></font>
<font color="#000000"><a href="http://www.nlextract.nl" target="_blank">www.nlextract.nl</a></font>


<font color="#000000">></font>
<font color="#000000">> Gertjan Idema</font>
<font color="#000000">></font>
<font color="#000000">></font>
<font color="#000000">></font>
<font color="#000000">> _______________________________________________</font>
<font color="#000000">> Talk-nl mailing list</font>
<font color="#000000">> <a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a></font>
<font color="#000000">> <a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.org/listinfo/talk-nl</a></font>
<font color="#000000">></font>





<font color="#000000">_______________________________________________</font>
<font color="#000000">Talk-nl mailing list</font>
<font color="#000000"><a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a></font>
<font color="#000000"><a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.org/listinfo/talk-nl</a></font>
</pre>
    </blockquote>
    <br>
    <br>
    <br>
    
<hr align="center">
<br>
    <font color="#000000">_______________________________________________</font><br>
    <font color="#000000">Talk-nl mailing list</font><br>
    <font color="#000000"><a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a></font><br>
    <font color="#000000"><a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.org/listinfo/talk-nl</a></font><br>
    <br>
</blockquote>
<blockquote type="CITE">
<pre>
_______________________________________________
Talk-nl mailing list
<a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.org/listinfo/talk-nl</a>
</pre>
</blockquote>
<br>
</div>

<br>_______________________________________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org">Talk-nl@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.org/listinfo/talk-nl</a><br>
<br></blockquote></div>