[GRASSGUI] Re: g.proj won't parse PROJ.4 string

[Michael Barton]

I've got the location wizard working and making locations. I haven't
committed my newest changes because I'm having trouble with Python parsing
of the g.proj command.

The main way we are parsing commands is through a custom class cmd.Command.
However, this is choking on the g.proj proj4= command. It is probably
because of some of the characters, but I'm not getting any meaningful error
messages and so it is difficult to debug.

The simple os.popen works for datum strings, but won't parse ellipse strings
because it stops reading at the forward slash "/" in the f=1/nnnnn
parameter. I don't know why, since it's NOT a backslash.

I'm going to try subprocess.Popen (the Python command that underlies
cmd.Command), but haven't yet had a chance.

But the bottom line is that the wizard is now constructing valid PROJ.4
strings and passing them correctly to g.proj.

As a brief overview, the wizard does the following:

1. Create a location by choosing a projection (including latlon, not
technically a projection) and ellipse OR datum with transform parameters.
2. Create a location using EPSG code
3. Create a location using a georeferenced file
4. Create a location by entering your own PROJ.4 string
5. Create an XY location (this is not yet working because I'm not sure what
the best way to do this is).

I haven't messed with the extents yet.

Michael

I'm trying to make the location wizard actually create a location and, to my
surprise, it wouldn't parse a PROJ.4 string. There is not example of
inputting a PROJ.4 string in the docs, so I've done some experimentation and
found out why. Here is the PROJ.4 string created out of the values in
projection.table and ellipse.table
GRASS 6.3.cvs (spearfish60_test):~ > g.proj -c location=test1
proj4="+proj=ll +a=6378137.000 +f=1/298.257223563 +no_defs"
ERROR: Can't parse PROJ.4-style parameter string
For this to be accepted by PROJ.4, 'll' must be rewritten as 'longlat', and
the 'f=' parameter must be rewritten as 'rf='.
Did I just happen to find the 2 problematic spots in these files, or could
there be others? Do either of you happen to know where the GRASS format
differs from PROJ.4 in other places?

That's two of the main places - others are datum and ellipsoid names
although if you put them in numerical format as above the lib/proj code
should do it's best at extracting an alphanumeric ellipsoid name now. But
the datum names are still a problem.
In fact yes I've been thinking about this the last few days and realised
it would be a problem. Using g.proj in this way is more complicated than
it first appeared. It may be simpler to manually create the directories
(in Python) and write out the PROJ_INFO and PROJ_UNITS files directly.
Skeleton DEFAULT_WIND and WIND files would also have to put in too.
As I said I don't have a lot of time to devote to this but I'm working on
a proposal for how I think a location creation wizard should work (what is
included on each screen etc.) and when finished I will post it to the
list, in the hope that the thinking behind it will prove to be some help.
I'm doing it blind, i.e. without looking at what's there already in the
new GUI - hopefully we can then share the best ideas from both approaches.
Paul

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton