[Proj] Polar stereographic, different values on different
warmerdam at pobox.com
Thu Aug 21 22:24:27 EDT 2008
Bruce Raup wrote:
> I agree with this general philosophy. I can't imagine a bug being
> squashed within 24 hours in a typical proprietary package.
While it is rare, when I worked at PCI it was not that uncommon for
me to fix a bug reported by a user, and post a fixed shared library
within 24 hours. For whatever reason, the concept of providing fixed
binaries does not seem very common with larger proprietary software
packages these days (or perhaps I just don't see it). Nevertheless,
I think speed of bug fixing is a strength of open source, especially
for a savvy user willing to rebuild from "trunk".
> 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.
We have a modest test suite in the proj/nad directory (do "make check")
but unfortunately it is not convenient to run on win32/msvc builds
since it depends on a unix style shell.
It is my hope that the MetaCRS project will publish "test data files"
at some point which each of the software packages (proj.4, csmap,
proj4js,geotools) can use as a base for a substantial regression test.
> 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
> says you can say "proj +proj=list" to get a list of projections, but
> 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.
Agreed. Note that the PROJ.4 web site is now just a trac wiki, and anyone
can get a userid and start improving it. I no longer need to be the
> 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!
There is no much of an effort in this regard. Especially in the area
of examples, and FAQ types docs, I'm very keen on getting more people
contributing, even if rather casually.
For GDAL there is a reasonable ongoing effort to maintain decent
reference docs, but these are not really filling all the needs of
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Proj