Custom RDNAPTRANS integration development
RDNAPTRANS™2018 is the official transformation between the Dutch Rijksdriehoeksmeting (RD) with heights relative to NAP and the European ETRS89, in which GNSS measurements are recorded. If you combine coordinates from different sources, you need to get that conversion right, otherwise cables, parcel boundaries or measurement points end up slightly out of line. Appfront builds the transformation into your software or data flow, following the official procedure and validated with the NSGI service.
What is an RDNAPTRANS integration?
In the Netherlands, position and height are usually expressed in the Rijksdriehoeksmeting (RD), with heights relative to NAP. GNSS receivers and European datasets work with ETRS89. RDNAPTRANS™ is the official transformation between the two, maintained by the Dutch Geodetic Infrastructure Partnership (NSGI). The 2018 version is easier to implement than its predecessor, and NSGI advises everyone to use it.
A transformation that is slightly off only becomes apparent when something goes wrong: a surveyed cable that sits a metre away from the drawing in the system, a height that does not match the benchmarks, or two datasets that just fail to meet. The cause is often an approximation built into a library chosen long ago, or an old version of the transformation.
We build the transformation in where your coordinates come in or go out: in your own software, in an API that other systems call, or in a data pipeline that converts batches. The parameters and formulas of RDNAPTRANS™ are freely available. We check the result with NSGI's validation service, so you know the output is correct.
Correct positioning
RD, NAP and ETRS89 line up.
Official procedure
RDNAPTRANS™2018.
Validated
With the NSGI service.
How we build your RDNAPTRANS integration
We start with your data: which coordinates come in, in which system, with or without height, and where they go. Then we look at how conversion is currently done and where the transformation is best built in. We implement RDNAPTRANS™2018 with the official parameters, for single points and for batches, and check the output with NSGI's validation service. After that, we keep the transformation up to date when NSGI releases a new version or your systems change.
Systems, heights and data flows.
Software, API or data pipeline.
With the official parameters.
Checked with NSGI, kept up to date.
What an RDNAPTRANS integration actually does
The components below appear in almost every RDNAPTRANS integration. Which ones you need depends on your data and where it comes from.
RD to ETRS89
And back.
NAP heights
Consistent with the benchmarks.
Batches
Large files converted.
API
For other systems.
Validation
Checked with NSGI.
Log
Which transformation, on which data.
Who we build an RDNAPTRANS integration for
The integration is intended for organisations that combine coordinates from different sources and want to know the conversion is correct.
Engineering firms
Design and surveying. Alignment matters.
Cables and pipelines
Underground position. Precision matters.
Government bodies and water boards
Geo-information. One system matters.
Software vendors
Coordinates in a product.
Technology and integrations
This page is about the transformation between coordinate systems. If you are looking for the data itself, see our page on the PDOK integration, for large-scale topography our page on the BGT integration, and for land parcels our page on the BRK integration. You can read about our approach on custom software development.
Why Appfront for your RDNAPTRANS integration?
A conversion that is slightly off costs an engineering firm or network operator rework, disputes over positioning, and sometimes damage. That is what we build against: correct positioning, the official procedure, and a validated result.
No offset
Datasets line up.
Official
As NSGI prescribes.
Demonstrable
Validated and logged.
Security and privacy in an RDNAPTRANS integration
The transformation processes coordinates and sometimes the data attached to them, such as cables, pipelines or land parcels. These are not always public. We only use what is necessary, access to the API is restricted, and every processing run is logged.
The transformation runs in a European data centre or in your own environment, with encrypted storage and connections. Where personal data is involved, we record the processing in a data processing agreement.
Frequently asked questions about an RDNAPTRANS integration
Questions organisations ask before they get started.
RDNAPTRANS™ is the official transformation between the Dutch triangulation system (RD) with heights relative to NAP and the European ETRS89. It is maintained by the Netherlands Geodetic Infrastructure partnership, NSGI. The current version is RDNAPTRANS™2018.
Sometimes you can, provided the library follows the official procedure correctly. Often it contains an approximation or an outdated version, and then the result is slightly off. We check the output with NSGI's validation service, so you know where you stand.
NSGI has a validation service that tests an implementation against RDNAPTRANS™2018. We run that test on delivery and after every change, and supply the results with it.
Yes. RDNAPTRANS™ also converts heights between ETRS89 and NAP. You need this when GNSS measurements must tie in with benchmarks or when designs use NAP heights.
Yes. Besides individual points via an API, we convert batches, such as survey files or exports from a GIS. The log records which transformation was applied to which file.
Then we update the transformation and validate it again. The log shows which version was used on which data, so old and new data can be told apart.
RDNAPTRANS™ is a protected name, intended for implementations that follow the official procedure. NSGI offers a validation service to test this, and we run it before you offer the transformation under that name. We will go through any further conditions with you in the first step.
That differs per organisation. Often GNSS measurements in ETRS89 come in from the field, and they need to end up in RD and NAP in a GIS, a drawing package or a registry. Sometimes it is the other way round, for a delivery to a European partner. The transformation sits at the point where that conversion takes place.
For engineering and surveying firms, for network operators and contractors in cables and pipelines, for government bodies and water boards working with geo-information, and for software vendors that process coordinates in the Netherlands. If you only occasionally convert a few points in an existing package that has already been validated, custom work is often not needed.
Coordinates that land in the same place everywhere?
Tell us which coordinates come in and where they need to go. We will show you where the transformation fits and how we validate it.