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>

sisyphus1 | 19 May 10:46 2015

[MS Windows] PVALUE causes problems with mingw64 compilers


The problem arises when the mingw64 header winreg.h gets included.
We then get errors like:

C:/tmp64ng/c/include/projects.h:161:47: error: conflicting types for 
  typedef union { double  f; int  i; char *s; } PVALUE;
C:/tmp64ng/c/x86_64-w64-mingw32/include/winreg.h:75:3: note: previous 
declaration of 'PVALUE' was here

The fairly simple (though tedious) workaround is, prior to building proj, 
change each of the few occurrences of "PVALUE" in the proj source to a 
symbol that doesn't clash.
(I've been using "_P_VALUE", but perhaps something like "PROJVALUE" is a 
better choice .... I'm happy with *any* symbol that's not going to clash.)

Could the proj developers please rename "PVALUE" to something that doesn't 
clash ?
I really would like to not have to alter the proj source in future proj 

I did raise this matter a few years ago but, as nothing was ever done, I 
thought that maybe I should instead submit a bug report along with a patch.
However, AFAICT, to submit a bug report I need to go to and create a user id so that I can first 
log in.

Unfortunately the link to "this simple form" ( ) results in a "page can't 
be displayed error" for me.
There's a suggestion there that this could be a problem with my browser 
settings, though I don't usually have any trouble with secure connections.

Is there any other way I can create a user id ?


Proj mailing list
Proj <at>

Michel.Dastous | 13 Apr 17:31 2015

ACT Standard Grid (AGD66)



I’m currently trying to publish an Oracle dataset marked as SRID 82474 and cannot determine the proper proj4 init string corresponding to it.  I was able to extract the WKT definition from Oracle:


PROJCS["ACT Standard Grid (AGD66)", GEOGCS [ "Australian Geodetic 1966 ACT", DATUM ["AGD 66 ACT", SPHEROID ["Australian", 6378160, 298.25],-129.19,-41.21,130.73,-.25,-.37,-.33,-2.96], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 1.000086], PARAMETER ["Central_Meridian", 149.0092948333], PARAMETER ["False_Easting", 200000.000000], PARAMETER ["False_Northing", 4510193.4939], UNIT ["Meter", 1.000000000000]]


The best we have is:

+proj=tmerc +lon_0=149.0092948333 +k=1.000086 +x_0=200000 +y_0=4510193.4939 +ellps=aust_SA +towgs84=-129.19,-41.21,130.73,-.25,-.37,-.33,-2.96 +units=m +no_defs  <>


Unfortunately this produce a displacement of around 200 meters when  reprojected to Bing coordinate system.


Can anyone help?





Proj mailing list
Proj <at>
Daniel Buse | 13 Apr 16:12 2015

cs2cs differences between Windows and Linux


I noticed some small discrepancies in cs2cs between Windows and Linux.

Version for both is "Rel. 4.8.0, 6 March 2012"

Command used:
cs2cs -f "%.17g" +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=5500000 +y_0=0 
+ellps=bessel +datum=potsdam +units=m +no_defs +to +proj=utm +zone=33 
+ellps=WGS84 +datum=WGS84 +units=m +no_defs

Coordinates used:
5398786.5625 5672047.509765625

Result Windows:
398690.85663695924 5670224.1293941503

Result Linux:
398690.85663695924 5670224.1293941513

Difference is with 5670224.1293941503 in the second to last place.

Can anybody explain why this might be happening and what I could do 
about it?

Best regards,
Proj mailing list
Proj <at>

Andrea Aime | 6 Apr 19:25 2015

Why is cs2cs not compensating for the difference between ellispoid and sphere?

does anybody know why when going from WGS84 to the 1924 authalic sphere 
cs2cs is not compensating for the difference in flattening (and thus not changing a bit
the latitute)?

cs2cs -v +datum=WGS84 +proj=lonlat +to +proj=lonlat  +a=6371228 +b=6371228 +units=m +no_defs
# ---- From Coordinate System ----
#Lat/long (Geodetic)
# +datum=WGS84 +proj=lonlat +ellps=WGS84 +towgs84=0,0,0
# ---- To Coordinate System ----
#Lat/long (Geodetic)
# +proj=lonlat +a=6371228 +b=6371228 +units=m +no_defs
10 10
10dE 10dN 0.000

