[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