[Proj] Question about authorship

[Frank Warmerdam]

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