Rob Parsons | 10 Jul 05:48 2015

Verifying cs2cs arguments


Is there a way to verify the arguments that will be passed to cs2cs.exe before cs2cs.exe is used?

cs2cs.exe is used from inside a python script. Is there a related tool that can verify the arguments that will be passed to cs2cs.exe?

Rob Parsons
Raleigh NC

Proj mailing list
Proj <at>
Even Rouault | 7 Jul 18:53 2015

Next major proj version: 4.10 ?


What will be the number of the next major proj version : 4.10 ?

I'm wondering so as to be able to close a ticket and set the appropriate 
milestone (4.10 doesn't exist currently in github tickets)

Currently, we have:

#define PJ_VERSION 491

I guess that with 4.10 that should become :

/* MAJOR * 10000 + MINOR * 100 + MICRO */
#define PJ_VERSION 41000



Spatialys - Geospatial professional services
Proj mailing list
Proj <at>

OHTSUKA Ko-hei | 6 Jul 02:28 2015

Can I make definitions of bird-eye-view maps coordinates using proj4 and proj4text?


I used proj.4 for transforms of many maps projections, but those projections are ordinary maps'
projection, like stereographic, orthographic, gnomonic .. and so on.

But these days, I have a question if proj.4 can use for bird-eye-view maps projection.
Are there any options for making definition of bird-eye-view maps in proj4text?

Proj mailing list
Proj <at>
Even Rouault | 4 Jul 21:13 2015

AppVeyor (Windows CI) setup + Windows CMake question


Similarly to Linux Travis-CI builds, I've also added the configuration for the 
AppVeyor hosted CI service for Windows builds 

The following configurations are tested (for pushes and pull requests) :
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 10; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 10; Platform: x86
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 11; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 11; Platform: x86
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 12; Platform: x64
Environment: BUILD_TYPE=cmake, VS_VERSION=Visual Studio 12; Platform: x86
Environment: BUILD_TYPE=nmake; Platform: x64
Environment: BUILD_TYPE=nmake; Platform: x86

This only runs the build as I don't think there's a test target for Windows ?

Results available at:

Travis and Appveyor badges displayed on:

I've had a hard time with Windows cmake builds. I had to add  "-
DCMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE=../bin" on the cmake line, otherwise I 
got errors during the build with "..\bin\nad2bin.exe" not being found when 
processing """
  Building Custom Rule c:/....../proj.4/nad/CMakeLists.txt
Is it expected?
Without that, the binaries are installed in bin\Release



Spatialys - Geospatial professional services
Proj mailing list
Proj <at>

Darren Govoni | 3 Jul 13:35 2015

Custom grid system?

   I'd like to create custom grid reference systems with proj4 
(specifically pyproj).
So I want to a method to create all the individual grids and have them 
in a matrix or something.

Are there examples of this? I couldn't find any.

Proj mailing list
Proj <at>

José Luis García Pallero | 2 Jul 16:25 2015

PROJ.4 and OpenMP


Since version 4.8.0, PROJ.4 has some thread safety facilities
( and also the source
code contains an example program in which Posix Threads are used. But
I'm a bit confused about how to use this thread safety with OpenMP.
Could someone, please, upload a code example of using PROJ with
OpenMP? Such example could be also added to the distributed source



José Luis García Pallero
jgpallero <at>
/ / \
Use Debian GNU/Linux and enjoy!
Proj mailing list
Proj <at>
Even Rouault | 23 Jun 17:29 2015

Experiment to speed up proj.4 by 2 or more


I've done an experiment to use Intel SIMD intrinsics 
(, and I think they could be beneficial for 
proj, when called to transform several coordinates at a time.

I've used the SSE2 instruction set (128 bit registers, so 2 doubles at a 
time), and I managed to speed up the inverse Transverse Mercator ellipsoidal 
transformation (ie. from projected to geodetic) by a factor of ~ 2 (excluding 
potential datum transformations)

One key for performance was to find an efficient way of computing the usual 
transcendental functions (ie. sin, cos, tan and their inverse, exp, ln, 
etc...) with SIMD registers, since they are not included in the instruction 
set. Otherwise you have to collect each component of the SIMD register, 
evaluate it with the x87 coprocessor, and reassemble the SIMD register from 
the computed components, which kills all the other performance gains. The 
SLEEF library ( has such routines, is in 
the public domain and works rather well (with gcc/clang, although it has some 
rough edges when trying with MSVC, but nothing that cannot be overcome)

I've encapsulated the use of SSE2 intrinsics in a C++ class with overloading 
of arithmetics operators, so the resulting code looks pretty much similar to 
the original C code, which is great for readability (although the original C 
code isn't always very readable ;-)), and confidence that it doesn't introduce 
errors. Conditionnal branches are not so great for SIMD performance, but there 
are tricks to rewrite some of them with a ternary-like operator.

SLEEF also supports the AVX & AVX2+FMA instruction sets (256 bit registers), 
which could also lead to a further ~ x2 gain over SSE2.

So I was wondering if there was :

1) interest of the project in pursuing into that approach (which involves  
introducing C++ in the code base, as an implementation detail, the interface 
being unchanged). We could imagine to have the same source files compiled 
several times with different register sizes, with runtime selection of the 
appropriate variant (note: SSE2 is guaranteed to be available on all x86_64 
compatible processors. AVX/AVX2 is for more recent CPUs).

2) ... and sponsors interested in making that happen.

Finally, the proof of concept: 
* regular code (runs in ~30s on Core i5 750  <at>  2.67GHz  ):
* SSE2 code (~14s):

Best regards,



Spatialys - Geospatial professional services
Proj mailing list
Proj <at>

Tom Kralidis | 21 Jun 14:34 2015

first pass website complete

Hi all: update on original proposal [1]: first pass is at
(see gh-pages branch [2]).  Comments/suggestions/improvements welcome.

I'll start working on the docs setup (help wanted!) once folks are
comfortable with the new web presence.



Proj mailing list
Proj <at>

Even Rouault | 21 Jun 01:35 2015

Travis-CI + Coveralls setup


I've setup Travis-CI to run builds on commit pushes (and pull requests) to

The script does the 
following combinations:
- gcc / clang
- cmake build / autoconf build
- with / without

So 8 combinations in less than 5 minutes :-)

It does also "make check", but only for the autoconf setup since the target 
doesn't appear to be implemented for cmake.

I've also included coverage report of the test suite with the Coveralls 
service. And that confirms my intuition that there would be place for 
improvements: 28% line coverage

The .travis.yml conf could certainly be improved, but that's a start.

Travis results at
Coverage results at

Similarly to what I've done for GDAL, I've also used a trick to makes builds 
with MacOSX and MinGW. I've a regular cron job (scheduled every 15 minutes 
currently) that merges proj.4 master into my fork, in 2 dedicated branches, and, and pushes the result of 
the merge to github, so that Travis builds happen (that can break in case 
.travis.yml in master is changed, in which case manual merge might be 
required). The mingw target doesn't run the tests, "make check" being not 
ready for that.

Results for MacOSX and MinGW at

Of course, those 2 last targets are only triggered after pushes to master, not 
pull requests.



Spatialys - Geospatial professional services
Proj mailing list
Proj <at>

snitch | 20 Jun 15:19 2015

Proj4 String and Well Known Text Keyword mapping


I guess this is the right place to ask. 

Does anyone know about any resource that has a mapping between Proj4 and WKT

Thank you

View this message in context:
Sent from the PROJ.4 mailing list archive at
Proj mailing list
Proj <at>

Lourens Veen | 10 Jun 15:23 2015

Lambert Azimuthal Equal Area scale

Dear all,

I have a GeoTIFF file that uses a custom Lambert azimuthal equal area 
projection with proj.4 string

+proj=laea +lat_0=15 +lon_0=-80 +x_0=0 +y_0=0 +datum=WGS84 +units=m 
+no_defs +ellps=WGS84 +towgs84=0,0,0

The pixels are sized 10000x10000m, and so in the projected system have a 
surface area of 100km^2.

I am now using the invproj tool (from proj 4.8.0) to un-project four 
corners of a pixel to WGS84 coordinates:

$ invproj +proj=laea +lat_0=15 +lon_0=-80 +x_0=0 +y_0=0 +datum=WGS84 
+units=m +no_defs +ellps=WGS84 +towgs84=0,0,0 -S
-4600000 6190000
164d11'36.762"W	54d52'47.599"N	<1.25548 0.798216 1 26.0103 1.25729 0.795362>
-4600000 6180000
164d1'53.146"W	54d50'37.423"N	<1.25483 0.798516 1 25.943 1.25653 0.795842>
-4590000 6180000
163d55'19.442"W	54d54'20.055"N	<1.25437 0.798719 1 25.8934 1.25597 0.796196>
-4590000 6190000
164d5'3.703"W	54d56'30.694"N	<1.25502 0.798414 1 25.9607 1.25673 0.795716>

Next, I'm calculating the distance-along-the-ellipsoid between these 
points using invgeod:

$ invgeod +ellps=WGS84 +units=m

164d11'36.762"W	54d52'47.599"N 164d1'53.146"W	54d50'37.423"N
12d6'11.586"	-167d53'12.778"	18457.232
164d1'53.146"W	54d50'37.423"N 163d55'19.442"W	54d54'20.055"N
-28d30'57.832"	151d28'0.716"	13856.109
163d55'19.442"W	54d54'20.055"N 164d5'3.703"W	54d56'30.694"N
-167d51'52.105"	12d7'31.893"	18479.179
164d1'53.146"W	54d50'37.423"N 164d5'3.703"W	54d56'30.694"N
-119d16'41.52"	60d41'41.449"	12043.634
164d5'3.703"W	54d56'30.694"N 164d11'36.762"W	54d52'47.599"N
151d21'28.799"	-28d37'30.228"	13847.743
164d1'53.146"W	54d50'37.423"N 164d5'3.703"W	54d56'30.694"N
-119d16'41.52"	60d41'41.449"	12043.634
163d55'19.442"W	54d54'20.055"N 164d11'36.762"W	54d52'47.599"N
174d47'56.288"	-5d11'38.318"	30345.538

The LAEA projection doesn't preserve angles or distances, so it's no 
surprise that my square pixel is warped. From the above lengths of the 
sides and diagonals, it's approximately a parallelogram, with top and 
bottom sides of 13.8 km, left and right sides 18.4 km, and the top-right 
corner almost directly above the bottom-left corner (i.e. it's leaning 
left about 45 degrees).

What is surprising, at least to me, is that this parallelogram has a 
surface area of about 165 km^2! Of course in reality the parallelogram 
is embedded in the ellipsoid, and therefore not flat, but surely over a 
distance of 30 km the curvature can't be enough to give such a 
deviation? Besides, that should result in a surface area less than the 
actual 100 km^2 I think.

Is there something fundamentally wrong with this calculation? Am I using 
invproj and invgeod incorrectly? What am I missing?

Thanks in advance,


Proj mailing list
Proj <at>