RDNAPTRANS 2018 implementatie in Java

Standaarden RDNAPTRANS
#1

Ik heb ooit voor de Basisregistratie Ondergrond (BRO) een java implementatie gemaakt voor de RD <-> ETRS89 en WGS84 <-> ETRS89 transformaties. Deze implementatie was gebaseerd op C++ source code van het kadaster. In eerste instantie had ik geprobeerd de transformatie met Geotools uit te voeren, maar dat had (toen in ieder geval) niet de gewenste nauwkeurigheid.

In dezelfde (j2ee) omgeving moet ik nu de RDNAPTRANS 2018 implementeren en ik vroeg me af hoe dat het eenvoudigst is te realiseren. Zijn er b.v. java libraries beschikbaar die de transformatie voldoende nauwkeurig uitvoeren?

Open source RDNAPTRANS2018 Java implementatie
#2

Bij mijn weten is RDNAPTRANS (het programma) niet strict noodzakelijk meer, maar kunnen deze transformaties met standaard proj: RD/NAP naar ETRS89 met NTv2 en VDatum. Dus met grid-transformaties, dus niet de standaard “7 parameter” met EPSG:28992. Kan niet zo snel de referenties vinden maar dit werk is ooit door Lennard Huisman van destijds Kadaster in gang gezet.

Door Bas Couwenberg is ook een Linux package beschikbaar: Debian -- Error

Zie ook Lennard’s Artikel pagina 18, Geo-Info.

2 likes
#3

Ook binnen het Kadaster zijn we nog aan het uitvogelen hoe we RD <-> ETRS89 transformaties het beste uit kunnen voeren vanuit Java.

Meeste PROJ projecten in Java hebben de ontwikkelingen van PROJ niet bij kunnen houden en zijn op PROJ 4 blijven steken. En daarmee kan je RDNAPTRANS2018 niet uitvoeren.

Meest belovende wat ik recent heb gezien is GitHub - OSGeo/PROJ-JNI: Java Native Interface for PROJ .

#4

Er is geen C+±voorbeeldcode voor RDNAPTRANS2018 meer, alleen PROJ-commando’s.

EPSG-code 28992 is in de EPSG-registry inmiddels aangepast conform RDNAPTRANS2018. Het duurt even voordat dit ook in alle van PROJ afgeleide projecten opgenomen wordt en de transformatie dus automatisch goed gaat. Tot die tijd kunnen de cct-commando’s van PROJ.6+ worden gebruikt (zie bijlage 3 van de documentatie RDNAPTRANS2018.pdf).

Voor projecten die op PROJ.4 zijn blijven steken werkt dat niet. De enige echte oplossing hiervoor is een nieuwere PROJ gaan gebruiken. Vanuit de NSGI raden we het gebruik van PROJ.4 ten zeerste af! (vanwege enkele bugs met fouten van enkele cm op zee). Desalniettemin kan RDNAPTRANS2018 wel met PROJ.4 (zie cs2cs-commando’s hieronder), want voorlopig negeert de validatieservice de bugs in PROJ.4 nog.

Groeten, Jochem Lesparre (Rijksdriehoeksmeting)
 

RDNAPTRANS™2018 implementation variant 2 with cs2cs of PROJ.4
From ETRS89 to RD and NAP
cs2cs +proj=lonlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs +to +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +wktext +nadgrids=rdtrans2018.gsb +geoidgrids=naptrans2018.gtx +no_defs -f %.4f input.txt > output.txt

From RD and NAP to ETRS89
cs2cs +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +wktext +nadgrids=rdtrans2018.gsb +geoidgrids=naptrans2018.gtx +no_defs +to +proj=lonlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs -f %.9f input.txt > output.txt

3 likes
#5

Bedankt voor de reacties. Ik kan/wil PROJ niet op een server installeren, weet dus niet hoe ik PROJ functionaliteit vanuit Java kan benutten. Moet nog beter naar Kortforsyningen/PROJ-JNI kijken. Wordt vervolgd

#6

Als je PROJ niet blijkt te kunnen gebruiken is er nog de optie om de formules uit de RDNAPTRANS2018.pdf zelf te programmeren. Een deel van die formules (bijv. de projectie) is onveranderd t.o.v. 2008 dus daar kan je oude code voor hergebruiken.

#7

Wat dat betreft: waarom niet naar Python overstappen? Met de Python-bindings voor GDAL, Proj en familie altijd toegang tot laatste versies. Ik heb de switch van Java naar Python bijna 10 jaar geleden gemaakt. Voor Open Source Geo is Python de beste keuze, server-side. Met Docker helemaal. Maar goed, soms zit je vast in infrastructuur…

1 like
#8

Bijzonder, ik ben net met exact hetzelfde bezig. Ik heb in een recent verleden verder gegaan met de proj4j “fork”. GitHub - locationtech/proj4j: Java port of the Proj.4 library for coordinate reprojection

#9

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 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