[OSRS-PROJ] Lambert Conformal Conic 1SP

Sun Feb 9 16:52:23 EST 2003

Gentlemen,

The EPSG database has an objective of attaining approximately ±0.1 meters
in computational accuracy.  That is according to a personal phone
conversation I had with Mr. Roger Lott, now retired Chief Surveyor of BP
Oil in London.  EPSG has enormous holes in its database and details, but is
fair as it exists.  The computational examples show ONE MORE digit than
their basic objective.  EPSG was NOT designed to be of geodetic-quality.
It was designed to be of passable utility for hydrocarbon exploration and
development.  The addition of the French Army Truncated Lambert (partially)
Conformal Conic was at my urging.  After a couple long phone conversations
with Mr. Lott, he did a bit of research, verified what I was talking about,
and added it to the EPSG documentation and collection of math models.  This
is mainly for North Africa, but for other "vacation spots" in the Middle
East also.  These details are in many of my monthly columns that are
published in "Photogrammetric Engineering and Remote Sensing."  (Check out
Morrocco and Algeria, if you're interested).

In regard to "conformal" conic projections, there are some whopping holes
in what's been written of late.  There is only one Lambert (fully)
Conformal Conic projection.  There are two basic ways of defining the same
projection.  Those methods are the "British Definition," and the "American
(French) Definition."  Both ways may use the math found in C&GS Special
Publication 251 "Conformal Projections in Geodesy and Cartography" by Paul
D. Thomas.  John P. Snyder relied on Thomas, and those looking for
definitive derivations should consult Thomas' work.  Snyder's work was not
intended for geodetic use; it was intended for USGS applications in
medium-scale mapping.  Snyder's work is a magnificent achievement of his
objective.

The fully conformal Lambert has its developed surface in either a tangent
case or a secant case.  Period.  If we consider a tangent case, then the
scale factor at the latitude of origin is equal to unity.  If we consider a
secant case, then the scale factor at the latitude of origin is less than
unity.  Period.

One can SAY there's one or two standard parallels, but that's a
complicating factor, not a simplifying one.  The Americans and French
normally (like to) define their secant zones with two standard parallels
that are integer degrees with integer minutes or the French method of
integer grads - commonly with Paris as the Prime Meridian, too.  The
Americans and French then wind up with a scale factor at the latitude at
origin and the latitude at origin as some odd value.

The British, on the other hand, developed (in 1916), their Lambert zones
with a defining latitude of origin in integer degrees and integer minutes,
and a FRACTION OF TWO WHOLE NUMBERS.  For instance, the "Minute Mesh" Grids
of the British Survey of India developed a number of Lambert zones in
British India and its environs as:

      Latitide of Origin       Scale Factor at Origin

Zone 0:    39º 30' N                 649/650,
Zone I:    32º 30' N                 823/824,
Zone IIA:  26º N                     823/824, etc.

Most of this stuff is quite straightforward if we just look at the original
works and the original publications.

OTHER kinds of Lambert include the French Army version (still used), the
Spens of Sweden (not used anymore), and the Oblique version of Professor
Krovak used in the Czech Republic.  The Krovak method uses the Equivalent
Sphere in similar fashion as the old French Army version, they just took a
different fork in the road of implementation.

In reference to the rounded-off example computations of EPSG for the
Jamaica National Grid of 1969, for those seeking to validate
transformations, try chasing the following decimal points:

Latitude = 17º 55'55".80 N
Longitude = 76º 56' 37."26 W
X = 255,966.582 m
Y = 142,493.511 m.

In the United States, the defining equations for the State Plane Coordinate
Systems are in Jim Stem's monograph that may be downloaded in .pdf format
from the www.ngs.noaa.gov web site.  What's the criterion for computational
accuracy for the U.S.?  It's plus or minus a tenth of a millimeter.

If your objective is cartographic transformations, then Snyder's USGS
publications are ideal for use in the United States.  If your objective is
geodetic transformation, then Stem's NGS publication is the national
standard for use in the United States.

If your objective is geodetic transformations in foreign countries, then
EACH local national government's publications are the ONLY authorities.
Usually it takes a lot of historical research, some of it traditionally
military secret.  "One size fits all" will NOT work for geodetic-accuracy
transformations.

A collection of "example" transformations?  Only useful if garnered from
each soverign country's civilian geodetic agency or military mapping
directorate.  Sometimes, that is impossible.  I have been trying for 15
years to get such information out of Cyprus.  The last graduate student I
knew that went back home for a holiday (and a trip to his family's Dentist
in Cyprus), was treatened with bodily harm if he ever came back and asked
such a thing in their office!  They actually chased him out of their
building!

There's possibles, and then there's a bunch of impossibles ...

Cliff Mugnier
LOUISIANA STATE UNIVERSITY

--------------------------------------

Aye!  That was a nasty one.  One suggestion that might have helped
is to try the -V option and look at the final list of options
that proj decides to use.

I reiterate that this problem shows the need for certification
tables usable in testing projection programs.  That is, a list of
geographic coordinates and their corresponding cartesian space
values for the worlds grid systems.  How this list can be used
with individual projection packages will, of course, vary, but
at least a list would be available and individual software can
can be constructed to use the definition data to test the
software.

As for testing the PROJ.4 system I would be glad to assist in
any way.

On Sat, 2003-02-08 at 23:52, Frank Warmerdam wrote:
> Gerald I. Evenden wrote:
> > I compiled and loaded PROJ on my RedHat Linux system, edited your
> > email into a script and executed it:
> >
> > proj +proj=lcc +lat_1=18 +lat_0=18 +lon_0=-77 +k_0=1 +x_0=250000
> > +y_0=150000 +ellps=clrk66 +units=m <<EOF
> > 76d56'37.26"W 17d55'55.80"N
> > EOF
> >
> > produces:
> >
> > 255966.58       142493.51
> >
> > These numbers seem to match the JAD69 / Jamaica National Grid
> > numbers in the referred to web page.
> >
> > You seem to have a flawed version of proj.
>
> Gerald,
>
> Thanks for trying this out.  Seeing that you were getting the
> correct results I was able to dig in deeper and figure out what
> was happening differently.  It turns out that if proj finds the
> proj_def.dat file, then it will pick up a default lat_2 value
> of 45 from it, and this is what screws up the results.
>
> The proj_def.dat file contains:
>
> <lcc> # Conterminous U.S. map
> lat_1=33
> lat_2=45
> <>
>
> For my purposes it is sufficient to add the +no_defs item on
> the commandline to supress the default values.
>
> So in summary, for LCC1SP  use +lat_0 and +lat_1, and make sure that
> the no_defs flag is used to avoid including any default parameters.
>
> Best regards,

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.