Cleo Drakos | 23 Aug 08:38 2014

Convert the array into required coordinates

Dear guys,

I have 2d numpy array of 480 rows and 1440 columns as named by 'data' below:

The first element belongs to (49.875S,179.875W), the second element belongs to (49.625S,179.625W), and the last element belongs to (49.875N,179.875E). import os, glob, gdal, numpy as np fname = '3B42RT.2014010606.7.bin' with open(fname, 'rb') as fi:,0) data = np.fromfile(fi,dtype=np.uint16,count=480*1440) data = data.byteswap() data = data.reshape(1440,480)

How can I convert this numpy array so that its first element belongs to (49.875N,179.625W), i.e., upper left latitude and longitude respectively; and the last element belong to (49.625S,179.875E), i.e., lower right latitute and longitude respectively.

I tried to rotate it, but I do not think it is correct.

data = np.rot90(data,1)

Have some of you experienced with this type of problem? The binary file I am using is here:

Proj mailing list
Proj <at>
Aleksander Yanovskiy | 21 Aug 09:35 2014

direct geodesic problem


Maybe somebody can clarify how to solve the following direct geodesic 
problem: find the end point of a geodesic given its starting point and 
initial azimuth and the angle between the tangent planes at the 
beginning and the end points (or, equivalently, the angel between the 
normals at the points).
It seems the most easy way is to find the corresponding arc length on 
the auxiliary sphere, but I haven't found anywhere the explicit formula 
for it as the function of the point coordinates, the azimuth and the 
angle between the tangent planes at the beginning and the end points. 
And I'm not sure that such formula would be valid for the the beginning 
and the end points laying in different hemispheres.

And why is the geodesic problem in such formulation not being used in 
practice ?

Proj mailing list
Proj <at>

Chris HUDDART | 18 Aug 19:04 2014

Does anyone know of any Ebola mapping activities?

Dear All,


Does anyone know of any West Africa Ebola mapping activities?


Many thanks & regards,





The information contained in this electronic message and any attachments is intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose, distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Food Programme. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences. The sender reserves the right to monitor, record and retain electronic messages.
Proj mailing list
Proj <at>
Cleo Drakos | 18 Aug 16:13 2014

Can I convert the ellipsoids using Proj?

Dear guys,

I have the data (latitudes, longitudes, and elevations) given in ICESat/GLAS ellipsoid. This equatorial radius and  reciprocal flattening (1/f) on this ellipsoid are 6378136.30 m and is 298.257 respectively.

Now, I want to convert my data into WGS84 ellepsoid with equatorial radius and reciprocal flattening (1/f) of 6378137.000000 and 298.25722356 respectively.

Can I convert the ellipsoids using Proj?

I hope some of you can help me.

Proj mailing list
Proj <at>
Roger Bivand | 18 Aug 11:32 2014

#229 - trunk init still broken

Please could someone patch pj_init.c with the bugfix for the missing 
found_def after line 263? The fix has been known for months, but no action 
has been taken.



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>

Charles Karney | 10 Aug 23:49 2014

rhumb lines + arbitrary precision arithmetic

I've released version 1.37 of GeographicLib.  See

A couple of items might be of interest to the readers of this list.

(1) Classes and a utility for computing rhumb lines.  For details, see

(2) Support for high precision arithmetic.  A compilation option is
provided to allow linking against Boost (for quad precision) or MPFR
(for arbitrary precision).  Thanks to C++'s operator overloading this
entailed minimal changes to the code itself.  For details, see


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

Tel: +1 609 734 2312
Fax: +1 609 734 2662
Proj mailing list
Proj <at>

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 script (see, 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.




Submitted for PostGIS :

Best regards,



Geospatial professional services
Proj mailing list
Proj <at>

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:

Although called Hough in honor of F. Hough,  it 
appears to have been the work of that remarkable 
lady Dr. Irene Fischer who lived to be 102 and 
see her work incorporated into WGS84.  See:

Fischer, Irene. 1959. "A Tentative World Datum 
from Geoidal Heights Based on the Hough Ellipsoid 
and the Columbus Geoid". Journal of Geophysical Research. 64 (1): 73-84

Can anyone offer some ideas about the amount of 
error which would be introduced by mixing Hough 
lat/lons and WGS84 lat/lons obtained from Google 
Maps/ Google Earth when georeferencing the Corona 
imagery for further processing in GIS 
programs?  Or are Bursa-Wulff or Helmert datum 
transformation  parameters available somewhere?

Irwin Scollar

Proj mailing list
Proj <at>

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>
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 International, Princeton, NJ 08543-5300

Tel: +1 609 734 2312
Fax: +1 609 734 2662
Proj mailing list
Proj <at>

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>