I was expecting this behavior only when adding +nadgrids= <at> nul (as reported in the
faq,, which is using a similar command line...).

What am I missing?


GeoServer Professional Services from the experts! Visit for more information.

Ing. Andrea Aime 
<at> geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Proj mailing list
Proj <at>
Mikael Rittri | 2 Apr 12:19 2015

Emulating Lambert Conic Conformal (2SP Michigan) in PROJ.4.

Almost a year ago, Even Rouault wrote

> I've followed the update process of the EPSG SRS database to latest
> v8.4, and just committed the updated files into libgeotiff, GDAL and
> PROJ trunk. Also submitted to PostGIS.

> From what I can see, among many changes and additions, 2 new projection 
> methods have been added:
> * 1051,Lambert Conic Conformal (2SP Michigan)
> --> looks very close to standard "Lambert Conic Conformal (2SP)", with
> the addition of a new parameter K, the ellipsoid scaling factor.
> * 1052,Colombia Urban
> I don't think any of those 2 new methods are currently handled by PROJ,
> so the new PCS based on those projection methods (3 Michigan SRS, and
> several dozains of Colombia PCS) will not be handled by GDAL nor PROJ.
(archived at

I have been thinking about how the new Lambert Michigan systems could
be handled in PROJ.4, and I have found three ways that do not require
new functionality in PROJ.4. 

A) One could drop the ellipsoid scaling factor K from the projection
definitions, if one also replaces the Clarke 1866 ellipsoid with a
user-defined ellipsoid that is K times larger than Clarke 1866. Using
a modified Clarke 1866 is how these systems have been described by
Michigan authorities,
Such a modified Clarke ought to work together with the usual +datum=NAD27
one would use for NAD27-based CRS definitions, since grid shift files do
not care about the ellipsoid size. 
     However, this method does not really reflect how the new Michigan CRS
instances are defined in EPSG, so it is kind of cheating. 

B) More EPSG-conformant would be to use +proj=lcc with two standard
parallels, lat_1 and lat_2, as well as a scale factor, k_0. The value
of the ellipsoid scaling factor K is simply assigned to k_0. PROJ.4 has
always supported combining two standard parallels with a scale factor
(for a suitable value of "always"). But one has to remember to convert
the False Easting from US survey feet to metres. 

Definitions with example conversions:

NAD27 / Michigan North, EPSG:6966
>proj +proj=lcc +ellps=clrk66 +lat_0=44.78333333333333 +lon_0=-87.0 +lat_1=45.4833333333333
+lat_2=47.08333333333333 +x_0=609601.2192 +y_0=0 +k_0=1.0000382 +units=us-ft +datum=NAD27 +no_defs

89W 48N
1510177.73      1179359.09

NAD27 / Michigan Central, EPSG:6201
>proj +proj=lcc +ellps=clrk66 +lat_0=43.31666666666667 +lon_0=-84.33333333333333
+lat_1=44.18333333333333 +lat_2=45.7 +x_0=609601.2192 +y_0=0 +k_0=1.0000382 +units=us-ft
+datum=NAD27 +no_defs

83d10'W 43d45'N
2308335.75      160210.48

NAD27 / Michigan South, EPSG:6202
>proj +proj=lcc +ellps=clrk66 +lat_0=41.5 +lon_0=-84.33333333333333 +lat_1=42.1
+lat_2=43.66666666666667 +x_0=609601.2192 +y_0=0 +k_0=1.0000382 +units=us-ft +datum=NAD27 +no_defs

86W 42N
1546955.83      186706.19

For Michigan Central, the example conversion above agrees with 
the test example in IOGP Guidance Note 7.2, section, For the two other systems,
I do not have test data, so there is always a risk that I made 
some blunder, but the basic design seems to work. 

