Tijdsafhankelijk transformatie van EPSG:4326 naar EPSG:4937 (ETRS89)

Standaarden RDNAPTRANS
#1

Hoi,

Ik wil graag mijn lat/lon/h (EPSG:4326, WGS84) coördinaten transformeren naar EPSG:4937 (en daarna naar EPSG:7415 met RDNAPTRANS2018). De eerste stap kan met een nultransformatie, maar eigenlijk zou ik dit graag preciezer willen doen door de tijdsafhankelijkheid mee te nemen. De EPSG:4326 coördinaten komen immers uit 2018. Ik heb daarvoor de handleiding van Geostandaarden erbij gepakt (Handreiking Gebruik coördinaatreferentiesystemen bij uitwisseling en visualisatie van geo-informatie) en de laatste versie (v9.3.0) van PROJ geïnstalleerd.
De naïeve aanpak met proj (eigenlijk pyproj die ook PROJ v9.3.0 gebruikt) was met de EPSG codes voor transformatie, namelijk:

transformer = pyproj.transformer.Transformer.from_crs(“EPSG:4326”, “EPSG:4937”)

maar hiermee komen dezelfde coördinaten eruit.

Aan de hand van de handleiding begrijp ik het als volgt

De lat/lon/h → ITRF2018 → ITRF1989 → ETRS89 waarna ik RDNAPTRANS kan gebruiken om naar EPSG:7415 te gaan.

Begrijp ik dat zo goed? En zo ja, wat is de standaardaanpak voor de implementatie van mijn geografische coördinaten naar ETRS89?

#2

Het hangt nogal van je toepassing af of überhaupt het verstandig is om tijdsafhankelijk te transformeren.

Voor de meeste toepassingen is het advies om een nultransformatie te gebruiken. Nauwkeurige geografische coördinaten (lat., lon., h) zijn in Europa namelijk bijna altijd in ETRS89 ook al hangt er het label EPSG:4326 aan, waardoor een nultransformatie dus beter is. Coördinaten in WGS 84 zijn bijna altijd onnauwkeurig waardoor tijdsafhankelijk transformeren niet zo veel zin heeft.

Wat is de bron van je coördinaten in WGS 84?

#3

Bedankt voor je antwoord! Ik snap wat je schrijft. De coördinaten komen van radar data.

#4

Ah, dat verduidelijkt al het een en ander, maar ik heb nog meer vragen:

  • Gaat het om radardata van het aardoppervlak ingewonnen met een satelliet zoals Sentinel of zo, en niet om data ingewonnen met een vliegtuig? Voor satellietdata is het inderdaad waarschijnlijk in een wereldwijd CRS, in het geval van airborne data zou het ook in ETRS89 kunnen zijn.

  • Wat is de horizontale resolutie (pixel size op de grond) van de data? Als de resolutie slechter dan een meter is, dan lijkt tijdsafhankelijk transformeren niet zo veel zin te hebben.

  • Is er bekend welke realisatie van WGS 84 gebruikt wordt voor de satellietdata? Is dat bijvoorbeeld de huidige realisatie van GPS: WGS 84 G2139 / ITRF2014, of is het een oudere realisatie, of juist een nieuwere (ITRF2020)?

  • Weet je het epoche van de data?

#5

Ja het is onder andere een afgeleid product (EGMS) van Sentinel-1. In het geval van Sentinel-1 is de resolutie zelf de beperkende factor. Helaas staat er in de beschrijving enkel het volgende over de lat/lon/h in de ATBD:

…non-projected (geographic) coordinates using the WGS84 datum…

De data heeft een geschatte nauwkeurigheid van < 8 m als het om de (horizontale) positie gaat. Stapel ik geen fouten als ik dan ook nog eens de tijdsafhankelijkheid achterwege laat?

De data is een samentrekking van data van 2015 t/m 2020.

Sorry dat ik je niet meer informatie kan geven, ik hoop dat dit het iets verduidelijkt.

#6

Het kan best dat EGMS in werkelijkheid niet in WGS 84, maar in ETRS89 is en dat een nultransformatie dus beter is. Ik weet niet hoe die data gegeorefereerd wordt. Het verschil tussen WGS 84 en ETRS89 was tussen 2015 en 2020 ca. 0,6 tot 0,7 m. Bij de gespecificeerde nauwkeurigheid van 8 meter valt dat in het niet. Inmiddels is het verschil in 2024 opgelopen tot 0,9 meter, maar zelfs dat lijkt me voor deze toepassing niet significant.

Mocht je toch nieuwsgierig blijven naar de tijdsafhankelijke transformatie: We publiceren binnenkort een nieuwe Transformatie-API op NSGI.nl die de tijdsafhankelijke transformatie ondersteund.

1 like
#7

Ja, ik ben nog steeds wel nieuwsgierig eigenlijk en wat er daarbij achter de schermen gebeurt. Ik hou het in de gaten! Bedankt.