Op <a href="https://www.kadaster.nl/particulier/producten/bestel.asp?soort=terugmelding_br">https://www.kadaster.nl/particulier/producten/bestel.asp?soort=terugmelding_br</a> kun je ook een melding maken. <br><br>Zie ook <a href="http://pdok.nl/bagviewer/">http://pdok.nl/bagviewer/</a> de Terugmelding of Correctieverzoek<br>
<br><div class="gmail_quote">Op 20 oktober 2012 13:38 schreef Just van den Broecke <span dir="ltr"><<a href="mailto:just@justobjects.nl" target="_blank">just@justobjects.nl</a>></span> het volgende:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Beste Pander,<br>
<br>
Heb je de standaard terugmelding per email al geprobeerd:<br>
<a href="mailto:bag@kadaster.nl" target="_blank">bag@kadaster.nl</a><br>
zie<br>
<a href="http://bag.vrom.nl/de_bag_gebruiken/terugmelden" target="_blank">http://bag.vrom.nl/de_bag_<u></u>gebruiken/terugmelden</a><br>
<br>
"Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per e-mail melden op <a href="mailto:bag@kadaster.nl" target="_blank">bag@kadaster.nl</a>. 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."<br>
<br>
groeten,<br>
<br>
Just<div class="HOEnZb"><div class="h5"><br>
On 20-10-12 13:32, Pander wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-10-20 13:21, Just van den Broecke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Beste Gertjan e.a,<br>
<br>
Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week<br>
ververst met versie 8 sept en 8 okt:<br>
<a href="http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml" target="_blank">http://geodata.<u></u>nationaalgeoregister.nl/<u></u>inspireadressen/atom/<u></u>inspireadressen.xml</a><br>
(Atom).<br>
e.e.a. moet ook simpeler worden in de toekomst:<br>
<a href="http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds" target="_blank">http://drupal.pdokloket.nl/nl/<u></u>producten/pdok-downloads/<u></u>atomfeeds</a><br>
<br>
Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.<br>
</blockquote>
<br>
Voor wie interesse heeft: ik heb nog een hele lijst van correcties op de<br>
BAG-gegevens. Met name coderings- en typefouten zitten er redelijk wat in.<br>
<br>
Ook zou het handig zijn als het Kadaster er iets mee zou willen doen?<br>
<br>
Ik heb ze al eens geschreven over fouten in toponiemen uit 1:25.000<br>
kaarten (TOP25) maar toen hadden ze geen interesse. Hun reden was dat ze<br>
er zelf al mee aan de slag waren.<br>
<br>
Voor BAG denk ik niet dat ze op de hoogte zijn van deze fouten, ook<br>
omdat het een gigantische collectie is. Heeft iemand een ingang<br>
hiervoor? Volgens de wet moeten ze volgens mij openstaan voor<br>
terugmelding van correcties.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17-10-12 13:11, Gertjan Idema wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Er is een aantal initiatieven gaande voor het opnemen van BAG data in<br>
Openstreetmap.<br>
- ruudblank heeft veel werk verricht in Gorinchem.<br>
- rullzer in de omgeving Purmerend<br>
- mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee<br>
(Leusden) en Sebastiaan (Oldambt) nu kleinschalig<br>
aan het testen zijn.<br>
- en ongetwijfeld nog meer.<br>
<br>
Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee<br>
van deze discussie is om hier samen te vatten wat er tot nu toe gedaan<br>
en besproken is over het taggen van data afkomstig uit de BAG.<br>
Vervolgens hoop ik dat we het samen eens kunnen worden over een<br>
standaard. Deze kan dan opgenomen worden op de Wiki pagina en<br>
geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel<br>
mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit<br>
consistent gebeurt.<br>
<br>
Eerst maar eens een inventarisatie:<br>
<br>
Adres tags op pand of losse nodes<br>
=============================<br>
De BAG maakt onderscheid tussen panden, verblijfsobjecten en<br>
nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.<br>
</blockquote>
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO),<br>
maar moet daarvan nog voorbeeld zien.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tot nu toe heb ik de adressen als volgt getagd:<br>
Voor panden met een enkel verblijfsobject heb ik de adres tags<br>
(addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld<br>
met in tag "ref:bagid" het BAG id van het pand.<br>
Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen<br>
adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De<br>
adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het<br>
BAG id van de nummeraanduiding.<br>
<br>
ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te<br>
koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van<br>
het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id<br>
van het pand in "bag:pand_id".<br>
<br>
rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met<br>
meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.<br>
</blockquote>
Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model<br>
blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes<br>
zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In<br>
het achterhoofd ook het soort gebruik van OSM adressen: Geocoders,<br>
Door-to-door navigation. En verder aansluiten bij algemene<br>
OSM-conventies voor adressen.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
AssociatedStreet relaties<br>
=====================<br>
AssociatedStreet relaties bieden veel voor en nadelen en het laatste<br>
woord is er nog niet over gesproken. Een voordeel dat in mijn ogen<br>
onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde<br>
straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen<br>
straten in OSM en straten uit andere bronnen. Dat gaat echter alleen<br>
werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het<br>
invoeren, zie ik dat nog niet zo snel gebeuren.<br>
De osmosis plug-in waarmee ik bezig ben bied een optie om<br>
associatedstreet relaties te genereren, inclusief BAG openbareruimte id.<br>
Vanwege de complexiteit bij het invoeren zijn we er echter vanaf gestapt<br>
om die te gebruiken.<br>
Ook ruudblank en rullzer lijken geen associatedstreet relaties toe te<br>
voegen.<br>
<br>
addr:city en addr:country tags<br>
=========================<br>
Toevoegen van addr:city en addr:country tags aan adressen gaat bij het<br>
importeren van BAG data in een moeite mee. De vraag is of het wenselijk<br>
is om dat ook te doen. Het zorgt voor erg veel redundantie.<br>
ruudblank voegt addr:city toe, rullzer niet.<br>
Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar<br>
om addr:city toch maar te gaan toevoegen.<br>
</blockquote>
City is dan Woonplaats neem ik aan. Gemeente en provincie?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Huisnummers<br>
===========<br>
De BAG bevat de kolommen huisnummer, huisletter en huisnummertoevoeging.<br>
OSM gebruikt alleen de tag "addr:housenumber". Hier is dus een vertaling<br>
nodig waarbij je kunt kiezen om wel of geen spaties tussen de<br>
verschillende delen van het huisnummer te plaatsen.<br>
De BAG laat gemeenten vrij in het gebruik van hoofd en kleine letters.<br>
<br>
rullzer: gebruikt geen spatie tussen huisnummer en huisletter<br>
(huisnummertoevoeging kom ik in zijn gebied niet tegen).<br>
ruudblank: gebruikt een spatie tussen huisnummer en huisletter en lijkt<br>
huisnummertoevoeging weg te laten.<br>
<a href="http://bagviewer.geodan.nl" target="_blank">bagviewer.geodan.nl</a>: gebruikt een spatie na het huisnummer en niet<br>
tussen huisletter en huisnummertoevoeging.<br>
</blockquote>
Offiële URL is <a href="http://pdok.nl/bagviewer" target="_blank">http://pdok.nl/bagviewer</a> (is nu nog dezelfde app).<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://www.kadaster.nl/BAG/producten/web.html" target="_blank">http://www.kadaster.nl/BAG/<u></u>producten/web.html</a>: gebruikt geen spatie<br>
tussen huisnummer en huisletter, maar wel tussen huisletter en<br>
huisnummertoevoeging.<br>
<br>
Zelf gebruik ik de laatste conventie. Die is ook het beste leesbaar.<br>
(Vergelijk "42 abov" met "42a bov")<br>
<br>
De adressen in de BAG komen ook niet altijd overeen met die op de gevel,<br>
alleen al bij mij in de buurt:<br>
BAG: 19 BSA, gevel: 19 BIS A<br>
BAG: 100A A, gevel: 100 AA<br>
</blockquote>
..<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Versiebeheer<br>
===========<br>
De BAG id code op zich is niet voldoende om te kunnen zien of een BAG<br>
object in OSM nog actueel is. Daarvoor heeft de BAG 2 extra velden:<br>
begindatumtijdvakgeldigheid en aanduidingrecordcorrectie.<br>
begindatumtijdvakgeldigheid bepaalt vanaf welk moment een object een<br>
bepaalde status heeft. Bijvoorbeeld 'Bouw gestart'<br>
(building:construction) of 'Pand in gebruik' (building:yes). Deze waarde<br>
kan als extra tag in OSM worden toegevoegd (Ik gebruik nu<br>
"bag:begindatum", met "yyyy-MM-dd hh:mm:ss" als datum formaat).<br>
aanduidingrecordcorrectie geeft aan dat er fouten gecorrigeerd zijn in<br>
de BAG data. Helaas krijgt het meest recente record niet de hoogste<br>
waarde voor 'aanduidingrecordcorrectie', maar de waarde 0. Het opslaan<br>
van deze waarde in een OSM tag heeft dus niet zo veel zin. Ik denk dat<br>
je de maximum waarde van 'aanduidingreccordcorrectie' in een OSM tag zou<br>
moeten zetten, maar omdat ik dit proces nog niet helemaal doorgrond, heb<br>
ik dat tot nu toe niet gedaan. Ook zou de betekenis van die tag zonder<br>
grondige documentatie alleen maar voor verwarring zorgen. Daarom heb ik<br>
er voorlopig voor gekozen om een tag "bag:extract" toe te voegen met<br>
daarin de naam van het zip bestand waaruit de BAG data afkomstig is.<br>
Daarmee is in ieder geval de versie van de BAG data af te leiden.<br>
</blockquote>
<br>
Volgens mij zijn er 2 begrippen in de BAG om "aktieve"-non-duplicate<br>
records te krijgen: "actueel" en "bestaand". Heeft ook te maken dat er<br>
nooit iets wordt weggegooid uit de BAG, inclusief invoerfouten. Binnen<br>
NLExtract-BAG baseren we daar ook de SQL VIEWs op:<br>
<br>
- actueel: bepaald door de velden: begin/<u></u>einddatumtijdvakgeldigheid en<br>
aanduidingrecordinactief<br>
- bestaand: bepaald door "status" veld bijv 'Pand gesloopt'<br>
<br>
Hieronder een stukje SQL voor pandactueelbestaand VIEW:<br>
WHERE<br>
pand.<u></u>begindatumtijdvakgeldigheid <= LOCALTIMESTAMP<br>
AND (pand.<u></u>einddatumtijdvakgeldigheid is NULL OR<br>
pand.<u></u>einddatumtijdvakgeldigheid >= LOCALTIMESTAMP)<br>
AND pand.aanduidingrecordinactief = FALSE<br>
AND pand.geom_valid = TRUE<br>
AND (pand.pandstatus <> 'Niet gerealiseerd pand' AND<br>
pand.pandstatus <> 'Pand gesloopt' );<br>
<br>
aanduidingreccordcorrectie heb ik nooit iets mee gedaan...<br>
<br>
En dan is er nog INSPIRE Addresses voor wie nog leestijd over heeft :-) :<br>
<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.<u></u>eu/documents/Data_<u></u>Specifications/INSPIRE_<u></u>DataSpecification_AD_v3.0.1.<u></u>pdf</a><br>
<br>
Het Adres-model is overly complex GML maar aan eind van document staat<br>
wel goed uitgelegd hoe adres-conventies in verschillende landen werken.<br>
<br>
groeten,<br>
<br>
Just van den Broecke<br>
<a href="http://www.justobjects.nl" target="_blank">www.justobjects.nl</a><br>
<a href="http://www.nlextract.nl" target="_blank">www.nlextract.nl</a><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Gertjan Idema<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk-nl</a><br>
<br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk-nl</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk-nl</a><br>
<br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-nl mailing list<br>
<a href="mailto:Talk-nl@openstreetmap.org" target="_blank">Talk-nl@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-nl" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk-nl</a><br>
</div></div></blockquote></div><br>