<br><font size=2 face="sans-serif">Nice summary.</font>
<br>
<br><font size=2 face="sans-serif">The problem of semantics is always worse
than the problem of computation.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">"Noel Zinn" <ndzinn@comcast.net></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">"'PROJ.4 and general Projections
Discussions'" <proj@lists.maptools.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">03/28/2009 07:25 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Proj] datum matters</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Sent by:</font>
<td><font size=1 face="sans-serif">proj-bounces@lists.maptools.org</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Interesting subject of surprising sensitivity. Let
me offer some<br>
terminology that helps me parse the issue, with an acknowledgement of EPSG<br>
for some of it.<br>
<br>
Conversions are mathematically exact (within the quality of the algorithm<br>
and machine precision) changes among coordinate systems (in the EPSG sense,<br>
not the Richard Greenwood sense), for example, lat/lon to projected<br>
Northing/Easting, or lat/lon to ECEF geocentric Cartesians. <br>
<br>
Transformations are changes in datums, what Richard calls coordinate<br>
systems, a term that I have redefined above. Transformations are
always<br>
inexact since the parameters are always empirically derived (measurements<br>
have errors) and because datum relationships vary spatially and (probably)<br>
temporally, for example, NAD27 lat/lon to WGS84 lat/lon, NGVD29 normal<br>
orthometric heights to NAVD88 Helmert orthometric heights. <br>
<br>
Some of us prefer the mathematically purity (and entertainment) of<br>
conversions and others prefer the dirty-fingernail (and remunerative) task<br>
of quantifying relationships among real-world datums. Courses for
horses,<br>
as they say in the UK. <br>
<br>
Now the EPSG (or maybe the ISO before them) have conflated these concepts<br>
into the coordinate reference system (CRS), for example, Geographical CRS<br>
for the lat/lon coordinate system of a particular datum, or Projected CRS<br>
for a particular projection on a particular datum (what Richard calls a<br>
coordinate system). I am not convinced that this taxonomy is an advance<br>
(agreeing with the recently departed), but I am so in awe of the enormous<br>
compendium of useful, real-world information that this taxonomy supports<br>
that I happily accept it as the de facto standard. <br>
<br>
Noel Zinn<br>
<br>
PS - Shouldn't pj_transform() be pj_convert() if you accept the definitions<br>
above?<br>
<br>
<br>
-----Original Message-----<br>
From: proj-bounces@lists.maptools.org<br>
[</font></tt><a href="mailto:proj-bounces@lists.maptools.org"><tt><font size=2>mailto:proj-bounces@lists.maptools.org</font></tt></a><tt><font size=2>]
On Behalf Of Richard Greenwood<br>
Sent: Saturday, March 28, 2009 7:10 PM<br>
To: PROJ.4 and general Projections Discussions<br>
Subject: [Proj] datum matters<br>
<br>
I made a post to this list earlier this week that offended at least<br>
one member of the list. I'll try here to clarify my position and<br>
hopefully not start a flame war. I know that 90% of the subscribers to<br>
this list have already forgotten more than I will ever know about<br>
projections and datums, so please be tolerant of my simplistic<br>
comments.<br>
<br>
In this era we must think in terms coordinate systems, not just<br>
projections, despite the name of the list and library. I'm using<br>
"coordinate system" as a projection + datum, or lat/long + datum.
To<br>
tie a position to the earth you need both. Many users, both C<br>
programmers incorporating the library in their own work, and end users<br>
accessing the library thru the various OSGEO stack applications that<br>
use the library, do not distinguish between a "projection" and
a<br>
"coordinate system".<br>
<br>
Two subtle, but important, changes that I have noticed in the library<br>
are: (1) No longer assuming a datum of WGS84 when either a source or<br>
destination system lacks an explicit datum (2) depredicating pj_fwd()<br>
and pj_inv() in favor of pj_transform(). These changes encourage users<br>
to think in terms of the coordinate system as a whole and may keep<br>
people out of trouble. Thanks to Frank or who ever deserves credit for<br>
these changes.<br>
<br>
-- <br>
Richard Greenwood<br>
richard.greenwood@gmail.com<br>
</font></tt><a href=www.greenwoodmap.com><tt><font size=2>www.greenwoodmap.com</font></tt></a><tt><font size=2><br>
_______________________________________________<br>
Proj mailing list<br>
Proj@lists.maptools.org<br>
</font></tt><a href=http://lists.maptools.org/mailman/listinfo/proj><tt><font size=2>http://lists.maptools.org/mailman/listinfo/proj</font></tt></a><tt><font size=2><br>
<br>
_______________________________________________<br>
Proj mailing list<br>
Proj@lists.maptools.org<br>
</font></tt><a href=http://lists.maptools.org/mailman/listinfo/proj><tt><font size=2>http://lists.maptools.org/mailman/listinfo/proj</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>