[OSRS-PROJ] Re: Weirdnesses in the source code
proj at ton.iguana.be
Sat Jul 19 18:32:51 EDT 2003
In article <1058636379.3317.23.camel at localhost>,
"Gerald I. Evenden" <gerald.evenden at verizon.net> writes:
> First of all, can we change the name of this thread. "Weirdnesses"
> is not that meaningful.
> One problem with projection parameters is that several projections
> have different means of expressing their control For example,
> Lam. Conformal Conic can use two parallels or one parallel and
> a scale factor.
> Another item is that many control factors are not explicitly
> mentioned in the -lP line because they are common to all projections.
> For example, ellipsoid/sphere parameters, false easting/northing, ... .
> Earlier versions attempted to address this problem with the
> ancillary files that contained definitions for default
> parameters but was later dropped.
> What I see here is the never ending debate as to how much documentation
> should be placed in the library itself. What is in there now is
> minimal and what I believe is appropriate for the current library.
> To add more detail and user assistance then a complex addenda
> is added that would have to be tailored to various
> GUI systems. I do not feel that is part of the basic library that
> tries to restrict itself to merely doing the numbers.
Still, this kind of information is meaningfull. E.g. I'm using it to try
to generate testcases that try to cover all meaningfull combinations, so
I indeed parse the -lP output, collect the vars mentioned there, add the
standard vars and then give them all kinds of combinations of values. I'd
rather do that then have to read the docs for each projection and then
program it by hand, even though a few things have to be handled special.
Especially since otherwise I'd have to repeat this on each new
When you're using a specific transformation this kind of stuff is indeed
pretty irrelevant, but whenever you have a metaprogram that tries to
support them all, you need it. And then it gets pretty clear that this
purely human readable stuff that doesn't get compiler checked has many
imperfections :-( Fortunately I'm doing this in perl where it's pretty
easy to fudge strings and sort of "repair" it.
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
More information about the Proj