[Proj] "Double Ellipsoid" error, reproduction
ndzinn at comcast.net
Fri Dec 12 17:28:30 EST 2008
Since it's come up a few times, it's worth noting that the EPSG dataset
began as - and still pretty much is - an *inventory* of geodesy and
cartography encountered in the oil industry. Projections *used* in the
industry, or by the national authorities from whom prospects are leased, are
always associated with a geodetic datum. Consequently, projection *codes*
(with associated numerical grid parameters) have datums attached. On the
other hand, projection *methods* (that one might find described
algorithmically in Guidance Note 7-2 without numerical grid parameters) do
not. So, it's not really fair to characterize EPSG one way or another.
Datums are conflated when required for a specific usage, and are not when no
instance of usage is specified. -Noel Zinn
From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Christopher Barker
Sent: Thursday, December 11, 2008 12:51 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] "Double Ellipsoid" error, reproduction
First, let me say that I am a Scientist/Engineer first, a Software
developer second, and a cartographer a very, very, very, distant third...
So take my comments as you will.
Gerald I. Evenden wrote:
> Clearly note: that it was and still is quite clear that datum conversions
> projection operations are totally different, mathematically and logically,
Are they really so different mathematically? I see both as a transform
from one coordinate system to another. I suppose that a projection is
from a spheroidal(or ellipsoidal) system to a Cartesian one, if that's
what you mean. Though if you want to go from one projection to another,
then it's still a Cartesian to Cartesian transform -- do you always go
through geo-coords to get from one projection to another?
> there is *no* reason to combine the operations into one procedure.
> Programmatically combining the operation made no sense and was a clear
> violation of modular programming practices.
Here is where a take issue -- but maybe it's only with what you mean by
"combining". It seems to me that datum conversion and projecting share a
great deal from a programming perspective. Certainly I/O, but also data
needs (ellipsoids, etc) and others.
It also seems that EPSG has, like it or not, merged the two concerns and
thus software that deals with EPSG codes needs to work with the two
> On the surface I find nothing wrong with cs2cs and it certainly should be
> valuable program. However, I feel that the internals are put together in
> manner that first: made it harder to develop and now: much more difficult
I know nothing of the internals, so I can't comment.
But from a software development perspective, I feel strongly that one
should think in terms of libraries first, and applications second. the
projections+datums library should provide all the tools required to make
it easy to write cs2cs, and I think this does mean a certain merging, or
at least sharing of routines, between projection support and datum support.
> By combining datum and projection operation internally with
> modifications of proj.4 it is impossible to easily upgrade cs2cs when
> corrections or improvements of libproj4 become available.
That has nothing to do with cs2cs, it has to do with the fact that proj
has been forked, and the two forks are not API compatible. I suppose
PROJ.4 could have been built as a library that used libproj, adding the
extra datum support, so that a fork would not have been required, but
I'm not going to second-guess anyones decisions from years back.
It seems that all (most?) agree that PROJ.4 could use some refactoring
(and maybe re-naming) -- but who has time to do it?
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
Proj mailing list
Proj at lists.maptools.org
More information about the Proj