[Proj] Polar stereographic, different values on different platforms?

[Gerald I. Evenden]

On Thursday 21 August 2008 5:49:31 pm Bruce Raup wrote:
> Thomas,
>
> On Thu, Aug 21, 2008 at 3:17 PM, Thomas Knudsen
>
> <knudsen.thomas at gmail.com> wrote:
> > 2008/8/21 Bruce Raup <brauplists at gmail.com>:
> >> but the colleague I'd just introduced to all these tools is getting a
> >> bad first impression of open source geospatial software (his words).
> >
> > IMHO your colleague has actually rather gotten a bad impression of
> > Microsoft Compilers.
>
> Hopefully, this is now his impression, but the *first* impression was
> formed before Eric's diagnosis.  I tried to set him straight!

We hope!

> > Eric Miller's quick diagnosis of the cause of the problem is a wonderful
> > example of what Eric Raymond dubbed Linus' law: "`Given enough eyeballs,
> > all bugs are shallow". Another confirmation of the superiority of the
> > open development method ("bazaar style" for proj vs. "cathedral style"
> > for Microsoft's
> > compilers, to follow Eric Raymond's terminology).
>
> I agree with this general philosophy.  I can't imagine a bug being
> squashed within 24 hours in a typical proprietary package.
>
> However, I see two areas for improvement here:
>
> 1)  a rigorous test script to test the output of proj against known
> correct values (within some tolerance).  It should test forward and
> reverse transformations, as many of the projection/datum combinations
> as is practical, using points from all eight octants of the globe.  If
> this existed (and covered this particular projection), the bug would
> never have been released.  I've offered to make a start at this if
> this doesn't exist already.

There once was test material for GCTP that I occasionally used in the early 
stages of proj4.  I'm not sure they are still around.  The data only covered 
US state plane systems and thus only a few projections.

There are some problems with doing a general test of projections.  One of them 
is the detail that some projections have several options which complicates 
the process.  Another detail is that a testing software must allow for 
precision of testing and "round trip" precision.

> 2) Better user documentation.  At least one of the docs on the web
> site is out of date (ftp://ftp.remotesensing.org/proj/OF90-284.pdf

My goodness, it is still around in spite of some changes in the system.
My current efforts are slow and at 128 pages less than half way through the 
effort.  Even the last copy is not up to date as it uses the old pj_ rather 
than proj_ namespace.  Right now I am trying to redo the Transverse Mercator 
section (now about 8 pages) which may only be half done.  Currently delayed 
by getting used to an updated OS, reinstalling software and trying to figure 
out how to do some non-map graphics.

> says you can say "proj +proj=list" to get a list of projections, but

That's part of the problem of being of the Open-File report being woefully out 
of date.  Try "[l]proj -lp".  Oops.  That only works on my sources.  Dunno 
about other distributions.

See.  That is also part of the problem(s).  I go by a very broadly dated 
release number (currently proj4.3) and a tightly spec'd distribution date 
which is part of the distribution tarball name.  As I recall, 4.3 occurred 
when it went to proj_ name space.

> this doesn't work in any version I've seen -- I know it says it's old,
> but how is a user to know what is out of date and what is not?), and
> it would be good to have more examples out there to copy. A discussion
> of how to treat the datum and ellipsoid separately (in cases where
> they are not the same) would be particularly useful.  These issues are
> even more pressing with GDAL, where the -wktext flag can affect how
> the underlying proj does its job.

Of course there is also an underlying problem in that original proj *and* my 
current software does not have anything to do with datums.  Inclusion of 
datum conversion was the work of others.  The reasons have  been exhaustively 
discussed before.  This is one of the basic problems with all discussions 
about "proj[4]".  For most of you, the discussion is about software that 
contains a good deal of what of the "proj" that I am very familiar with but 
there is also a good deal of value added 'stuff" I know nothing about.

> There are some good books out there now on some of the higher level
> packages like MapServer, but I wonder if there are any efforts under
> way to consolidate and expand the documentation for Proj/GDAL/OGR?  I
> wish I had more time to spend on this kind of thing myself!

Glad to jaw about this at any time.  Perhaps we should also review some old 
issues and see where things are going.

> Thanks,
> Bruce



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