Transformation pipelines paper

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Transformation pipelines paper

Kristian Evers-2

All,

 

Thomas Knudsen and I have written a paper about the Transformation Pipelines

framework that have been introduced to PROJ.4 recently. We have submitted it

to the FIG Working Week 2017 which is held in Helsinki next week. I’ll be

presenting the paper in the “Geodesy and Surveying Applications II” session on

Thursday June 1st. Please stop by and say hello if you are there.

 

The paper can be found at

http://www.fig.net/resources/proceedings/fig_proceedings/fig2017/papers/iss6b/ISS6B_evers_knudsen_9156.pdf

I have pasted in the abstract below.

 

In section 4, about transformation pipelines, we show case a few examples of

how transformation pipelines can be used. The examples all feature the new

and much improved implementation of the Helmert transform. Keeping the

lively discussion about the Helmert transform in March in mind I figure that the

paper will be of great interest to those involved in the discussion.

 

Happy reading,

Kristian

 

----------------------------------------------------------------------------------------------

TRANSFORMATION PIPELINES IN PROJ.4

 

For more than 2 decades, PROJ.4 has been the globally leading map projection

library for open source geospatial software. While focusing on mathematically

well-defined 2D projections from geographical to planar coordinates, PROJ.4

has nevertheless, since its introduction in the 1980s, provided limited

support for more general geodetic datum transformations, and has gradually

introduced a higher degree of support for 3D coordinate data and reference

systems.

 

The support has, however, been implemented over a long period of time, as

need became evident and opportunity was found, by a number of different

people, with different needs. Hence, the PROJ.4 3D support has not been the

result of neither deep geodetic, nor careful code architectural considerations.

This has resulted in a library that supports only a subset of commonly

occurring geodetic transformations. To be more specific: It supports any datum

shift that can be completed by a combination of two Helmert shifts and a

non-linear planar correction derived from interpolation in a correction grid.

While this is sufficient for most small scale mapping activities, it is not at

all sufficient for operational geodetic use, nor for many of the rapidly

emerging high accuracy geospatial applications in agriculture, construction and

transportation. To improve this situation, we have introduced a new framework

for implementation of geodetic transformations, which will appear in the next

release of the PROJ.4 library.

 

Before describing the details, let us first remark that most cases of geodetic

transformations can be expressed as a series of elementary operations, the

output of one operation being the input of the next. E.g. when going from UTM

zone 32, datum ED50, to UTM zone 32, datum ETRS89, one must, in the simplest

case, go through 5 steps:

 

1. Back-project the UTM coordinates to geographic coordinates

2. Convert the geographic coordinates to 3D cartesian geocentric coordinates

3. Apply a Helmert transformation from ED50 to ETRS89

4. Convert back from cartesian to geographic coordinates

5. Finally project the geographic coordinates to UTM zone 32 planar coordinates.

 

The homology between these steps and a Unix shell style pipeline is evident.

With this as its main architectural inspiration, the primary feature of our

implementation is a pipeline driver, that takes as its user supplied arguments,

a series of elementary operations, which it strings together in order to

implement the full transformation needed. Also, we have added a number of

elementary geodetic operations, including Helmert transformations, general

high order polynomial shifts and the Molodensky transformation. In anticipation

of upcoming support for full time-varying transformations, we also introduce a

4D spatiotemporal data type, and a programming interface (API) for handling this.

 

With these improvements in place, we assert that PROJ.4 is now well on its way

from being a mostly-map projection library, to becoming an

almost-generic-geodetic-transformation library.

 


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj