[Proj] Transformation Paper @ FIG WW Helsinki

Johnston, Gordon /C gordon.johnston at exxonmobil.com
Wed May 24 09:50:39 EST 2017

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: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of proj-request at lists.maptools.org
Sent: Wednesday, May 24, 2017 2:15 PM
To: proj at lists.maptools.org
Subject: Proj Digest, Vol 152, Issue 9

Send Proj mailing list submissions to
	proj at lists.maptools.org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
	proj-request at lists.maptools.org

You can reach the person managing the list at
	proj-owner at lists.maptools.org

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 <even.rouault at spatialys.com>
Subject: Re: [Proj] Submitting proj.4 to Google OSS Fuzz ?
To: proj at lists.maptools.org
Message-ID: <8265442.mUgpA38i5W at 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:even.rouault at spatialys.com]
> > Sendt: 23. maj 2017 16:09
> > Til: proj at lists.maptools.org
> > 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
> > > 
> > > Proj at lists.maptools.org<mailto:Proj at lists.maptools.org>
> > > 
> > > http://lists.maptools.org/mailman/listinfo/proj
> > 
> > --
> > 
> > Spatialys - Geospatial professional services
> > 
> > http://www.spatialys.com

Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170523/f4623379/attachment-0001.htm 


Message: 2
Date: Wed, 24 May 2017 13:14:42 +0000
From: Kristian Evers <kreve at sdfe.dk>
Subject: [Proj] Transformation pipelines paper
To: PROJ.4 and general Projections Discussions
	<proj at lists.maptools.org>
	<2E885BB293AF0448A0181138489E9A0E99FE09D9 at S000014.PROD.SITAD.DK>
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...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170524/11bd2eab/attachment.htm 


Proj mailing list
Proj at lists.maptools.org

End of Proj Digest, Vol 152, Issue 9

More information about the Proj mailing list