Nogmaals RDNAPTRANS2018 in Java

Standaarden RDNAPTRANS
#1

Na een jaar respijt ben ik nu weer bezig om voor de BRO RDNAPTRANS2018 te implementeren in een java omgeving.
Ik had verwacht dat het met de GeoTools library (25.2) wel zou lukken omdat, in ieder geval variant 2, door veel software ondersteunt wordt (volgens de documentatie van NSGI). Dat deze variant alleen binnen de begrenzing van het correctiegrid gebruikt kan worden is voor de BRO geen probleem.
Echter, de afwijkingen die ik bij RD → ETRS89 transformatie krijg zijn aanzienlijk groter dan die van onze eigen RDNAPTRANS2008 implementatie (de afwijking is het verschil met de door PROJ varinat 1 berekende waarde):
RD: (0117380.1200, 0575040.3400, 001.0000) ETRS: (04.824761812, 53.160752489) Deviation: (0.00000005, 0.00000055)
RD: (0247380.5600, 0604580.7800, 002.0000) ETRS: (06.776726564, 53.419482198) Deviation: (0.00000008, 0.00000014)
RD: (0155000.0000, 0463000.0000, 000.0000) ETRS: (05.387203581, 52.155172342) Deviation: (0.00000007, 0.00000055)
RD: (0155000.0000, 0463000.0000, 100.0000) ETRS: (05.387203581, 52.155172342) Deviation: (0.00000007, 0.00000055)
RD: (0016460.9100, 0377380.2300, 003.0000) ETRS: (03.397586265, 51.368607017) Deviation: (0.00000236, 0.00000012)
RD: (0182260.4500, 0311480.6700, 200.0000) ETRS: (05.773796990, 50.792585712) Deviation: (0.00000144, 0.00000083)
RD: (0064640.8900, 0440700.0101, 004.0000) ETRS: (04.072887861, 51.947394237) Deviation: (0.00000076, 0.00000036)
RD: (0400000.2300, 0100000.4500, 005.0000) ETRS: (08.723260354, 48.843030229) Deviation: (0.00000007, 0.00000000)
RD: (0100000.6700, 0300000.8900, 006.0000) ETRS: (04.608971888, 50.687420419) Deviation: (0.00000005, 0.00000004)
RD: (0100000.6700, 0350000.8900, 006.0000) ETRS: (04.601375791, 51.136825306) Deviation: (0.00000046, 0.00000014)
RD: (0079000.0100, 0500000.2300, 007.0000) ETRS: (04.268403950, 52.482440876) Deviation: (0.00000067, 0.00000008)
RD: (0050000.4500, 0335999.6700, 008.0000) ETRS: (03.891247897, 51.003976560) Deviation: (0.00000080, 0.00000045)

Weet iemand of dit ligt aan de EPSG definitie die GeoTools gebruikt, en zo ja, wat de EPSG WKT dan wel zou moeten zijn?

Open source RDNAPTRANS2018 Java implementatie
#2

Aan de coördinaten te zien is er voor de transformatie een verouderde benadering gebruikt zonder correctiegrid. Vermoedelijk is dat het gevolg van het gebruik van een RD-definitie uit een verouderde versie van de EPSG Registry. Dat een verouderde benadering gebruikt wordt valt eenvoudig zelf te controleren met de Validatieservice. Die geeft namelijk niet alleen de overeenkomst met de actuele RDNAPTRANS™, maar ook met verouderde versies en de benadering zonder correctiegrid.

Ik zit nog niet zo goed in de WKT-syntax om hier even snel een correcte WKT-string te kunnen geven. Je kan wel zelf een WKT-string genereren met QGIS op basis van een PROJ4-string. Zo’n automatisch gegenereerde WKT-string werkt, maar mist meta-data zoals de naam van het CRS, datum enz.

  • Start QGIS
  • Open het menu Extra
  • Kies de optie Aangepaste projecties…
  • Klik op de knop met de groene + (Nieuw CRS toevoegen)
  • Selecteer bij Indeling de optie Proj String (Oud – Niet aanbevolen)
  • Plak bij Parameters deze PROJ4-string:  +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +nadgrids=rdtrans2018.gsb +units=m +geoidgrids=naptrans2018.gtx +vunits=m +no_defs +type=crs
  • Selecteer bij Indeling de optie WKT (Aanbevolen)
  • Kopieer de WKT-string die bij Parameters staat

Ik hoop dat het hiermee lukt. Als dat zo is dan hoor ik het graag, want er is vaker vraag naar RDNAPTRANS™2018 in Java. Ook als het niet lukt hoor ik dat graag, want als er genoeg vraag is dan zou het de moeite waard kunnen zijn om gezamenlijk de Java-code van de oude RDNAPTRANS™2008 te laten updaten.

Groeten, Jochem Lesparre (Rijksdriehoeksmeting, NSGI)

3 likes
#3

Bedankt voor de info. Ga er a.s. maandag mee aan de slag

#4

Jochem,

De QGIS procedure die je beschrijft resulteert in een COMPOUNDCRS. Wanneer ik hier in Geotools een CoordinateReferenceSystem van probeer te maken (met ReferencingObjectFactory.createFromWKT() ) resulteert dit in de exception:
org.opengis.referencing.FactoryException: Type "COMPOUNDCRS" is unknow in this context

Weet jij of ik misschien een andere factory moet gebruiken?

#5

Als je de hoogte niet nodig hebt dan kan het ook zonder compound CRS met deze PROJ4-string:
+proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +nadgrids=rdtrans2018.gsb +units=m +no_defs +type=crs

Als je de hoogte wel nodig hebt dan zit je aan een compound CRS vast. Hoe dat werkt in Geotools weet ik niet.

#6

Geeft ook een foutmelding (org.opengis.referencing.FactoryException: Type "BOUNDCRS" is unknow in this context). Ga nog even verder zoeken

#7

Om voor de BRO per 1-10-2021 iets werkends te hebben gebruik ik nu PROJ8 via de command line. Niet helemaal wat je zou willen, maar het werkt

#8

Let op! Om de hoogte helemaal goed volgens RDNAPTRANS™2018 te berekenen, moet in PROJ4 de string die ik hierboven noem gebruikt worden. Vanaf PROJ6 moet voor een string in PROJ4-stijl echter een ander gridbestand voor de quasi-geoïde gebruikt worden:

+proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +nadgrids=rdtrans2018.gsb +units=m +geoidgrids=nlgeo2018.gtx +vunits=m +no_defs +type=crs