Idee om wat met BAG te gaan doen

Goed dat ze er zijn, maar die bestanden zijn enkel een alternatief voor de RDNAPTRANS-procedure, dus van RD naar ETRS89. Voor OSM hebben we WGS 84-coördinaten nodig, die 65 cm afwijken van ETRS89. Het lijkt erop dat PCTrans het enige programma is dat deze laatste conversie kan uitvoeren.
Overigens hebben om dezelfde reden alle uit BAG geïmporteerde woonplaatsgrenzen een kleine afwijking van 65 cm met de realiteit.

Cavit, begrijp ik nu goed dat het Kadaster ook deze 65cm afwijking heeft ?
m.a.w. dat de BAG data ook in WGS84 aangeleverd wordt? Of wordt deze BAG data in RD coördinaten omgezet naar WGS84

Het laatste, BAG wordt in RD-coördinaten geleverd en voor OSM-toepassingen omgezet naar WGS 84. De afwijking ontstaat bij deze omzetting.

BAG wordt geleverd in RD. De conversie in de plug-in maakt er (blijkbaar) ETRS89 van, terwijl ik in de code WGS84 opvraag. Dat is ook ergens wel logisch, want ik hoef bij de conversie nergens een datum als parameter mee te geven. Achteraf ben ik er ook wel blij mee. WGS84 zou voor de panden een nachtmerrie worden, omdat een pand dat je vandaag importeert en over een jaar of wat opnieuw zou importeren dan meer dan 10cm verschoven zou zijn.
Typisch geval van voorschrijdend inzicht. In de begintijd van Openstreetmap, was de kaart veel minder gedetailleerd en was WGS84 ruim voldoende. Zo langzamerhand zou het misschien beter zijn om per continentale plaat een ander coordinaten stelsel te gebruiken ETRS89 voor Europa, NAD83 voor Noord-America etc.

In een oud draadje van 22.03.14 werd de mogelijkheid om via een TMS laag, grenzen zichtbaar te maken.
Deze heeft tot heden goed gewerkt, en was een heel prettig hulpmiddel om de grenzen van landen, provincies, gemeenten, steden, dorpen en gehuchten (van heel de wereld) op een mooie en snelle manier in beeld te krijgen.

Weet iemand waarom het (vandaag) niet meer werkt?

tms:http://129.206.74.245:8007/tms_b.ashx?x={x}&y={y}&z={z}

Werkt deze: http://129.206.66.245:8007/tms_b.ashx?x={x}&y={y}&z={z} ?

Wonderbaarlijk, deze werkt wel.
Ik heb deze even vergeleken met welke ik vermelde, maar ik zie geen verschillen.
Daarentegen werkt deze wel, en die andere niet meer.

tms:http://129.206.74.245:8007/tms_b.ashx?x={x}&y={y}&z={z} werkt niet
tms:http://129.206.66.245:8007/tms_b.ashx?x={x}&y={y}&z={z} werkt wel

Ik zie nu dat er wel degelijk een ander ip adres wordt gebruikt.

Is dit niet iets dat een keer op de dev-mailinglijst besproken zou kunnen worden? Dit probleem wordt er met de loop der jaren niet kleiner op. Je wilt natuurlijk ook niet ieder jaar alle data 2,5 cm opschuiven.

Heb je nog iemand nodig om dit te testen? Ik had in de oude plugin problemen met een aantal nieuwe huizen die ik niet geïmporteerd kreeg, terwijl de status op pand in gebruik staat.

Bedankt voor je aanbod. Ik ben nu met 3 mensen versie 0.6.4. aan het testen, wat op niet al te lange termijn tot een versie 0.6.5 moet leiden. Voor mij is het het handigst als je bij die versie instapt.
Waar stonden de huizen die je niet geimporteerd kreeg? Dan kan ik alvast even kijken of ze nu mee komen. Het echte importeren laat ik aan jou over.

Het gaat om de Stakenberg 65 t/m 83, Ede. De huisnummers t/m 63 importeerden wel goed.

De nieuwe verlsie importeert deze panden en adressen zonder problemen.

Hoe gaan we om met hergebruik van historische gebouwen ? Houden we voor het gemak de door de gemeente aangehouden (foutieve) verbouw datum aan of de originele stichtingsdatum en eventueel de ontwerper (architect), etc ?

Ik kreeg van een Gemeente dit antwoord terug

“Wij hebben geconstateerd dat het pand wel een kleine ronding op de begane grond heeft (draaideur) maar dat de verdiepingen oversteken, en alles wat hoger is dan 1,50 op verdiepingsniveau dient ook in BAG te worden ingetekend, het pand is dus iets groter geworden.”

Ik ging er steeds vanuit dat wat wij zien en intekenen op funderingsniveau is.

edit: van een hierop volgende mail

“In BAG wordt gekeken naar het bovenaanzicht (in tegenstelling tot de GBKN waarbij gekeken werd naar maaiveldniveau), met dien verstande dat de overbouw alleen word meegenomen als deze substantieel is, dus niet als het alleen om een overstekende dakconstructie gaat.”

Voor mijn huis klopt dat dan al niet. Mijn huis staat in de BAG met de inspringende voorgevel die op maaiveldniveau is te zien. Op de luchtfoto is dat niet te zien, maar de BAG toont wel degelijk maaiveld niveau.

Ik had een vraag over het taggen van admin_level bij dorp polygonen. Ik zie bij de polygonen source = BAG staan, dus denk dat ik in dit topic het beste mijn vraag kan stellen.

Op deze pagina zie ik dat in Nederland dorpen als admin_level 9 worden gemarkeerd en wijken als admin_level 10. Nu ben ik erachter gekomen dat dorpgrens polygonen in OSM als admin_level 10 gemarkeerd worden (zie Malden, Beers, Urk als voorbeeld). Dit heeft tot gevolg dat wanneer ik bijvoorbeeld Nominatim (geocoder om adres → coordinaat en andersom te rekenen) gebruik, het lijkt alsof deze weg in het dorp Heumen zit met als wijk Malden. Dit terwijl daadwerkelijk Malden het dorp is en Heumen de gemeente.

Mijn vraag is dus eigenlijk: wat is de logica van het taggen van admin_level in Nederland? Is de pagina van OSM outdated? Is dit een fout die meegenomen is uit BAG?

Je word in de war gebracht door de foutieve vertaling op de OpenStreetMap website van de admin_level zoals deze in Nederland worden gebruikt. Het volgende heb ik eerder gepost in het topic: Vervallen gemeentegrenzen:

Toch vind ik het vreemd.
Op 17 november 2015 was Netherlands nog niet opgenomen in de wiki (10 admin_level values for specific countries:).
https://wiki.openstreetmap.org/w/index.php?title=Template:Admin_level_10&oldid=1243416

Deze is pas geupload op 25 november 2015.

En bovenstaande wijkt af van:

Nu zie ik dat er een proposal heeft aangebracht op de wiki Tag:boundary=administrative op 25 november 2015

Nu begrijp ik ook de verwarring die ontstaan is omtrent de adresvlakken

Is het verstandig om een nieuwe topic te openen, om tot overeenstemming te komen in het gebruik in Nederland op de Tag;boundary=administrative site?

Op de wiki Tag:boundary=admistrative staat helemaal onderaan

11 admin_level values for specific countries
Deze is geplaatst op 29 november 2014 dit lijkt juist te zijn.

11_admin_level_values_for_specific_countries

Waarom Netherlands opgenomen is in “10 admin_level values for specific countries” is me nog onduidelijk.
Het lijkt mij dat 10 admin_level geheel mag komen te vervallen.

10 admin_level values for specific countries: