Lijkt me de goede benadering. Hugo Op 21 okt. 2012 11:07 schreef "Gertjan Idema" <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 <g.id...@zonnet.nl> > > *Sent:* Saturday, October 20, 2012 8:54 PM > > *To:* 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: gebruikt een > >> spatie na het huisnummer en niet> tussen huisletter en > >> huisnummertoevoeging.Offiële URL is http://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.pdfHet > 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 Broeckewww.justobjects.nlwww.nlextract.nl > > >> Gertjan Idema>>>> _______________________________________________> Talk-nl > >> mailing list> Talk-nl@openstreetmap.org> > >> http://lists.openstreetmap.org/listinfo/talk-nl> > > > > > _______________________________________________Talk-nl mailing > listTalk-nl@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-nl > > > > > ------------------------------ > > _______________________________________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > > > _______________________________________________ > Talk-nl mailing > listTalk-nl@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-nl > > > > _______________________________________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > >
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl