FME Kennissessie Grip op RDNAPTRANS™

2 oktober 2020

RDNAPTRANS™ is de officiële en nauwkeurige transformatie tussen de coördinaten in het Nederlandse stelsel van de Rijksdriehoeksmeting (RD) met hoogte ten opzichte van het Normaal Amsterdams Peil (NAP) en het European Terrestrial Reference System 1989 (ETRS89). Deze officiële transformatie RDNAPTRANS™ is dusdanig aangepast, dat deze nu voor het eerst ook exact mogelijk is met GIS-software, waaronder FME.

Jochem Lesparre van Kadaster gaf hier meer uitleg over. Wat zijn bijvoorbeeld de gevolgen bij het niet toepassen van de officiële transformatie RDNAPTRANS™? En waar en waarvoor kunnen in Nederland RDNAP-coördinaten wel en niet gebruikt worden? Oscar van Vicrea vulde Jochem aan met praktische voorbeelden hoe de RDNAPTRANS™ in FME toegepast kan worden.

Heeft u deze kennissessie gemist? U kunt hier de opname bekijken.


VRAGEN EN ANTWOORDEN

Is het al bekend onder welk EPSG nummer RDNAPTRANS beschikbaar komt? 
RDNAPTRANS2018 staat sinds eind januari 2020 in EPSG, maar het duurt lang voor het ook in alle software die de EPSG-registry gebruikt zichtbaar is. De EPSG-codes van coördinaatsystemen veranderen niet bij een nieuwe transformatie. De codes voor RD- (28992) en RD-NAP-coördinaten (7415) zijn dus onveranderd (en je kan daaraan ook niet zien hoe er getransformeerd wordt! Met de validatieservice op nsgi.nl kan je controleren of RDNAPTRANS gebruikt wordt). De transformatiestappen hebben ook EPSG-codes, zoals de code voor de RD-projectie (19914) die niet veranderd is en het datum-correctiegrid (9282) dat wel veranderd is voor RDNAPTRANS2018. De meeste software laat deze EPSG-codes voor de transformatiestappen echter niet zien.

Is er een overzicht van alle leveranciers die RDNAPTRANS al geimplementeerd hebben?
We zijn van plan een dergelijk overzicht op nsgi.nl te publiceren tegen het eind van de overgangsperiode tussen RDNAPTRANS2008 en 2018. Op het moment is RDNAPTRANS vooral in landmeetkundige software geimplementeerd is en nog niet veel GIS-software.

RDNAPTRANS2018 biedt twee correctiegrids, die onderling ook verschillen opleveren, hoe zit dat?
Er zijn twee correctiegrids vanwege de twee varianten van RDNAPTRANS2018. Een variant voor open-source software PROJ waarmee ook buiten het grid getransformeerd kan worden en een variant die door de meeste GIS-pakketten ondersteund kan worden. Het verschil tussen deze twee varianten is ruim onder de 1 mm.

Welke tranformer zou Safe Software / Vicrea adviseren voor de RDNAPTRANS2018 transformatie?
Custom transformer RdNapTrans2018 (FME HUB)

Is RDNAPTRANS2018 transformer ook in oudere versies van FME beschikbaar? Waarom niet?
Nee, de nieuwe gridbestanden waar de nieuwe RDNAPTRANS transformer gebruik van maakt, worden pas sinds de 2020 versie uitgeleverd. Vanaf FME build 20181 wordt de tranformer ondersteunt (2020.0.0.1). In theorie zou je de gridbestanden kunnen inlezen in oudere versies van FME, maar dan kan niet gegarandeerd worden dat RDNAPTRANS tranformer volgens de officiele procedure de coördinaten transformeert (door versieverschillen van de transformers die gebruiks zijn binnen RDNAPTRANS).

Wat betekent dit bijvoorbeeld voor de BGT? Blijft de complete BGT gewoon de huidige coördinaten gebruiken? 
De coördinaten van GNSS-referentiestations en Kernnetpunten veranderen nauwelijks (minder dan 1 cm horizontaal), er is dus geen noodzaak tot het aanpassen van datasets zoals de BGT.

Landmeters maken gebruik van satellieten, dus meten in WGS1984. Niet in ETRS89. Waarom gebruiken we niet alleen WGS84 en RD?
Landmeters maken naast GNSS-satelieten ook gebruik van GNSS-referentiestations en krijgen daardoor coördinaten in het coördinatensysteem van het referentiestation en dat is weldegelijk ETRS89 en niet in WGS84. WGS84-coördinaten zijn ook helemaal niet praktisch in gebruik, omdat die 2,5 cm per jaar veranderen.

Stelling: eigenlijk moeten we afspreken zolang RDNAPTRANS2018 niet is geïmplementeerd in GIS moeten we geen coordinatentransformaties uitvoeren omdat er verschillen optreden.
Niet transformeren voorkomt inderdaad fouten. Als transformeren toch nodig is en het gebruikte GIS ondersteund RDNAPTRANS (nog) niet, dan zijn er twee opties. 1. In de meta-data opnemen hoe en dat er met een benadering getransformeerd is. 2. De data buiten het GIS-pakket conform RDNAPTRANS te transformeren met andere software zoals FME.

Dringt het Kadaster aan bij GIS-leveranciers om RDNAPTRANS2018 te implementeren?
Ja en we adviseren gebruikers van GIS-pakketen (met name overheidsinstanties) om bij aanschaf van GIS-software de ondersteuning van RDNAPTRANS in de eisen op te nemen.

Zit het al in Qgis? Of moet je bij deze systemen eerst transformeren met FME?
Nog niet, QGIS en ESRI zijn daar nog mee bezig. Het is wel al mogelijk RDNAPTRANS™2018 zelf als custom CRS te configureren in QGIS en ESRI-software. 

Zit het al in ESRI Software?
In de laatste presentatie van het nieuwe ArcGIS platform heeft ESRI onthult dat ze ook RDNAPTRANS ondersteunen als tranformatie. Buiten ESRI om kan je ook met FME zorgen dat datasets op de juiste manier van WGS84/ETRS89 naar RD worden omgezet.

Binnen de organisatie is afgesproken om de Molodensky-Badekas transformatie te gebruiken tussen ETRS en RDNew, werkt dit met RDNAPTRANS?
Nee, de Molodensky-Badekas-transformatie is een variatie op de Helmert-transformatie waarbij de rotatietermen niet direct worden toegepast op de ECEF-coördinaten, maar op carthesian coördinaten ten opzichte van een referentiepunt (meestal dicht bij het aardoppervlak en op het gebruiksgebied van de transformatie). Als px = py = pz = 0, komt dit overeen met een Helmert-transformatie met 7 parameters. Molodensky-Badekas is daarmee een (sneller) alternatief voor Helmert maar is daarmee nog steeds een benaderde methode die geen rekening houdt met de afwijkingen en correctie zoals die door RDNAPTRANS wel worden ondervangen, en door de fundamentele andere benadering niet te combineren met de RDNAPTRANS procedure van het correctiegrid.

Waarom is die 7 parameter transformatie niet voldoende? (met dx 593,032 dy 26 dz 478,741 rx 0,409394,….)
Naast dit soort parameters van de datumtransformatie is ook nog een correctiegrid en projectie nodig voor transformatie volgens RDNAPTRANS. De benodigde parameters en grids  staan in de RDNAPTRANS2018-documentatie die te downloaden is via nsgi.nl

Is het mogelijk om 7 point parameters te delen om in de custom mode in ArcGIS toe te passen?
Naast de 7 parameters van de datumtransformatie is ook nog een projectiemethode en een correctiegrid nodig voor transformatie volgens RDNAPTRANS™. De benodigde parameters en grids  staan in de RDNAPTRANS2018-documentatie die te downloaden is via nsgi.nl

Wel en geen RDNAPTRANS gebruiken leidt tot verschillen. De een is goed, de ander niet. Gevolg is een "nieuw soort fout". Dus ook verwarring. Hoe voorkomen we die situatie?
Dit is inderdaad een risico (dat eigenlijk al bestaat sinds landmeters in 2000 RDNAPTRANS zijn gaan gebruiken). Een manier om problemen te voorkomen is in de meta-data te documenteren of en hoe data getransformeerd is.

Wordt GTRF (gallileo) nog niet gebruikt?
Als de Galileo High-Accuracy Service beschikbaar komt, wordt dat misschien anders, maar tot nu toe wordt GTRF nog nauwelijks gebruikt. Consumenten-GNSS-ontvangers gebruiken Galileo altijd naast GPS en transformeren alles naar WGS84. Landmeetkundige RTK-GNSS geeft coordinaten in het coördinatensysteem van het referentiestation en dat is altijd in ETRS89. Wereldwijde GNSS-correctiediensten zoals PPP geven coordinaten in ITRS. 

MEER VRAGEN?
Staat uw vraag er niet tussen? Mail hem naar fme@vicrea.nl en wij komen er zo snel mogelijk op terug.

 

 

Deel dit artikel