Even Rouault | 14 May 12:56 2014

Update of EPSG database to v8.4


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.

Regarding GDAL, I've improved the add_esri_column.py script (see 
http://trac.osgeo.org/geotiff/changeset/2446), so that we have more ESRI DATUM 
names. That should make morphing from/to ESRI .prj files a bit better.

Regarding PROJ.4 'espg' and PostGIS spatial_ref_sys.sql files, I've also added 
the list of SRS that are GEOCCS (GeoCentric) and COMPD_CS (Compound Horizontal 
+ Vertical).

Please let me know if you see issues.

(Continue reading)

Irwin Scollar | 10 May 17:29 2014

Hough Ellipse

I am working on a program for geometric 
correction of the Corona KH4, 4A and 4B satellite 
imagery which was declassified in 1995 and is now 
available from the web site of the USGS & EROS data center.


The panoramic image strips cover vast areas of 
roughly 3000 sq. km at 2 to 4 meters per pixel, 
depending on the satellite height.  USGS supplies 
a metadata file with the corner and center points 
of each image given in latitude and longitudes.


Image Coverage Models for Declassified Corona, 
Argon and Lanyard Satellite Photography, A 
Techical Expanation by J. Michael Sélander, in:

CORONA: Between the Sun & the Earth: The First 
NRO Reconnaissance Eye in Space. Robert McDonald, 
ed. Bethesda, Md.: ASPRS, 1997.

on page 181, it is stated that the coordinate 
database uses the Hough Ellipsoid (1960).  :

Parameters are given for this ellipsoid in the table:


(Continue reading)

Andrea Peri | 8 May 19:27 2014

Info on proj4 formulas


I'm just now subscribe to this MialingLIst so before all
My best wish to all the readers.

I'm searching info about what formula is use in the proj4 to reproiect data.
There is a document where is describe the used formulas. ?

I need to understand how far is the proj4 results from other tools used in Italy

AFAIK in Italy is used a formula usually know as the "Formula's Bonifacino".


Andrea Peri
. . . . . . . . .
qwerty àèìòù
Proj mailing list
Proj <at> lists.maptools.org
Charles Karney | 29 Apr 15:14 2014

New NGA documents on UTM/UPS/MGRS; time to update proj.4 implementation of UTM?

NGA has recently published

   Universal Grids and Grid Reference Systems, Feb 2014,

   The Universal Grids and the Transverse Mercator and Polar
   Stereographic Map Projections, Mar 2014

These are revisions of

   TM8358.1: Datums, Ellipsoids, Grids and Grid Reference Systems,
   Sep 1990

   TM8358.2: The Universal Grids: Universal Transverse Mercator (UTM) and
   Universal Polar Stereographic (UPS), Sep 1989

NGA is now recommending the algorithms implemented in etmerc for the UTM
system.  So it would probably be a good idea if proj.4 had "utm" hooked
up to "etmerc" instead of the older (and less accurate) "tmerc"

See also


Charles Karney <charles.karney <at> sri.com>
SRI International, Princeton, NJ 08543-5300

Tel: +1 609 734 2312
Fax: +1 609 734 2662
Proj mailing list
Proj <at> lists.maptools.org

Mikhail Tchernychev | 26 Apr 01:07 2014

possible bug in proj.exe 4.8.0 under Windows with -V

Hi, Just wanted to let you know that it appeared to be a problem with -V 
under windows.

Here is sample session:

C:\Windows\System32>proj   +proj=tmerc +lon_0=-75  +ellps=clrk66 -V 
#Transverse Mercator
#       Cyl, Sph&Ell
# +proj=tmerc +lon_0=-75 +ellps=clrk66 +k_0=0.9996
#Final Earth figure: ellipsoid
#  Major axis (a): 6378206.400
#  1/flattening: 294.978698
#  squared eccentricity: 0.006768657997
-75.5 40.5
Rel. 4.8.0, 6 March 2012
<proj>: while processing file: <stdin>, line 1
Unknown error

The same sequence works fine under Linux.

I hope it helps,


