[Proj] Just a short visit with some items

Gerald I. Evenden geraldi.evenden at gmail.com
Mon Apr 6 13:58:53 EST 2009


Hi. Your grumpy old proj'er is back but fortunately only
for a moment to make a couple of announcements:

1. The website:

http://members.verizon.net/~gerald.evenden/proj4/

has been updated to reflect status of my activities
on the new libproject and application spin-offs.
Distribution is by GNU `configure' and I'd appreciate
any trials and comments.  Sorry, only Linux, Unix
and clones.

2. How long this website will retain its name is
problematic because I may be changing phone and
thus Internet provider.  It would be nice to get a
domain name and independent space provider but this
is unbroken ground for me and needs research.

--------------------

It would be nice to link this stuff with a group with
a group that would provide a little more exposure.
This group was appropriate but *severe* philosophic
differences prohibit a tight connection.  Read the
"Note 1" link on the above website title line.  ;-)

--------------------

I am currently updating the proj material with the
only minor addition of option pm=<longitude>.  This
only affects converting longitude data in the
projection process.  Any longitude in the initialization
process is assumed to be in the longitude of the
old prime meridian.

Suggestions of putting geographic limits to data
being projected is impractical.  The main place this
suggestion was aimed at was limiting the longitude
range for UTM.  But UTM longitude range varies from
+-3 degrees for most zones up to +-6 degrees for
some Scandinavian regions.  Also, military limits are
base upon over-ranging in meters---not longitude.  Except
for checking for latitude range (which libproj4 already
does) it is an impractical option.

There will be some changes in the projection structure
but other than the pm addition, there is not expected to
be few entry changes for application programmers or users.
The header file will be changed to <project.h> and the
entry proj_initstr(s) will be dropped because all that
is required is a macro to imitate proj_init(s,1) or, for
that matter, to accommodate 'proj-4.x's' pj_init_plus.
Of course, you could do that with libproj4 some time
ago.

Outside of changing from pj_ to proj_, users who *properly*
employed osgeos proj.4 will have almost no problems using
the project library.

----------------------------

Please forgive me for going back to the all-time stupid
statement from 25 March:

"I would discourage the use of pj_fwd and pj_inv. If "obsolete" is
offensive, how about "private". It is so provincial in this day and
age to think that we merely project and un-project without concern for
datum."

This individual failed to recognize that a very large number
of world scale maps are generated each year.  If a location
is in error by 1km the mislocation on the printed page
is about 1mm for a 1:1,000,000 scale map (regional in
extent depending upon page size) and for a 1:100,000,000
page size world map mislocated by 10 microns.  I doubt
that most map makers will quibble too much on the 1mm
and laugh at 10 microns.  I will suggest that there
are a large population of map makers that rightfully care less
about datum shift.

Secondly, to compare a complex entry like:

p = pj_transform(pj_latlong, pj_merc, 1, &x, &y, NULL );

to the elegance of simplicity:

XY pj_fwd( LP lp, PJ *P );

and infer an improvement?  For shame!!!  For shame!

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