[Proj] "Double Ellipsoid" error, reproduction
Christopher Barker
Chris.Barker at noaa.gov
Thu Dec 11 13:51:27 EST 2008
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 and
> 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
together.
> On the surface I find nothing wrong with cs2cs and it certainly should be a
> valuable program. However, I feel that the internals are put together in a
> manner that first: made it harder to develop and now: much more difficult to
> maintain.
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?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
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
More information about the Proj
mailing list