No subject

in a program can be handled by allowing the old code to co-exist
during development and testing of a library based replacement. This
is the best alternative for users dependent upon the original
function.

Create a new name that best fits this projection procedure, migrate
the original code into a database/library, leave the original code
intact.  Once testing is completed, phase out the old code, and
perhaps create an alias name from the original name to the new name.

John Huddleston 

-----Original Message-----
From: grass5-admin at grass.itc.it [mailto:grass5-admin at grass.itc.it]On
Behalf Of Andreas Lange
Sent: Thursday, January 24, 2002 9:09 AM
To: Morten Hulden
Cc: Lee Wilson and Associates; grass5 at grass.itc.it
Subject: Re: [GRASS5] Projection transform


Morten Hulden wrote:
> 
> On Wed, 23 Jan 2002, Lee Wilson and Associates wrote:
...
> > Now g.setproj and m.proj don't even perform similar tasks.  g.setproj
> > lets the user set the projection information associated with a database
> > location and m.proj converts coordinates between different projections.
> > I guess I don't see much reason why these tasks should be merged.
> 
> Please don't misunderstand. I don't mean they should be merged. They
> _were_ merged, but there were obvious reasons to split them. Nevertheless,
> there is a lot of common code. Both use geo.h and geo_init.c, and main.c
> (in g.setproj) is very similar to process.c (in m.proj).
> 
> What I mean is they should be maintained in sync and common code should be
> put in a library. If g.setproj asks questions on datum settings, same
> questions should be asked in m.proj.
> 
> They perform different tasks, yes, but both programs generate proj-options
> based on user input and default settings for the projection in question.
> They differ in that g.setproj uses the settings to generate a PROJ_INFO
> file, while m.proj uses them directly to do a projection of a single
> point.

Hi all,

i have to underline what Morten said. 
The problem is that much of the projection setup is now hardcoded into
g.setproj.
For example, it is hardcoded into g.setproj that some projections have
fixed ellipsoids:
if ((proj_index == ALSK) || (proj_index == GS48) || (proj_index ==
GS50)) {
  sprintf(spheroid, "%s", "clark66");
...
}

This has to be hardcoded for obvious reasons into m.proj, too. 

This is very bad design. We need to implement a new database, which
contains projections, names, ellipsoids/spheroids, datum shift
parameters and all the dependencies. (it comes to my mind that this is
also a candidate for new library, as the key/value processing for the
etc tables is cloned several times in the gis libray code). 
Then we need to implement a set of library functions that manage/setup
all this and call the proj library for the actual processing. 

I am open to any ideas, 

Andreas

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net
_______________________________________________
grass5 mailing list
grass5 at grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5