[Proj] "Double Ellipsoid" error, reproduction

[Gerald I. Evenden]

On Monday 08 December 2008 12:24:19 pm Frank Warmerdam wrote:
> Gerald I. Evenden wrote:
> > I think more desirable approach is to create a d2d program with optional
> > i/o filtering through projection procedures.  One might have options
> > like:
> >
> > d2d --in=EPSG1234 --out=NAD83_1105
> >
> > where --in and --out may refer to library systems but one can also have
> >
> > d2d --in=proj=latlon --datum_in=xyx --datum_out=mm \
> >           --out="proj=merc ellps=WGS84 R_A"
>
> Gerald,
>
> Modulo syntax differences, cs2cs can already be used just to do the datum
> transformation step if desired.  So I don't see your point.
>
> > To me, that kills all mice with flexibility and ease of use.  *AND* you
> > can easily use libproj4 updates.  ;-)
>
> I would note that this still does nothing for the folks who use PROJ.4
> within another program like MapServer or GDAL.  There typically the
> application knows very little about the coordinate systems or what steps
> might be used.  They just call pj_init() for the source and destination
> coordinate system and then call pj_transform().

Hey!  I am out of this discussion.

What has been done, IMHO, is a grievous design flaw.  It is like slipping odd 
and unrelated attributes into the trigonometric library so as to "facilitate" 
the creation of a particular program.

There is nothing wrong with buffering ignorant users from the details of 
complex problems but *not* at the expense of poor coding practices.  There 
are many ways of doing this that would not require destroying the modularity 
of code sources.

A case in point.  As many of you know I used the GSL library recently.  I 
often use foreign libraries.  But in all of my usage of such sources I do not 
even look at the source code nor does the thought ever cross my mind to 
change such sources to facilitate some aspect of my particular problem.  If 
there is a usage problem, then it is up to my external code to work around 
it.  The result is that when an update to these libraries comes along I can 
normally easily update my own application by merely relinking the program.  I 
respect the "sanctity" of such source material in order to maintain my own 
flexibilty and coding sanity.

Obviously, this attitude has not been extended to the proj system by others.  
I have tried to maintain a consistancy of the proj library to support the 
above development philosophy that, as it seems, is purely my own.  The 
biggest change that I recall was translating the namespace from pj_ to proj_ 
and a few related items which would hopefull help avoid conflict with other 
software.  I believe that one can go back many years and not see any 
fundamental differences in the projection library.

Sorry to bore the non-programmers with a discussion of coding practices.

> This is *by far* the most common use of PROJ.4 and then there is no
> option to setup program pipelines.
>
> Best regards,



-- 
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