[GRASS5] Re: proj bugs

Paul Kelly paul-grass at stjohnspoint.co.uk
Thu Jul 17 15:12:58 EDT 2003


On Thu, 17 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....

> 
> No, the DEFAULT_WIND file didn't update at all. starting with a ll 
> 'proj: 3' location, running g.setproj to set a projection of nzmg, the
> DEFAULT_WIND file is not touched (the file's time stamp is unchanged).
> DEFAULT_WIND would need to translate n,s,e,w,e-w res,n-s res between 
> the DD:MM:SSh format and the UTM style ... slightly ugly.
> I guess that has to be done if there is any change at all, even just 
> transform params. Maybe do it and dump the user into the set bounds/res 
> curses screen so they are forced to double check that the resolution 
> isn't now 23.456789m or something ... ?? more ugly.

I tried this and it works for me. The region boundaries are stored in the
Cellhead structure and when the file is being written they are formatted
correctly depending on the projection.

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. I feel this should be enough to remind the
user to check his/her region boundaries. The code for this reminder was
already in g.setproj; it just wasn't being activated properly.

If you still have problems with the latest CVS, let me know.


> 
> Both PROJ_UNITS and PROJ_INFO are backed up to *~ and updated correctly.
> 
> While I can't imagine actually wanting to change type, someone undoubtedly
> will try it, get stuck, and start filing bug reports....
> Maybe just remove the ability to switch between proj types 1,2,3,4 with an 
> error message telling you to create a new location and use *.proj if you 
> want to do something that radical.
> 
> -=-
> 
> Another issue: can it list the transformation parameters without the user 
> having to type 'list' first[*], as there is no way to know which number 
> you want beforehand. Even if you remember what it was, it might change 
> without warning between versions. And if there is only one option just 
> use that with notification? (e.g. datum=wgs84, transform==1).  Maybe not 
> if you want to parse the answer to the transform params question for 
> 1, 3, or 7 inputs. [1 use the list, 3 or 7 prepend towgs84=]
>  ... but maybe that is introducing too much complication.

I have not been able to find a tidy solution to this so far.
The list is currently displayed using a G_system() call to the GRASS_PAGER
program (usually more or less depending on platform.) The message asking
the user to select a parameter set isn't included in the buffer passed to
the pager, so it would scroll off the top of the screen if the list of
parameter sets was longer than one screen and displayed without warning.
Typing 'list' to see a list of the choices is a consistent feature in the
GRASS user interface so I just did it like that when I couldn't see any
obvious improvement.

In general I think it is good to force the user to pick a set of
parameters, even if there is just one set. It should make him/her think
about what is being done and reinforce the idea that there is no 'default'
set of parameters for a datum (well arguably there is for WGS84 but that
is only because we are arbitrarily using it as the reference datum) and
the user must explicitly choose a set of transformation parameters that
suits his or her application.

But I'm very open to suggestions for improvement or to make it clearer.

Paul





More information about the grass-dev mailing list