Uitvoerige landmeetkundige/geodetische vragen over OSM NL

Ach, iemand die zich bewust is van consistente afwijking in een bron kan dat ook weer zelf compenseren, zoals het Kadaster met de RDNAPTRANS omrekenings-truc (correctiegrid) heeft gedaan. Maar inderdaad de situatie is wel ingewikkeld door tal van coordinatensystemen met elk hun eigen afwijkingen en speciale dingetjes wereldwijd, wat vervolgens weer de omgerekende coördinaten beïnvloed.

Ik weet niet of het al bestaat, maar is het niet een idee om een uitgebreide wiki pagina hier over te maken, specifiek voor NL? Ook in het Engels, dan is het namelijk tenminste goed gedocumenteerd.
Ook een potentieel interessant idee is een programma dat osm coördinaten uit heel Europa omrekend naar absoluut correcte (alle systematische fout er uit, ruis zal je altijd hebben) ETRS89 coördinaten. Zo’n programma zou natuurlijk kennis moeten hebben van de verscheidene landelijke systemen en hun systematische afwijkingen. Het ingewikkelde daar aan is die 2.5cm verschuiving per jaar, je zou eigenlijk naar mutatiedatum per node moeten kijken en daarop gebaseerd rekenen, en natuurlijk dat import data en non-import data door elkaar heen wordt gebruikt.

Alas, absolute positie is lang niet zo belangrijk als onderlinge fout.

Het blijkt allemaal nog ingewikkelder dan voorheen gedacht. Er zijn zelfs verschillende transformaties voor het omrekenen zonder RDNAPTRANS correctiegrid.

Gebruikt de BAG-import plugin de JOSM projecties of doet de plugin zelfstandige reprojectie?

Volgens mij laat de plugin het over aan de WFS service waar het de data van opvraagt.

De BAG-import plugin gebruikt proj4j (De Java variant van proj4) voor de reprojectie. Bij het begin van de plugin was het RD coordinatenstelsel nog niet beschikbaar in Josm zelf. Ik heb ook naar Geotools gekeken, daar zat destijds een afwijking in de RD coordinaten.
Ook voor de BAG plugin geldt wat mij betreft:

Is er in de BAG-import plugin een transformatie string gespecificeerd? (+towgs84) Zo ja, welke string is dat precies? Of geef je simpelweg op: transformeer van EPSG:28992 naar EPSG:4326 en laat je het proj4 verder zelf uitzoeken?

+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725

Interessant, in OSM (beiden JOSM en BAG-import blijkt) gebruiken we dus de EPSG:4833 transformatie, afkomstig van de Nederlandse Commissie voor Geodesie uit 2008. Dat is dan ook de meest recente transformatie.

JOSM en de BAG-import plugin hebben wel beiden de van microradialen naar boogseconde omgerekende transformatie-parameters voor rotatie net wat anders afgerond: JOSM heeft meer cijfertjes dan de BAG-import plugin.

Ik denk dat het belangrijk is voor ons om er van bewust te zijn dat wij hier een apart geval zijn, aangezien PROJ4 standaard de EPSG:15934 transformatie gebruikt. GDAL, Mapserver, QGIS etc gebruiken dus standaard een andere transformatie dan wij in OSM gebruiken om RD om te zetten in WGS84 en vice versa. Als wij dingen met zulke GIS software doen moeten we dus eigenlijk even onze eigen transformatie-string specificeren.

Waarschijnlijk wijken de PDOK luchtfoto’s als we die niet aanvragen in RD dus ook af van onze transformatie, maar ik vermoed dat de afwijking verwerpelijk is, zeker aangezien die luchtfoto’s toch maar een resolutie van 25cm/pixel bevatten.
Misschien dat ik die afwijking later nog eens bereken, in dat geval zal ik hem hier bij vernoemen.

(deze post is vooral bedoeld als conclusie voor mensen die later deze thread lezen, ter verduidelijking)

Bedankt voor alle informatie, Gertjan en Cavit! :slight_smile:

Schijnbaar is het nóg ingewikkelder. Het lukt me maar niet om een BAG pand binnen 1mm te repliceren, er zit telkens minder dan een centimer afwijking in. Doet de BAG update plugin of ODS ergens bewust coördinaten afronden?

De plug-in gebruikt de zelfde afronding als de openstreetmap database. Die is 7 decimalen voor de lengte- en breedtegraad. Dat is zo’n 5 mm in noord-zuid richting en op de evenaar is zo’n 9 mm in oost-west richting. Verder van de evenaar wordt het minder in oost-west richting.

Dat verklaart een hoop :slight_smile:

Een kleine correctie:

Die 9 mm klopt volgens mij niet.
Op de evenaar komt een graad in zowel lengte als breedte overeen met zo’n 111 km (= de omtrek van de aarde gedeeld door 360 graden=40000km / 360).
De zevende decicimaal (0,000 000 1 graad) is dan zo’n 11,1 mm. Dus de afrondfout zowel in noord-zuid- als in oost-west-richting is maximaal de helft hiervan: zo’n 5,5 mm.

https://blog.openstreetmap.org/2017/03/31/osm-plate-tectonics/
Weet iemand hier meer van? Als ze dit werkelijk elk jaar doen, ook in NL, stort ons hele luchtkasteel van heen en terug transformaties en onderlinge integriteit in zee.

“This entry was posted in geodata on March 31, 2017 by Frederik Ramm.”
Wat was het de dag hierna? :slight_smile:

De Aarde zet dus uit als een ballon. Dat wist ik niet eens!!
Balloon-earth, the new myth? :slight_smile:

De platen drijven horizontaal van elkaar weg op sommige plaatsen, en op andere plaatsen schuiven ze op en over elkaar (met soms aardbevingen als gevolg). De aarde zet verder niet uit in verticale richting. :slight_smile:

Was het ook werkelijk een 1 april grap? Anderzijds zouden we het moeten merken met onze BAG import

Jeroen, hij zegt dat de platen uit elkaar drijven. Dat kan alleen op een uitdijende aarde.
Sterrenstelsels doen dat ook; het heelal dijt uit.
De stelling dat de tektonische platen uit elkaar drijven klopt natuurlijk niet. Ze drijven alle kanten op en als er twee uit elkaar drijven dan is dat toeval.

De Europese plaat verschuift langzaam ten opzichte van het WGS84 referentiesysteem

Hier is de voortschrijdende afwijking voor Nederland

Internationaal is men ook op de hoogte van pswudo-WGS84 coördinaten in verschillends landen.
https://www.openstreetmap.org/user/StephaneP/diary/390290

Mooie samenvatting.