[Proj] "Double Ellipsoid" error, reproduction
Gerald I. Evenden
geraldi.evenden at gmail.com
Mon Dec 8 13:35:27 EST 2008
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
More information about the Proj
mailing list