ellipsoid names

[Gerald I. Evenden]

>Date: Thu, 16 Jun 94 09:05:03 CDT
>From: jschuler at ncg.scs.ag.gov (Jill Schuler)
>To: grassu-list at max.cecer.army.mil
>Subject: Re: ellipsoid names
>Cc: ekoster at let.rug.nl, gie at charon.er.usgs.gov

	...

>Jerry,
>I realize that YOUR ellipsoid table is the MOST ACCURATE.  HOWEVER,  my task
>was to make GRASS work with MAPGEN.  I pointed out the conflict with ellipsoid
>names to my superiors --- and it went nowhere.  My only solution was to 
>duplicate your information with the ellipsoid names used in GRASS.  

Accuracy is not an issue here and in the cases I checked, the numbers
are the same anyway.

>Obviously the BEST solution would be to have GRASS USE YOUR ELLIPSOID NAMES.
>I have no control over this!  This is a CERL decision.
>
>I DID NOT REMOVE YOUR INFORMATION, I only duplicated the necessary GRASS
>ellipsoid names.  From your response you view this as unnecessary.  

Noted.

>In a previous message to this list, I pointed out the inconpatibility of GRASS 
>ellipsoid names with MAPGEN's.  I recommended that GRASS use your table.  
>So until CERL decides to conform to MAPGEN's list for every new release to proj the ellipsoid table will be edited with GRASS's version of ellipsoid names.
>
>Maybe if you request that GRASS conform to your ellipsoid names you can get
>CERL to change-----Maybe?
>
>So next time before you flame someone,  please consider the circumstances!
>If you want to discuss this give me a call.
>
>Jill

First, it is perfectly appropriate for CERL to have their own acronymic
set for ellipsoid identifiers and I appologize for not putting a
smiley beside my comment alluding to name length.  I felt my alternate
preference for UNIX style brevity contrasting the long keyword choices
was self evident.

The main problem that I see is the modification of source code in
order to achieve something that could have been better done by other,
less intrusive, mechanisms.  I pointed out some of the problems in
another email message.  A better way might be to use an init file
containing:

# CERL ellipsoids
<international>
ellps=intl
<>
<clarke66>
ellps=clrk66
<>
<UTM-international>
ellps=intl
proj=utm
no_defs
<>
# and so forth.

Thus an execution of *proj* might look like:

proj +proj=utm +lon_0=-75 +init=CERL:international

proj +init=CERL:UTM-international +zone=19

Of course, many other projection parameters can also be included
in this file.  The main thing is that you do not have to hack the
source code.  It would have been far more clearer to a non GRASSer
as to what was going on even without knowing what was in the CERL file.

The main reason that I provide the +init feature is just for this
kind of non-intrusive custimization.

Hacking up a code distribution is a perilous activity that should
only be done only when all alternatives have been exhausted.  It adds
a complex burden of trying to maintain these "patches" with new
releases.

I would also like to hear from users any suggestions that would
improve these types of operations.  It is the way many of the
*proj* features have evolved.

Lastly, my previous comments were not a flame, but a loud groan.

Gerald (Jerry) I. Evenden   Internet: gie at charon.er.usgs.gov
voice: (508)563-6766          Postal: P.O. Box 1027
  fax: (508)457-2310                  N.Falmouth, MA 02556-1027