[GRASS-dev] 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 


On 7/4/07 3:26 PM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> On Wed, 4 Jul 2007, Michael Barton wrote:
> 
>> 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: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton