Naar aanleiding van Kleine afwijking bij RDNAPTRANS2018 in PHP, waarin een voorbeeld implementatie in SAS genoemd wordt en controle data voor tussenstappen van de transformatie zit, heb ik een paar weken geleden een Java implementatie van RDNAPTRANS2018 geschreven. De transformatieresultaten zijn ondertussen ook gevalideerd en goedgekeurd zodat de RDNAPTRANS naam gebruikt mag worden.
Er zitten twee “known issues” in die de transformatie binnen de grenzen van het correctiegrid niet beïnvloeden. Die zal ik nog een keer oplossen als ik weer wat tijd vrij kan maken.
Bedankt Robin! Voor gebruikers wil ik er wel nog even op wijzen dat het advies vanuit NSGI.nl is om PROJ.org te gebruiken en vooral energie te steken in het efficiënt aanroepen van de PROJ-library vanuit de gebruikte programmeertaal, in plaats van een implementatie van RDNAPTRANS™ naar iedere mogelijke programmeertaal te vertalen en door de NSGI te laten valideren. Voordeel van PROJ is niet alleen het onderhoud (bugfixes in de code en aanpassingen voor nieuwe RDNAPTRANS™-versies), maar ook dat met PROJ ook eenvoudig iedere andere coördinaattransformatie mogelijk is.
Voorbeelden van het gebruik van de C++/C-code van de PROJ-bibliotheek vanuit andere programmeertalen van zijn te vinden op deze pagina van de PROJ.org-website.
Ik snap ook wel dat RDNAPTRANS™2018 zelf programmeren makkelijker of leuker is dan beperkingen van PROJ-JNI fixen maar op de lange termijn lijkt me dat wel efficiënter.
Met PROJ6 is overigens niet zo veel mis, al zijn nieuwere PROJ-versies uiteraard beter.
PS: WGS84 (EPSG:4326) geeft geen specificatie van de realisatie van WGS84 en het is daardoor (en bij het ontbreken van een epoche) sowieso onmogelijk om daar naartoe te transformeren (afgezien van een nultransformatie gebruiken wat tranformeren overbodig maakt).
maar op de lange termijn lijkt me dat wel efficiënter.