[Proj] The problem with proj.4
Gerald I. Evenden
geraldi.evenden at gmail.com
Wed Dec 10 10:59:20 PST 2008
While there seems to be lull in the hot debate about separation of church and
state ... er ... datum and projection, I was browsing the net and also
looking at everyone's bible: Guidance Note 7.
What seems clear is that seemingly without exception discussions about datums
and projections are divided into different web sites and/or different section
or different "chapters". Even in GN-7 there are the sections on projections
followed by sections on datum shifting.
Thus, why is it so necessary to bind the two operations so tightly as done in
the proj.4 distribution? I cannot find a precedence for this concept.
But remember, I am talking about the library and building blocks of useful
software and *not* application programs. It is certainly fine that cs2cs
combines the operations but its creation could have just as easily (more
easily, most likely) done with function-separated material. The user would
have been none the wiser.
My advice would be to see a collection of "libraries" with functions covering
most if not all phases of geodetic computations. My new geodesic lib would
be include once I do the version with 'h'. There should be a library
covering *all* the various datum transformation methods. I don't think the
current proj.4 stuff is so comprehensive. Somewhere, the xyz material fits
in. Etc, etc. Applications will naturally follow---and use the libraries of
the collection.
Lastly, the collection should not be called proj.4. A more appropriate name
should be given for the general collection. Anything with "proj" in the
title should be just what it indicates: projection material.
--
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
More information about the Proj
mailing list