[OSRS-PROJ] Proj.4 vs Geotrans

[Ed McNierney]

Gerald et al. -

"If you want comments, look up the equations.  You'll see what is going
on then."

"All the above stuff should be in the manual and there is no point in
duplicating it in the code."

I've managed software developers for over 20 years, and anyone making
those claims to me would get a stern rebuke, and if made in an
employment interview, would guarantee the speaker to NOT get a job
offer.

It appears that the PROJ code is written in a style very much to
Gerald's liking.  This is hardly surprising.  It would be much more
helpful if relatively OBJECTIVE observers made comments on the value of
each body of code, particularly as it pertains to how it met their
needs.

Turning this into a belly-bumping contest does not help solve anyone's
problems.

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: (978) 251-4242  Fax: (978) 251-1396
ed at topozone.com


-----Original Message-----
From: Gerald I. Evenden [mailto:gerald.evenden at verizon.net] 
Sent: Sunday, March 30, 2003 10:45 AM
To: [OSRS-PROJ]
Subject: Re: [OSRS-PROJ] Proj.4 vs Geotrans

Sorry, I could not disagree more.  It may be fine for verbosity
in COBOL procedures designed for accountants and others not trained
in mathematics and not used to the concept of abstract symbols
but is has no place in mathematical code---which is what the
details of cartographic projections are all about.

If you want to know what is going on inside a projection you must
refer to the source document such as Snyder's "Map Projections---A
Working Manual."  Coding follows fairly closely the symbols in
the published equations.  Secondly, the code is written by a
mathematical programmer for a mathematical programmer,
one who is used to abstract symbols.

One important point I failed to mention is the ability for a
program to use multiple instances of an individual projection
executing at the same time in the same program.  For example,
two UTMs could be processing two different ellipsoids when
transfering one datum to another.  PROJ.4/libproj4 will do
that but Geotrans?  I doubt it.

A few more comments below.

On Sat, 2003-03-29 at 23:29, Paul Selormey wrote:
> Hello Gerald,
> I found your comments on the codes very interesting.
> I am particularly interested in the first one...
> 
> > 1) it looks like it was written by a COBOL instructor. VERY
> > verbose and full of VERY long identifiers.
> 
> I do not know if there is any rule on identifiers but using readable
> identifiers is quite useful in open sources, especially where
documentation
> is minimum.

Again, readable to whom?  Certainly not to me

> On the other hand, the single and double letter identifiers in the
Proj.4
> makes it very cryptic.

Again, are you familiar with the mathematics of a projection?  If you
were I think you would find the symbols understandable.

> I do not think many will have problem with method names like
> 
>   void Get_Mercator_Parameters(double *a,
>                                double *b,
>                                double *Origin_Latitude,
>                                double *Central_Meridian,
>                                double *False_Easting,
>                                double *False_Northing,
>                                double *Scale_Factor);
> 
> as found in the GeoTrans codes.

You failed your own philosophy.  The first two factors should read:

double *major_axis,
double *minor_axis,
 
> > For the Mercator projection Geotrans took 373 lines while
> > PJ_merc.c takes 80.
> 
> My copies of both libraries read GeoTrans: 380 vrs Proj4: 148, with
> more than half of the 380 lines being COMMENTS which is hardly found
> in the Proj4 files.

If you want comments, look up the equations.  You'll see what is going
on then.

BTW, about 27 of the 80 lines in PJ_merc.c are boilerplate comments
so the meaningful lines are only about 53 lines.  Libproj4 version.

> Typically, you find the comment for the above method as:
> 
> /*
>  * The function Get_Mercator_Parameters returns the current ellipsoid
>  * parameters, Mercator projection parameters, and scale factor.
>  *
>  *    a                 : Semi-major axis of ellipsoid, in meters
(output)
>  *    b                 : Semi-minor axis of ellipsoid, in meters
(output)
>  *    Origin_Latitude   : Latitude in radians at which the
(output)
>  *                          point scale factor is 1.0
>  *    Central_Meridian  : Longitude in radians at the center of
(output)
>  *                          the projection
>  *    False_Easting     : A coordinate value in meters assigned to the
>  *                          central meridian of the projection.
(output)
>  *    False_Northing    : A coordinate value in meters assigned to the
>  *                          origin latitude of the projection
(output)
>  *    Scale_Factor      : Multiplier which reduces distances in the
>  *                          projection to the actual distance on the
>  *                          ellipsoid
(output)
>  */
> 
All the above stuff should be in the manual and there is no point in
duplicating it in the code.

Another point here: why do we repeat this information over and over
in each projection when it is common to ALL projections.  PROJ.4 and
libproj4 recognize this and there is one common procedure that takes
care of these parameters prior to making an initialization call to 
the individual projection.

> I do not know why someone will not prefer this to the macros stuff in
the
> Proj4.

First of all, to each his own.  Secondly there are plenty of macros in
the Geotrans stuff---some pretty inane.

> Best regards,
> Paul.


----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.