[Proj] Emulating Lambert Conic Conformal (2SP Michigan) in PROJ.4.
Mikael.Rittri at carmenta.com
Thu Apr 2 05:19:14 EST 2015
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
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
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
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
For Michigan Central, the example conversion above agrees with
the test example in IOGP Guidance Note 7.2, section 220.127.116.11, 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
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
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
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
More information about the Proj