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.
(Continue reading)

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 
(Continue reading)

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

(Continue reading)

ALBERT Aurélien | 9 Jun 22:47 2015

pj_transform in multithread application


Is there any requirement on Proj4 context when using "pj_transform" in a multi-threaded application ?

Does the context of "srcdefn" and "destdefn" have to be the same ?

Proj mailing list
Proj <at>

Tom Kralidis | 28 May 18:37 2015

Overhaul of docs/website/wiki and call for help

All: given the wiki transition to GitHub, I think it's a good time to
dust off what's there and make things more clear.  Way forward:

1. Website

Core presence (links to docs, wiki, download, issue tracker, FAQ, etc.
This would be implemented in Markdown and leveraging GitHub pages,
which would make the web presence available at  If there is interest, we could
register (maybe OSGeo could cover?), or

This would either be managed a) in a gh-pages branch within or b) a dedicated repo like with gh-pages as the default
branch.  Note that this will also automagically update the website as
changes are made.  Pros/cons/suggestions/other options appreciated

2. Documentation:

This would live in the codebase in docs/ and be made available on, which would automatically generate and make
available the docs across multiple versions.  Content will be managed
by Sphinx/reStructuredText.

Table of contents:
- Introduction
- Installation
- Usage
- Testing
(Continue reading)

Finn, Michael | 22 May 17:43 2015

FYI -- Maps for Nepal

Proj mailing list
Proj <at>
Howard Butler | 22 May 15:47 2015

Github migration complete


Thanks to Thomas Bonfort, the proj.4 migration to github is complete. I would like to invite you to take a
look at

and if there are no major issues identified in the next few days, we will declare it complete and
decommission the Trac instance at OSGeo.

Proj mailing list
Proj <at>

Roger Bivand | 20 May 08:56 2015

ticket #274: proj_def.dat left out of 4.9.1 tarball


describes a puzzle we have seen with different behaviour wrt. errno -13. 
The resolution is to reinstate proj_def.dat in /nad (and installed 
PROJ_LIB). The Debian binary 4.9.1-1 was put on our testing servers a day 
or so ago, causing considerable upsets in user R code omitting +ellps=.

The omission is visible in proj-data:

compared to:

Is a 4.9.2 release likely? This is quite a serious problem in that the 
behaviour of PROJ.4 has changed at the user level from 4.8.0 to 4.9.1, 
unless the system admin only overwrote PROJ_LIB without deleting it and 



Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand <at>

Proj mailing list
Proj <at>