Transformation Paper @ FIG WW Helsinki

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

Transformation Paper @ FIG WW Helsinki

Kristian, I shall be there all week although my focus is on the Commission 4 activities so there may be some conflict in the schedules.

However I know there is a plan for the Comm 4/5/6 social dinner and this might be a good time to make contact if not before that.

Safe travels to Helsinki
Gordon Johnston

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Wednesday, May 24, 2017 2:15 PM
To: [hidden email]
Subject: Proj Digest, Vol 152, Issue 9

Send Proj mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Proj digest..."

Today's Topics:

   1. Re: Submitting proj.4 to Google OSS Fuzz ? (Even Rouault)
   2. Transformation pipelines paper (Kristian Evers)


Message: 1
Date: Tue, 23 May 2017 19:51:01 +0200
From: Even Rouault <[hidden email]>
Subject: Re: [Proj] Submitting proj.4 to Google OSS Fuzz ?
To: [hidden email]
Message-ID: <8265442.mUgpA38i5W@even-i700>
Content-Type: text/plain; charset="us-ascii"

On mardi 23 mai 2017 17:23:32 CEST Even Rouault wrote:

> On mardi 23 mai 2017 14:24:11 CEST Kristian Evers wrote:
> > > That's the most convenient. You can run OSS-Fuzz locally as instructed
> > > in
> > > proj.4 tests/fuzzers/README.TXT (but you need Linux and Docker for
> > > that),
> > > and there you could point the oss-fuzz/projects/proj4/Dockerfile to a
> > > branch of yours (that's how I tested it before submitting it)
> >
> > Yeah, I figured. It would be super cool if you could trigger OSS-Fuzz
> > targeting a specific bug via a pull request. Maybe that will be possible
> > in
> > the future...
> >
> > Thanks for the help. I will try to run OSS-Fuzz locally to confirm fixes
> > before I commit them to master.
> Well, in that case that means you're running Linux, so build proj.4 with
> CFLAGS="- fsanitize=undefined,address" and running the standalone
> standard_fuzzer should be sufficient (and much faster)

Note: make sure the proj lib is built with a PROJ_LIB define that points to something valid, or
define PROJ_LIB to point to the in-source nad directory when running standard_fuzzer as it
can make a difference (in particular since the fuzzer might generate strings without +no_defs
and ellipsoid values, and in that case they are valid due to nad/proj_def.dat containing
ellps=WGS84. Whereas if you run standard_fuzzer with no valid PROJ_LIB you'll get an early
exit due to proj_init() having failed. I've updated the example in test/fuzzers/README.TXT
with that)

> > Kristian
> >
> > Fra: Even Rouault [mailto:[hidden email]]
> > Sendt: 23. maj 2017 16:09
> > Til: [hidden email]
> > Cc: Kristian Evers
> > Emne: Re: [Proj] Submitting proj.4 to Google OSS Fuzz ?
> >
> > On mardi 23 mai 2017 13:41:50 CEST Kristian Evers wrote:
> > > Kurt, Even,
> > >
> > >
> > >
> > > Thanks for your suggestions. Very helpful. I do have access to a Linux
> > >
> > > server and if necessary I can work on that. It is just slightly
> > >
> > > inconvenient when on the move etc.
> > >
> > >
> > >
> > >
> > >
> > > I must say, it is a very impressive piece software google has created!
> > >
> > > Although it is a bit hard to grasp the finer details :-) I think I can
> > > fix
> > >
> > > some of the discovered issues just from looking at the report, as you
> > >
> > > suggest, Even.
> > >
> > >
> > >
> > >
> > >
> > > The only way to triggers OSS-Fuzz to test code is to commit on the
> > >
> > > master-branch, correct?
> >
> > That's the most convenient. You can run OSS-Fuzz locally as instructed in
> > proj.4 tests/fuzzers/README.TXT (but you need Linux and Docker for that),
> > and there you could point the oss-fuzz/projects/proj4/Dockerfile to a
> > branch of yours (that's how I tested it before submitting it)
> >
> > > /Kristian
> > >
> > > _______________________________________________
> > >
> > > Proj mailing list
> > >
> > > [hidden email]<mailto:[hidden email]>
> > >
> > >
> >
> > --
> >
> > Spatialys - Geospatial professional services
> >
> >

Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...


Message: 2
Date: Wed, 24 May 2017 13:14:42 +0000
From: Kristian Evers <[hidden email]>
Subject: [Proj] Transformation pipelines paper
To: PROJ.4 and general Projections Discussions
        <[hidden email]>
        <[hidden email]>
Content-Type: text/plain; charset="us-ascii"


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


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

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.

-------------- next part --------------
An HTML attachment was scrubbed...


Proj mailing list
[hidden email]

End of Proj Digest, Vol 152, Issue 9

Proj mailing list
[hidden email]