[GRASS5] Re: proj bugs

[Paul Kelly]

On Tue, 22 Jul 2003, H Bowman wrote:

> > > > I think the changes I made in the last few days may have fixed the
> > > > biggest bugs in g.setproj. But you also need to check the
> > > > generated DEFAULT_WIND file. It should have proj: 3 for lat/long
> > > > and proj: 99 for nzmg or most projected systems (this determines
> > > > the return value from G_projection() ).
> > > 
> > > [running 5.0 CVS from 2 weeks ago]
> > 
> > It might have been less than 2 weeks ago that I fixed this....
> 
> Ok, I'm trying with a freshly checked out 5.0 CVS tree now.
> Still, DEFAULT_WIND doesn't want to update.
> (ll -> nzmg projection, same datum)

I have added a check for a return value so it will stop if it cannot write
the DEFAULT_WIND file. But it works fine for me and I really don't know
what is wrong here. Maybe someone else could test:
When changing projection to or from lat/long, UTM or state plane, the
DEFAULT_WIND file should always be updated as well as PROJ_INFO and
PROJ_UNITS.

> > On completion of g.setproj if the projection type has been changed,
> > you should see a message asking you to run 'g.region -d' to update the
> > current region from the default region.
> 
> Yes, I see that. Would it be better to ask (y/n) [y] to run that automatically?
> Unfortunately as DEFAULT_WIND isn't changing, the new WIND is just updated to 
> the old values. (see below)

Possibly but I feel if I make a lot of small cosmetic changes to g.setproj
people will start expecting the rest of the program to be perfect, when
really it needs to be totally re-written both to be GUI-friendly and
internally consistent. But we can wait until the future direction of the
PROJ library is clearer before making a start on this.

> Can the following line be shortened or split so it is shorter than 80
> characters? I think putting the (y/n) on the next line would do it.
> Would you want to change the datum (or the datum transformation parameters)?(y/n) [n] y

Done.

Paul