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> lists.maptools.org
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> lists.maptools.org

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, http://proj.maptools.org/faq.html, which is using a similar command line...).

What am I missing?


GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 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> lists.maptools.org
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 http://lists.maptools.org/pipermail/proj/2014-May/006855.html).

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,
http://www.ogp.org.uk/pubs/373-07-2.pdf. 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> lists.maptools.org

paul.chavent | 27 Mar 16:06 2015

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

See http://trac.osgeo.org/proj/ticket/269


Message du : 27/03/2015 14:34
De : "Howard Butler " <notifications <at> github.com>
A : "OSGeo/proj.4" <proj.4 <at> noreply.github.com>
Copie à : paul.chavent <at> fnac.net
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 http://trac.osgeo.org/proj to ensure it is not lost?


Reply to this email directly or view it on GitHub:
Proj mailing list
Proj <at> lists.maptools.org
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 (http://trac.osgeo.org/proj/ticket/271) 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> lists.maptools.org

paul.chavent | 27 Mar 15:52 2015

Add a "nofile" grid type.


Following this thread
), i suggest an improvement for being able to specify a constant vertical shift with the geoidgrids parameter.

I've created a new ticket here http://trac.osgeo.org/proj/ticket/270 with patch and more description.


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

paul.chavent | 27 Mar 13:41 2015

Fix reading failure of small GTX file.


As discussed in this thread
some GTX files fail to load as geoidgrids.

Indeed, as the smallest possible GTX file is compound of one tile (4 points), the resulting binary file may
be smaller than the size of the header read by pj_gridinfo_init (160 bytes).

I've submitted a merge request on github (https://github.com/OSGeo/proj.4/pull/1) that should solve
this issue Comments are welcome.



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

Paul Chavent | 23 Mar 23:14 2015

How to offset height above ellipsoid.


I try to convert lat/long coordinates to eqc. The origin of the eqc projection plane is at (43.315959
1.402896 320.000). My eqc specification take into account the altitude of the projection plane, so the
plane should be tangeant to a sphere with a radius of 6368437.553703493.

The specification of the translation is then :

+proj=longlat +datum=WGS84 +no_defs +to +proj=eqc +a=6368437.553703493 +lat_ts=43.315959
+lat_0=43.315959 +lon_0=1.402896 +no_defs

At this point, if i give an altitude in the LLA input, it isn't translated since no datum have been specified
for my destination projection.

For datum conversion, +towgs84 and +nadgrids seems to be the preferred choice for horizontal datum
shifting, although +geoidgrid seems the preferred way for vertical datum shift.

In order to add a constant offset to the LLA altitude, i could provide a "gtx" file with only one value for the
whole lat/long space.

I wonder if it is a good practice, or if there is other way of doing it ?

Wouldn't be possible to specify the offset on the description string for such a simple case (that also would
be easier in the case of the usage of the c API with frequent altitude offset changes) ?

The expected result is

cs2cs -rs \
     +proj=longlat \
     +datum=WGS84 \
     +no_defs \
     +to \
     +proj=eqc \
     +a=6368437.553703493 \
     +lat_ts=43.3159590 \
     +lat_0=43.3159590 \
     +lon_0=1.4028960 \
     +no_defs \
43.3159590  1.4028960  320
43.3155991  1.4024014  340
43.3155991  1.4033906  360
43.3163189  1.4033906  380
43.3163189  1.4024014  300
    0     0   0
  -40   -40   20
  -40    40   40
   40    40   60
   40   -40  -20

Thanks for your help.


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

Richard Greenwood | 18 Mar 02:59 2015

why doesn't the epsg file reference the hpgn grids?

The epsg file included with proj has definitions for hpgn coordinate systems that do not use the grid shift files, for example:
# NAD83(HARN) / Wyoming West (ftUS)
<3758> +proj=tmerc +lat_0=40.5 +lon_0=-110.0833333333333 +k=0.9999375 +x_0=800000 +y_0=100000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs  <>

So there is no datum transformation applied. But proj has the appropriate harn grid shift files here:

And changing the above definition to include the grid shift files like below seems more appropriate:
# NAD83(HARN) / Wyoming West (ftUS)
<3758> +proj=tmerc +lat_0=40.5 +lon_0=-110.0833333333333 +k=0.9999375 +x_0=800000 +y_0=100000 +ellps=GRS80 +nadgrids=wyhpgn.gsb +units=us-ft +no_defs  <>

Does the proj epsg file get created from data at www.epsg.org? And is that data lacking the reference to the grid shift files, or is it "lost in translation"? It seems like there is the wonderful resource in the harn grids that isn't getting used, but maybe I'm overlooking something.


Richard W. Greenwood, PLS
Proj mailing list
Proj <at> lists.maptools.org
Howard Butler | 13 Mar 19:27 2015

Migrate to github?


In my role as self-appointed maintainer, I became quickly aware that my brain had been poisoned by github's
ticket and development workflow. I found myself rather hamstrung without it in the context of doing the
proj 4.9.1 release.

I would like to migrate the proj Trac and Subversion instances, including all tickets, revision control,
branches, and tags, to a github repository at http://github.com/OSGeo/proj and decommission them once
there's sign-off that the migration looks good.

Unless I hear significant pushback *against* doing this, consider this message your notice that the
effort is ongoing, and I will notify once a test migration is complete for people to look around. At that
time I will then motion to switch over once folks are satisfied.

Note that this same migration was done in the past by Thomas Bonfort for MapServer, with a much larger Trac
instance (which itself was preserved from a Bugzilla instance). It's annoying to have software survive
multiple generations of bug tracking and revision control software, but I guess it's a good thing that the
software is useful enough to warrant the migration in the first place.


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