C) For every Lambert Conic Conformal (2SP Michigan) projection
instance intended for a given ellipsoid, it is possible to
find an equivalent definition using the ordinary Lambert Conic
Conformal (2SP) method. The idea is that the ellipsoid scaling
factor K can be emulated by tweaking the two standard parallels.
While this technique is unnecessary in PROJ.4, it could be useful
in other software that does not support giving both scale factor
and two standard parallels to an LCC projection.

I have amused myself by trying this, and I found these values for
the tweaked standard parallels:

NAD27 / Michigan North:   45.6608876152 and 46.9073300238.
NAD27 / Michigan Central: 44.3736977068 and 45.5111167520.
NAD27 / Michigan South:   42.2824326153 and 43.4856140554. 

Other projection parameters should remain the same, except for
the dropped K. So we get the following ordinary 2SP definitions
(with the same example conversions as before):

NAD27 / Michigan North
>proj +proj=lcc +ellps=clrk66 +lat_0=44.78333333333333 +lon_0=-87.0 +lat_1=45.6608876152
+lat_2=46.9073300238 +x_0=609601.2192 +y_0=0 +units=us-ft +datum=NAD27 +no_defs

89W 48N
1510177.73      1179359.09

NAD27 / Michigan Central
>proj +proj=lcc +ellps=clrk66 +lat_0=43.31666666666667 +lon_0=-84.33333333333333
+lat_1=44.3736977068 +lat_2=45.5111167520 +x_0=609601.2192 +y_0=0 +units=us-ft +datum=NAD27 +no_defs

83d10'W 43d45'N
2308335.75      160210.48

NAD27 / Michigan South
>proj +proj=lcc +ellps=clrk66 +lat_0=41.5 +lon_0=-84.33333333333333 +lat_1=42.2824326153
+lat_2=43.4856140554 +x_0=609601.2192 +y_0=0 +units=us-ft +datum=NAD27 +no_defs

86W 42N
1546955.83      186706.19

Again, we get the correct result for Michigan Central. For the two other
systems, the results agree with those from method B), so if I have made
blunders, they are at least consistent blunders! 

Conclusions: The definitions of method B) or C) could be added to the
epsg file of PROJ.4. But I assume it would have to be done manually,
until libgeotiff can extract correct definitions of LCC (2SP Michigan)
instances directly from the EPSG database. (I believe the epsg file in
PROJ.4 is generated from the libgeotiff .csv files for EPSG.) I don't
know if libgeotiff can do that extraction yet. Nor do I know how
WKT for LCC (2SP Michigan) ought to look, nor whether GDAL/OGR
has any support for LCC (2SP Michigan) yet. 

One could hope that the EPSG committee would replace all LCC (2SP Michigan)
definitions by the equivalent ordinary LCC (2SP) definitions. But the EPSG
committee doesn't publish workarounds (unless it is an official workaround
defined by a national mapping agency), so I don't think they would like to
do that.

Best regards,

Mikael Rittri

Proj mailing list
Proj <at>

paul.chavent | 27 Mar 16:06 2015

Re: [proj.4] Fix reading failure of small GTX file. (#1)



Message du : 27/03/2015 14:34
De : "Howard Butler " <notifications <at>>
A : "OSGeo/proj.4" <proj.4 <at>>
Copie à : paul.chavent <at>
Sujet : Re: [proj.4] Fix reading failure of small GTX file. (#1)

 <at> polch Unfortunately, this repository isn't quite ready yet. It is part of a migration to github that is not
yet complete. Can you please make this patch at to ensure it is not lost?

Reply to this email directly or view it on GitHub:
Proj mailing list
Proj <at>
paul.chavent | 27 Mar 16:04 2015

Use the GTX null value for vertical shift exclusion.


Vertical grid shift values specified with GTX files are  rejected outside of the [-1000;1000] range. I
don't know if it is the  expected behavior since the GTX files allow any values excepted the null  value.

I've opened a ticket ( to address this issue. I've submitted a
patch that use the 88.88880 null value for rejecting bad values.

Perhaps a better fix would be to add a null_value (or range) field to the CTABLE and check against this value
(or range).


Proj mailing list
Proj <at>