[Proj] datum matters

[Noel Zinn]

Interesting subject of surprising sensitivity.  Let me offer some
terminology that helps me parse the issue, with an acknowledgement of EPSG
for some of it.

Conversions are mathematically exact (within the quality of the algorithm
and machine precision) changes among coordinate systems (in the EPSG sense,
not the Richard Greenwood sense), for example, lat/lon to projected
Northing/Easting, or lat/lon to ECEF geocentric Cartesians.  

Transformations are changes in datums, what Richard calls coordinate
systems, a term that I have redefined above.  Transformations are always
inexact since the parameters are always empirically derived (measurements
have errors) and because datum relationships vary spatially and (probably)
temporally, for example, NAD27 lat/lon to WGS84 lat/lon, NGVD29 normal
orthometric heights to NAVD88 Helmert orthometric heights. 

Some of us prefer the mathematically purity (and entertainment) of
conversions and others prefer the dirty-fingernail (and remunerative) task
of quantifying relationships among real-world datums.  Courses for horses,
as they say in the UK.  

Now the EPSG (or maybe the ISO before them) have conflated these concepts
into the coordinate reference system (CRS), for example, Geographical CRS
for the lat/lon coordinate system of a particular datum, or Projected CRS
for a particular projection on a particular datum (what Richard calls a
coordinate system).  I am not convinced that this taxonomy is an advance
(agreeing with the recently departed), but I am so in awe of the enormous
compendium of useful, real-world information that this taxonomy supports
that I happily accept it as the de facto standard.  

Noel Zinn

PS - Shouldn't pj_transform() be pj_convert() if you accept the definitions
above?


-----Original Message-----
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Richard Greenwood
Sent: Saturday, March 28, 2009 7:10 PM
To: PROJ.4 and general Projections Discussions
Subject: [Proj] datum matters

I made a post to this list earlier this week that offended at least
one member of the list. I'll try here to clarify my position and
hopefully not start a flame war. I know that 90% of the subscribers to
this list have already forgotten more than I will ever know about
projections and datums, so please be tolerant of my simplistic
comments.

In this era we must think in terms coordinate systems, not just
projections, despite the name of the list and library. I'm using
"coordinate system" as a projection + datum, or lat/long + datum. To
tie a position to the earth you need both. Many users, both C
programmers incorporating the library in their own work, and end users
accessing the library thru the various OSGEO stack applications that
use the library, do not distinguish between a "projection" and a
"coordinate system".

Two subtle, but important, changes that I have noticed in the library
are: (1) No longer assuming a datum of WGS84 when either a source or
destination system lacks an explicit datum (2) depredicating pj_fwd()
and pj_inv() in favor of pj_transform(). These changes encourage users
to think in terms of the coordinate system as a whole and may keep
people out of trouble. Thanks to Frank or who ever deserves credit for
these changes.

-- 
Richard Greenwood
richard.greenwood at gmail.com
www.greenwoodmap.com
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj