Sinds QGIS 3.8 krijg ik bij het openen van een qgz bestand de vraag welke datum transformatie ik moet kiezen, zie het plaatje. Weet iemand welke ik dien te kiezen?
Dit voorbeeld hieronder is vanwege een Google Satellite laag die ik via de Map Library plugin heb geladen.
Ha @jhpoosthoek! Gebruik de onderste. De anderen hebben steeds als laatste zin “Replaced by…”. Maar wie vertelt me, in welke situaties je toch een van de andere opties zou gebruiken?
Ha @emacgillavry, is dit voor alle transformaties toepasbaar, of alleen deze specifiek? Ik krijg het ook bij RD met WGS84.
Is dit niet afhankelijk van het jaar waarin je data is opgenomen omdat we in de tussentijd een stukje zijn bewogen tov. het ETRS89 referentiepunt?
Deze presentatie van Lennard Huisman geeft een overzicht van verschillende transformatieparameters (p 18)
TL;DR:
<2005: +towgs84=565.0400,49.9100,465.8400,-0.409394,0.359705,-1.868491,4.0772
2005-2008 +towgs84=565.2369,50.0087,465.6580,-0.406857,0.350733,-1.870347,4.0812
>=2009: +towgs84=565.4171,50.3319,465.5524,-0.398957,0.343988,-1.877402,4.0725
Hoi Tom,
klinkt logisch, maar hoe bepaal je wat wat is? De omschrijvingen in de popup zijn onbegrijpelijk.
Kunnen we een tekst verzinnen of een uitleg aan QGIS laten toevoegen voor de gebruikers, zodat we weten wat we moeten kiezen en waarom?
Is er al een lijstje met de meest logische keuzes?
Dit soort informatie komt neem ik aan rechtstreeks uit de krochten van het EPSG en het speelt niet alleen in de situatie voor Nederland dus men wil het zo generiek mogelijk houden. Beste optie zou zijn om de teksten van de EPSG alvast aan te passen zodat de eerstvolgende proj update daar gebruik van maakt. Maar of het veel zal helpen… het blijft een lastig onderwerp.
Het zou wel fijn zijn als de meest recente ‘default’ wordt gezet maar voor zover ik weet kent de EPSG geen metadata over ‘meest recente’ (iemand anders die dat wel weet?).
Overigens zal het voor de gemiddelde gebruiker niet uitmaken wat die kiest, de nauwkeurigheid van de basisregistraties is denk ik lager dan deze verschuiving.
Dank je, dat is goed om te weten!
Kom ik op zoek naar iets anders weer eens op Qgis.nl, staat er al een tijdje een blog van @rduivenvoorde over dit probleem:
http://www.qgis.nl/2019/06/27/english-proj-select-datum-transformations-for-epsg28992/?lang=en
Nog niet volledig opgelost dus, maar weer wat extra achtergrond. En net als @emacgillavry hierboven al zei, ook @rduivenvoorde concludeert dat de laatste optie in het rijtje de beste is.
je kunt trouwens ook aanvinken ‘standaard maken’, dan heb je voortaan de vraag niet meer.
Ik ga in dit topic verder met een vergelijkbare vraag.
Ik probeer een kaartje te maken van het Cöln-Mindener spoorwegemplacement in Venlo van rond 1900.
Ik heb een .osm.pbf file met het emplacement er op.
Eerst pak ik in Qgis 3.12 met de Pdok-plugin de 8 cm-luchtfoto.
Daarna Layer > Add Layer > Add Vector Layer. Hier importeer ik mijn osm.pbf file.
Qgis vraagt vervolgens hoe ik wil transformeren:
Wat is beter? 1 of 2? Als het om een paar milimeter of centimeter gaat maakt het voor mijn kaart sowieso niet uit.
TL;DR: Het maakt voor jouw kaart sowieso niet uit.
Wat er aan de hand is is eigenlijk heel simpel. WGS84 is vastgezet aan “de aarde”, maar elk continent schuift daar op geheel eigen wijze overheen (plaattektoniek). Europa is dus niet “aardvast”. Om de paar jaar, als de verschuiving tussen Europa en de Aarde weer wat aan de grote kant wordt, wordt er een herberekening van de transformatie tussen die twee gepubliceerd. Dan schuift WGS84 dus weer een klein beetje op (gezien vanuit ons RD-stelsel).
Wanneer merk je dit? Bijvoorbeeld als je GPS metingen (en dan bedoel ik precieze GPS, dus RTK, niet met een wandel Garmin) hebt gedaan een jaar of wat geleden, en nu diezelfde punten weer inmeet. In het RD liggen ze op dezelfde plek, in WGS84 zijn ze verschoven. Wel een leuk idee om op die manier DHZ plaattektoniek te bepalen, leuke geonerdactiviteit).
OSM data houdt met dit alles volgens mij überhaupt geen rekening. Dat wordt “gewoon” allemaal opgeslagen in WGS84. En in het algemeen met een nauwkeurigheid die minder is dan dit soort effecten.
Aardig gedachte-experiment: als het emplacement daadwerkelijk in 1900 met GPS zou zijn gemeten (wat op zich redelijk onwaarschijnlijk is, gezien de wat latere totstandkoming van het GPS-systeem, en overigens ook die van het WGS84, waarin 84 niet staat voor 1848) en je zou die meting nu met de huidige transformatieparameters omzetten naar RD, dan kan er ondertussen wel eens een spoor door een gebouw geprojecteerd worden. Ik weet niet precies hoe hard WGS en RD schuiven (ik dacht ergens tussen 1-3 cm/jaar) maar dan kom je in ieder geval een keer boven de meter uit…
De TLDR klopt: Het effect van de verschillen tussen deze twee transformaties op coördinaten is in de orde van één centimer. In de rest van de reactie van Geogoeroe staan echter wat onjuistheden.
Dat je twee opties krijgt is een fout van EPSG.org de onderste van de twee transformaties met nummer (4) is de laatste update. Ze zijn bij EPSG alleen vergeten om de oude transformatie met nummer (3) als superseded te labelen zodat QGIS deze niet meer als optie geeft. Toevallig ben ik namens het Kadaster / NSGI net bezig om EPSG te vragen dit recht te zetten en om een nieuwe transformatie met nummer (5) op te nemen die consistent is met RDNAPTRANS™2018.
Europa beweegt in WGS 84 met 2,4 cm per jaar naar het noordwesten. RD is gekoppeld aan het Europese ETRS89 dat zo goed mogelijk meebeweegt met de Euraziatische tektonische plaat. Coördinaten in RD en ETRS89 veranderen daardoor nauwelijks. Omdat het onhandig is als de WGS 84-coördinaten en de transformatie wel iedere twee weken een millimeter veranderen is het advies van Geonovum en de NSGI om ETRS89 en WGS 84 voor de meeste toepassingen aan elkaar gelijk te stellen. De transformaties die QGIS voorstelt doen dit dan ook. De verschillen tussen de twee transformaties (3) en (4) zijn dus niet de verschuiving tussen ETRS89 en WGS 84, maar een kleine update van RDNAPTRANS™, de transformatie tussen ETRS89 en RD.
Dat Europa sinds 1 januari 1989 inmiddels 83,6 cm verplaatst is, wordt in QGIS dus verwaarloosd. GIS-gebruikers merken hier echter niets van omdat alle nauwkeurige datasets en software dit doen. GPS in je telefoon is niet zo nauwkeurig dat de fout storend is. Landmeetkundige precieze GNSS met RTK geeft coördinaten in het stelsel van de referentiestations, voor gecertificeerde RTK-netwerkdiensten is dit ETRS89. Dus ook daar worden WGS 84 en ETRS89 aan elkaar gelijk gesteld. Alleen gebruikers van een wereldwijde GNSS-correctiedienst (PPP) krijgen echte WGS 84-coördinaten (om precies te zijn ITRS-coördinaten) en merken het verschil op als ze hun ITRS-coördinaten niet netjes naar ETRS89 omrekenen.
Met het steeds nauwkeuriger worden van GPS en toegankelijker worden van wereldwijde correctiediensen zoals door de Galileo High-Accuracy Service (HAS), gaat het gelijkstellen van WGS 84 en ETRS89 op termijn problemen geven. Vanuit de NSGI denken we na over mogelijke oplossingsstrategieën en zijn we op zoek naar input van Nederlandse gebruikers om bij de verantwoordelijke instantie EUREF te bespreken, waarbij we ook naar de ontwikkelingen in Australie (GDA2020) en Noord-Amerika (NATRF2022) op dit vlak kijken.
Dank Jochem! Duidelijk een wat scherper geformuleerde uitleg dan mijn JBF methode ;-).
