[Proj] datum matters

Michael P Finn mfinn at usgs.gov
Mon Mar 30 16:47:55 EST 2009

Nice summary.

The problem of semantics is always worse than the problem of computation.

"Noel Zinn" <ndzinn at comcast.net>
"'PROJ.4 and general Projections Discussions'" <proj at lists.maptools.org>
03/28/2009 07:25 PM
Re: [Proj] datum matters
Sent by:
proj-bounces at lists.maptools.org

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 
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 

-----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

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
Proj mailing list
Proj at lists.maptools.org

Proj mailing list
Proj at lists.maptools.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20090330/71515849/attachment.htm 

More information about the Proj mailing list