Beste Pander, Als je mij een lijstje met correcties stuurt, wil ik wel kijken of ik er BAG id's aan kan koppelen.
Gertjan On Sat, 2012-10-20 at 13:54 +0200, Pander wrote: > On 2012-10-20 13:38, Just van den Broecke wrote: > > Beste Pander, > > > > Heb je de standaard terugmelding per email al geprobeerd: > > [email protected] > > zie > > http://bag.vrom.nl/de_bag_gebruiken/terugmelden > > > > "Als u gerede twijfel heeft over de juistheid van de informatie in de > > BAG, dan kunt u dit per e-mail melden op [email protected]. In het > > onderwerpveld van de e-mail dient u de gemeente te vermelden waarbinnen > > het object valt. De betreffende object ID('s) dient u te vermelden in uw > > bericht, plus hetgeen u over twijfelt. Voor private afnemers geldt geen > > terugmeldingsplicht. Bij gerede twijfel kan er rechtstreeks bij de > > bronhouder teruggemeld worden." > > Dank je wel. Alleen heb ik niet een overzicht van die ID's. Doe moeten > er bijgezocht worden als mijn correcties worden uitgevoerd. Aangezien ik > correcties doe nadat het ID gestript is is dat een hoop extra werk. > > Is er iemand die veel met BAG-gegevens werkt en al bestaande scripts > heeft die mijn lijst van correcties als een filter op wil nemen en zo > rapportjes kan genereren om terug te zenden naar het Kadaster. > > Voordeel als je hiermee aan de slag gaat is dat de gecorrigeerde > BAG-gegevens van veel hogere kwaliteit zijn. Vanuit OpenTaal ga ik door > de BAG-gegevens voor spellingcontrole maar de geografische informatie > interesseert ons verder niet. Dit ligt om die reden buiten ons domein. > Vandaar de zoektocht naar een BAG-liefhebber om het stokje aan door te > geven. > > > groeten, > > > > Just > > On 20-10-12 13:32, Pander wrote: > >> On 2012-10-20 13:21, 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: > >>> 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. > >> > >> Voor wie interesse heeft: ik heb nog een hele lijst van correcties op de > >> BAG-gegevens. Met name coderings- en typefouten zitten er redelijk wat > >> in. > >> > >> Ook zou het handig zijn als het Kadaster er iets mee zou willen doen? > >> > >> Ik heb ze al eens geschreven over fouten in toponiemen uit 1:25.000 > >> kaarten (TOP25) maar toen hadden ze geen interesse. Hun reden was dat ze > >> er zelf al mee aan de slag waren. > >> > >> Voor BAG denk ik niet dat ze op de hoogte zijn van deze fouten, ook > >> omdat het een gigantische collectie is. Heeft iemand een ingang > >> hiervoor? Volgens de wet moeten ze volgens mij openstaan voor > >> terugmelding van correcties. > >> > >>> 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. > >>>> 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. > >>>> > >>>> 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? > >>>> > >>>> 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' ); > >>> > >>> aanduidingreccordcorrectie heb ik nooit iets mee gedaan... > >>> > >>> 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. > >>> > >>> groeten, > >>> > >>> Just van den Broecke > >>> www.justobjects.nl > >>> www.nlextract.nl > >>> > >>> > >>> > >>>> > >>>> Gertjan Idema > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Talk-nl mailing list > >>>> [email protected] > >>>> http://lists.openstreetmap.org/listinfo/talk-nl > >>>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Talk-nl mailing list > >>> [email protected] > >>> http://lists.openstreetmap.org/listinfo/talk-nl > >> > >> > >> _______________________________________________ > >> Talk-nl mailing list > >> [email protected] > >> http://lists.openstreetmap.org/listinfo/talk-nl > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > Talk-nl mailing list > > [email protected] > > http://lists.openstreetmap.org/listinfo/talk-nl > > > _______________________________________________ > Talk-nl mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-nl
_______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