PLEASE NOTE: This message, including any attachments, may include privileged,
confidential and/or inside information. Any dissemination, distribution or copy
of this communication by   anyone other than the intended recipient is strictly
prohibited. If you are not the intended recipient, please notify the sender by
replying to this message and then delete it from your system. Information
provided via electronic media is not guaranteed against defects including
translation and transmission errors. The company accepts no liability for any
damage caused by any virus transmitted by this email.

Geometrics Inc. | 2190 Fortune Drive | San Jose, CA 95131 USA
Proj mailing list
Proj <at> lists.maptools.org

Michal Seidl | 19 Apr 10:54 2014

Custom nadgrid and .lla format again

I would like to confirm my suspecting that there is a little mistake in
README.GRD file which describes *.lla format. As I can see values in lla
files distributed with proj it seems to me it is something like this

<line_no>: <x_shift> <y_shift> <dx_shift> <dy_shift> *

So there is line number, x and y shift, and then there are only differences 

I just guess from values. Second and next pair values are much smaller than
first pair of values.
There can be also problem in units. Are difference in micro (milionth)
seconds of arc? diff= diff(deg)*3600E6?

Here is what is documented

Subsequent lines are:

<line_no>: <x_shift> <y_shift> *

The <line_no> is zero based, and will vary from 0 to <grid_size_y>-1.  The 
number of x/y shift pairs will match <grid_size_x>.  Grid lines can be
split over multiple physical text lines.  Use the colon to identify starts
of new grid lines.  The shift values are in millionths of a secondc of arc. 

For example, from MD.lla:

Maryland - HP
  25  17   1   -80.00000      .25000    37.00000      .25000
0: 5107 -2502 -700 496 -656 468 -587 418 -481 347 -325 256 -111 152 166 50
493 -37 854 -96 1221 -118 1568 -125 1953 -143 2433 -195 2464 -281 2529 -395
1987 -729 447 -916 -3011 -1181 -5559 -406 -6094 541 -5714 1110 -5247 1289
-4993 1254 -4960 1151
1: 4757 -1695 -644 429 -627 411 -602 368 -555 299 -470 206 -328 96 -125 -15


Thanks for your reply, Michal

View this message in context: http://osgeo-org.1560.x6.nabble.com/Custom-nadgrid-and-lla-format-again-tp5135986.html
Sent from the PROJ.4 mailing list archive at Nabble.com.
Proj mailing list
Proj <at> lists.maptools.org

raul pra levis | 26 Mar 15:16 2014

Add custom projection

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } -->
I work for a company where we have our custom mercator projection.
I already developed code snippets to integrate such projection in proj4 4.8.0  (c++).
Is there the chance to collaborate with develop team to integrate it in proj4 main trunk?

Thanks and best regards,

Raul Pra Levis

Proj mailing list
Proj <at> lists.maptools.org
Phil Elson | 4 Mar 15:41 2014

Expanding a proj4 CRS definition

I'm curious to know whether it is possible for proj4 to return a complete representation of a projection definition. For instance, supposing I gave a proj4 string of:


It would be useful to get back a projection definition such as:

+proj=merc +lat_ts=0 ...

Similarly, though this is less important to me, is it possible to go from:



+proj=aea +lat_1=34 +lat_2=40.5 ...

Without just returning the string found in share/proj/epsg?

I guess what I'm really asking whether there is an internal representation of these values which can then be used to pump out a string suitable for passing through to proj4 later on?

Thanks in advance,


Proj mailing list
Proj <at> lists.maptools.org
Frederik Ramm | 1 Mar 23:05 2014

Equal Arc Projection, GeoTIFF, and GDAL/Proj4


   I've been pointed to this list after posting my question to the
German FOSSGIS-talk list (FOSSGIS is the German OSGeo chapter).

Among the things I do for a living is making raster images from
OpenStreetMap data, usually through the "Mapnik" renderer which has
Proj4 support built-in. Someone recently asked whether I could make them
an image in the "Equal Arc" projection in GeoTIFF format, and I naively
said "sure, give me the EPSG code and I'll work it out". I had never
heard the term "Equal Arc" and I somewhat assumed that the inquirer
probably meant one of the common "Equal Area" projections.

But I was wrong; what the client-in-spe is looking for is indeed the
"Equal Arc" projection that is defined here


