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.id...@zonnet.nl <mailto:g.id...@zonnet.nl>
> <mailto:g.id...@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.id...@zonnet.nl>
>> *Sent:*Saturday, October 20, 2012 8:54 PM
>> *To:*talk-nl@openstreetmap.org <mailto:*talk-nl@openstreetmap.org>
<mailto:talk-nl@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@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
<mailto:Talk-nl@openstreetmap.org>
>>> >http://lists.openstreetmap.org/listinfo/talk-nl
>>> >
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-nl mailing list
>>>Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
<mailto:Talk-nl@openstreetmap.org>
>>>http://lists.openstreetmap.org/listinfo/talk-nl
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Talk-nl mailing list
>>Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
<mailto:Talk-nl@openstreetmap.org>
>>http://lists.openstreetmap.org/listinfo/talk-nl
>>
>> _______________________________________________
>> Talk-nl mailing list
>>Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
<mailto:Talk-nl@openstreetmap.org>
>>http://lists.openstreetmap.org/listinfo/talk-nl
>
>
> _______________________________________________
> Talk-nl mailing list
>Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
<mailto:Talk-nl@openstreetmap.org>
>http://lists.openstreetmap.org/listinfo/talk-nl
>
>
>
> _______________________________________________
> Talk-nl mailing list
>Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
>http://lists.openstreetmap.org/listinfo/talk-nl
_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org <mailto:Talk-nl@openstreetmap.org>
http://lists.openstreetmap.org/listinfo/talk-nl