Dutch coordinate system Rijksdriehoeksstelsel supported to the last sub-mm

Dutch coordinate system Rijksdriehoeksstelsel supported to the last sub-mm

By maxnl on

Coordinate systems have been a pain in the, ehm, neck, in our world. For some reason or another, things tend to go wrong. And if things go wrong, then the damage tends to be enormous! The impact is huge, the love for the topic is very limited… And I must say: I didn’t spontaneously fall in love myself with the topic of coordinate systems. I just happen to have been supporting people for the last 20 years with problems regarding coordinate systems, and Rijksdriehoeksstelsel in particular. That caused me to have an opinion, to say the least. And meanwhile, I also found out a thing or two.

Precision at remote sensing, GIS and surveying

Within GIS, the remote sensing and photogrammetry worlds, coordinate systems have always been the last thing to look at. Sure: things appear at a certain spot, obviously. But oh well, as long as it kinda fits –let’s say, within 2-10 meters accuracy- then it’s already ok. So different were things in the surveying and geodetic world. There you talk about precision, idealization, and reliability! Where hard topography is generally expressed in centimeters, and where ground control points are published with a millimeter accuracy. That’s a whole different ballgame! The surveying world has –in general- superb solutions for coordinate systems for many years now.

But these worlds are moving into one another more and more. That has been going on for a few years now, and it will continue. Aerial photographs deliver pixels, and the pixel size is more often than not 7.5 or 5 centimeters. And we collect GIS databases based on that material. We apply remote sensing techniques for change detection and other stuff. We capture in stereo based on these photos, and that is not a lot more than just another surveying technique next to the other surveying techniques. We expect geometry from stereo capturing, which does not go bleak against other measuring techniques. We assign a value to the position of a pixel, this tile of 7.5×7.5 centimeters in the terrain. But that implies, that more and more the topics of precision, idealization and reliability have crawled into the domain of GIS/remote sensing/photogrammetry. We need to talk about these things! And that implies that software vendors, like us, progressively need to get our act together regarding these geometric fundaments.

And let that be the good news: we aren’t doing that bad! We have been working for a couple of years now, to get this time and time again at a better level. If you wish to rely on the position of a pixel, then you need to make sure coordinates aren’t rounded up to the next 25 cm for instance. Or that image compression creates a minor shift in the data. Or that everything shifts by half a pixel, because we got some confusion if the center of the upper left pixel is the origin, or the top left corner of that pixel. These kind of things have been solved years ago. But one thing was still on the to-do list, and I really badly wanted to get rid of that. And that was accurate support of the Rijksdriehoeksstelsel, and of the Normaal Amsterdams Peil vertical datum…

RD support?

Real RD support…. That’s a rare thing to see…. OK, you see it in the geodetic world. But in the GIS world? I don’t know all possible GIS applications, so I cannot say for sure. But I can say for sure that I do not know any GIS application, commercial or open source, that support Rijksdriehoeksstelsel down to the last millimeter. OK: every application has an RD option in the software. But what is normally meant by that is ‘Pseudo RD’ under the hood. And there is a difference between Pseudo RD and RD. This difference is not constant, it changes throughout The Netherlands. But the difference can go up to 25 cm. In the old days, that was never an issue. But alas… if you assign a value to the position of a pixel… Or if you see a positional precision of 30cm in the State BGT registration definition to abide to the standards…. Then suddenly these things become extremely important!

And in fact… Are we that INSPIRE compliant, if we cannot even convert to the European ETRS89 system at all? Think about it….

So what’s the deal?

There always has been a method to convert RD all the way, but two serious issues were attached to it. One was, that the Dutch calculation method divided from how things were done in the rest of the world, in serious ways. The method was documented, and so it could be programmed, but it was deviating seriously from how the rest of the world dealt with this. And that implied that software vendors not just dealing with the Dutch market, had to deal with a ‘one-off’. They had serious problems. The effect was bad to maintain source code, not abiding to general standards. This is a true nightmare for software companies.

And there was a second problem: the transformation was based on pretty complex Overhauser Splines. And these Splines are seriously calculation-intensive. The ‘CPU-cost’ of these calculations is big. And that is quite ok if you are just transforming one coordinate (and in the surveying world, that is mostly the case), but if you have a few thousands or millions or coordinates, and you need to do serious calculations for each coordinate then you can imagine what that does to your hefty webservice. It is going to be as slow as the slow train of 1910…


Pragmatic solution

Luckily there is a solution. We had some good discussions with the Dutch Cadastre, to see what we can achieve if we follow the official road, but with a few shortcuts. And we seem to have done a good job. It is still a pragmatic approach, with a few limitations because of pragmatism. But the end result is, that at ground level, plus or minus, say, 100 meters, we can transform coordinates down to a fraction of millimeter accuracy. And that, while abiding to the de-facto standards in the GIS industry. And that in realtime, maintaining performance. Now that is not bad! With accuracies down to fractions of millimeters, we are good to go for the next few years I would say!

In all Hexagon Geospatial software, we are rolling out this implementation, with each and every service pack and update. Stereo Analyst for ArcGIS 11.7 and ERDAS IMAGINE 2014.1 were the first ones, and the rest follows. And you don’t need to trust me on that: you can simply check for yourself in ERDAS IMAGINE in the Coordinate Calculator (at the Manage Data Tab). Get some sample coordinates from the Dutch Kadaster Website and you will see: spot on!

So, another task from the to-do list. Time for the next!