and which, as far as I can see, has neither an EPSG code nor anything
remotely machine readable like a WKT or Proj4 projection description.
Even so, it seems to be widely used in aviation, and it seems to be an
integral part of so-called ADRG files. These ADRG files can even be
"experimentally" written by GDAL:


but of course these aren't GeoTIFFs then. I wonder:

1. Is it at all technically possible to have a GeoTIFF in Equal Arc
projection, given that I could not find any represenation of that
projection suitable for including in a GeoTIFF header?

2. If the answer to (1) is "yes", then can I create such a GeoTIFF with
GDAL, or possibly even by passing a clever Proj init string to the
Mapnik renderer?

3. If the answer to (2) is "no", then is this just an issue where
someone would have to spend some time adding support to Proj (with any
luck I could get the client-in-spe to fund this work), or are there
fundamental reasons barring us from doing that?

My internet research regarding "Equal Arc" was unsatisfying; the name
"FalconView" appeared a number of times in conjunction with this

Thank you for any insights you might have on this.



Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00'09" E008°23'33"
Proj mailing list
Proj <at> lists.maptools.org

AdamDynamic | 24 Feb 10:37 2014

Beginner Question: Latitude/Longitude to x, y conversion - understanding output


I've been scouring the internet for a couple of days now and getting
absolutely nowhere - I appreciate this is probably a simple question once
you know the answer but any help on this would be appreciated!

I have a series of latitude/longitude coordinates that i want to plot as xy
coordinates (i.e. a flat, rectangular map).

I'm using the PyProj Python library to perform the conversion, the problem
is I can't determine what the output of the function means or represents? 

e.g. Converting [51.5072,0.1275] (what Google tells me is the lat/long for
London in the UK) returns [5733755.276187301, 14193.246790158479] for a
Mercator projection - my question is '5733755.276187301 of what'? I
understand that the library converts to Proj.4 notation (?) but I can't seem
to find what the units are, or how I'd map the output onto a 900x1100

I'm using the following conversion formula which I found  here

+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
+k=1.0 +units=m  +no_defs

Any assistance would be great as I haven't been able to get any information
from anywhere else. Please let me know if more information would be useful.



View this message in context: http://osgeo-org.1560.x6.nabble.com/Beginner-Question-Latitude-Longitude-to-x-y-conversion-understanding-output-tp5105455.html
Sent from the PROJ.4 mailing list archive at Nabble.com.
Proj mailing list
Proj <at> lists.maptools.org

support.mn | 18 Feb 22:49 2014

More Proj.4 features (was Re: Aunits)


basically I have nothing against "aunits" as long as the default
behavior remains the same .. except that it is a very small
change and we would like to have more improvements
at the same time to the Proj.4 definition language.

One of the most important is the formal syntax checking and
check against most obvious user input errors (typos etc) ..
for example normal lat / lon limits on Earth etc. If errors were
detected the separate routine would then spit out a warning
or error message. This would then warn the user in fore
hand that there is an obvious error in the input. Let say
for example having an O (letter O) instead of a 0 (number 0)
in a number.. Now the sad situation is that Proj.4 says
nothing but gives crazy results and the user is not aware
of what is the problem and the crazy definition might
end up in some library and used with strange results.

The checking could be a separated subprogram that just
does the checking and nothing more. The main program
could just omit that with such data that is already checked
once to keep it simple and fast. So the check routine would
be a separated part and would not affect any of the current
library operation and programs that use it.

It would be most convenient to have that check inside
the library since it also defines the interface language
and format. Now everybody have to write it separated
if they want to have that.. situation similar to "aunits".

The syntax checker and analyzer could be also a
some kind of a preprocessor that could also handle
the "aunits" as well .. and maybe some future additional
similar requirements.

So if you do all that ... I have nothing against "aunits"!

regards: Janne.


Kal [b17c0de <at> gmail.com] kirjoitti: 
> Hi everyone,
> Is there any chance you will consider my +aunits= features (ticket
> #121). I am willing to donate any time required to get this integrated.
> Thanks!
> Kal
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj

Proj mailing list
Proj <at> lists.maptools.org