Op https://www.kadaster.nl/particulier/producten/bestel.asp?soort=terugmelding_br kun je ook een melding maken.
Zie ook http://pdok.nl/bagviewer/ de Terugmelding of Correctieverzoek Op 20 oktober 2012 13:38 schreef Just van den Broecke <j...@justobjects.nl>het volgende: > Beste Pander, > > Heb je de standaard terugmelding per email al geprobeerd: > b...@kadaster.nl > zie > http://bag.vrom.nl/de_bag_**gebruiken/terugmelden<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 b...@kadaster.nl. 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." > > 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<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<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<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<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 >>>> Talk-nl@openstreetmap.org >>>> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl> >>>> >>>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> Talk-nl mailing list >>> Talk-nl@openstreetmap.org >>> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl> >>> >> >> >> ______________________________**_________________ >> Talk-nl mailing list >> Talk-nl@openstreetmap.org >> http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl> >> >> > > > > > > > > ______________________________**_________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk-nl<http://lists.openstreetmap.org/listinfo/talk-nl> >
_______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl