[Proj] Question about authorship

[Clifford J Mugnier]

Gentlemen:

The EPSG documentation is mainly authored by Mr. Roger Lott, the retired
Chief Surveyor of British Petroleum Oil Company in London.  Mr. Lott relied
on the documentation and writings of Mr. John P. Snyder whenever Snyder
wrote on a particular projection.  However, Snyder was ONLY interested in
the map projections that were used by the U.S. Geological Survey (USGS) in
his books published by the USGS.  As a result, concepts germain to
topographic mapping by the USGS were addressed by Snyder and subsequently
by Lott.

On the other hand, Mr. Lott was interested in world-wide useage of
large-scale map projections used for topographic maps and navigation charts
specifically with emphasis on oil exploration and production.  Many of
these were not used by the USGS and therefore Snyder did not write on
those.  As a result, the mathematical documentation by Mr. Lott on a lot of
projections were a product of his own vast experience in oil exploration
during his world-wide career.  Concepts that were promulgated by Snyder for
USGS applications were not always valid for applications that Mr. Lott had
encountered during his career.

For instance, the Hotine Rectified Skew Orthomorphic (oblique Mercator) is
detailed by Mr. Lott but the Laborde Oblique Mercator is not.  Why is that?
It's because Mr. Lott's objective was plus or minus a tenth of a meter
accuracy for oil exploration applications.  NOT geodetic accuracy!  The
standard computer operating system for the oil patch world-wide is SUN
Solaris (UNIX).  What is the 800-pound gorilla for UNIX GIS software?
ESRI.  When the GIS Department of the Malagasy Republic (now re-named)
needed support for their country, (Madagascar); ESRI worked up a "kludge"
set of parameters to get the Hotine RSO to produce Grid coordinates more or
less compatible with the Laborde projection to an accuracy of a tenth of a
meter within the land area of the island.  That computational accuracy met
Mr. Lott's objective, so no further elegant mathematical
derivation/documentation was necessary as far as the EPSG was concerned.
Geodetically elegant?  No.  Practically functional as far as the "Oil
Patch" is concerned?  Yep.

And so on and so forth for the other questions, including the two-standard
parallel version of the Normal Mercator.  It is the identical mathematical
equivalent of the Normal Mercator with a scale factor at origin (at the
equator) equal to a value less than unity.  Why call it such?  Because
that's how NGA/NIMA (and the UK Military Survey and the UK Hydrographic
Office) describes their charts, and that's a big deal to the "Oil Patch."
(Same goes for the Lambert Conformal Conic).

The EPSG mathematical documentation is excellent when you consider the
context in which it was developed and its ultimate objectives.  Same goes
for Snyder's works.  They both have their limitations as far as a catholic
treatise is considered, but I doubt that PROJ4 is a catholic treatise,
either.

Check out chapter three in the 5th edition of the "Manual of
Photogrammetry" if you want some detailed math.  I wrote it.  There's a new
"Manual of GIS" being planned by the American Society for Photogrammetry
and Remote Sensing, and I've been asked to write a chapter for that on
projections also.  It'll be out in a year or two; I have yet to sit down
and write the chapter.

Regards,

Clifford J. Mugnier
Chief of Geodesy and
Associate Director,
CENTER FOR GEOINFORMATICS
Department of Civil Engineering
CEBA 3223A
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA  70803
Voice and Facsimile:  (225) 578-8536 [Academic]
Voice and Facsimile:  (225) 578-4474 [Research]
======================================================
http://www.asprs.org/resources/GRIDS/
http://www.cee.lsu.edu/facultyStaff/mugnier/index.html
======================================================





On Fri, 04 Mar 2005 09:33:47 -0500, Gerald Evenden
<gerald.evenden at verizon.net> wrote:
> When mentioning EPSG, I presume we're talking about the #7 manual?

Gerald,

Most of the notes sections are extracted from the text in the
projections methods tables in the EPSG database.  I believe the
#7 manual is suplemental information.

> Just discussing Mercator I have problems with terms like "natural
> origin."
> If there is a "natural origin" for Mercator it is the equator.  The
> origin can
> be artificially shifted to any latitude with +lat_0.

The intent of the web pages are to help software developers, such as
myself, relate the terms and names for projections between the various
environments.  I am not saying that "natural origin" is a meaningful term,
but it is a name used in EPSG and I think carried into GeoTIFF because
it was in EPSG.

>   This should not
> be confused with
> +lat_ts= which a method of referring to "latitude of true scale."
> +lat_ts
> assumes that the user expects the scale (h=k) is unity at that latitude.
> +lat_ts is used as an alternative to +k_0 which refers to the scale
> at the equator.  +k_0 is primarily uses where +lat_ts is not appropriate
> such as Transverse Mercator.  I think it is inappropriate to combine
> specifying +lat_ts and +k_0 to be used simultaneously.

OK, so I gather you point is that the PROJ.4 equilvelents to what
EPSG calls the latitude of natural origin is +lat_0, not +lat_ts, right?

Are you saying that +k_0 and +k are different?  That +k_0 refers
to the scale at the equator?  I don't think I have ever been aware of
a distinction between them.

> In Mercator (1SP) the description interprets Mercator as a limiting
> condition for Lambert Conformal Conic.  In theory true but often
> following such a development often to math that falls apart.
> Mercator is usually developed on its base definition and not a
> limiting condition for a cone.
>
> What really caught my eye with this stuff is the two entries for
> Mercator: (1SP) and (2SP).  C'mon.

Why do you say "C'mon"?  Is it silly to refer to Mercator 1SP and
2SP?   I was never clear on the distinction, if there is one, but
EPSG does have a projection method (9804) for "Mercator (1SP)"
and another (9805) for "Mercator (2SP)".

On slightly more review, it would appear that Mercator 2SP is just
junk, and that the 1SP version is just the plain Mercator we are
familiar with.  If you concur, I will update the pages to refer to
Mercator_2SP as an alias for Mercator.  Certainly EPSG does not
have any coordinate systems defined using method 9805.

ESPG has a few projected coordinate systems defined using
Mercator 1SP (9804) (ie. PCS 2934 / Segara (Jakarta) / NEIEZ),
but they all use the same set of parameters using 9804, and that
has a "Latitude of natural origin" of 0.0,  a scale of 0.997, and a
"Longitude of natural origin" of 110 degrees.

Would the proper rendition of this for PROJ.4 be:

+proj=merc +lat_0=0 +lon_0=110 +k_0=0.997

What if the latitude was not zero?

The confusion over mapping of parameters wouldn't likely be so
important if we only had to worry about the predefined projected
coordinate systems in EPSG, but in fact EPSG "projection method"
codes are also used in places like the GML coordinate reference
system format as a "well known" source for projection parameters.
So any Mercator coordinate system expressed in GML would
normally be done by stating the projection method is EPSG 9804
(Mercator 1SP), and that the parameters are the EPSG parameters
(lat of natural origin, long of natural origin, scale, false easting and
norting).   So, in this scenario we can really run into mercator
coordinate systems where a latitude of natural origin is given that
is not the equator, and with a scale.

I realize the illogic of the EPSG database is not really your problem.
What I want to emphasise is that in a GIS world which has oriented
itself around EPSG for standards conformant coordinate system
descriptions, it is important to try and make some sense out of how
this should be interpreted.

> Lastly, Mercator is dismissed a a projection.  This may be true with
> regard to grid systems but certainly not true for navigational purposed.
> Because of it properties it is still widely used for navigation charts

Where is Mercator dismissed as a projection?  In any event, it isn't
me that would be dismissing it if I am just copying the EPSG notes.

> I can obviously refer to EPSG #7 and I am aware of PROJ.4 usage but I
> am handicapped with details of GeoTIFF and others.

The GeoTIFF spec is available online, but one area that it
was very weak was in listing the projection methods and the
parameters that go with them - much less explaining how those
parameters relate to other formats for describing the same projection.

I was assumed, I guess, that folks would look up the details in the
EPSG database though in fact the GeoTIFF projection method codes
and parameter codes are distinct from the those in the EPSG database.
I think the EPSG projections stuff was even less developed at the time
the GeoTIFF specification was setup.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
Proj mailing list
Proj at xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj