[GRASS-dev] Re: g.proj won't parse PROJ.4 string

GRASS GIS GRASS GIS developer
1

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

2

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

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.

This also not as easy as it sounds.

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.

Before doing this, can you take a look at the existing location wizard,
since it is about 90+% done and represents a big investment. Suggestions for
improvements are very welcome, but I'd be loathe to scrap the whole thing
unless there is very good reason to do so. I'm currently debugging it since
g.proj is not accepting the PROJ.4 strings it is creating, but they've got
to be close. All is otherwise working except extents.

Michael

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

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

3

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@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

4

Michael Barton wrote:

As a brief overview, the wizard does the following:

..

5. Create an XY location (this is not yet working because I'm not sure
what the best way to do this is).

as Paul suggested just write out the needed files for a simple XY
location, don't bother trying to do it as a projection. If you create an
XY location using the old way, you will notice there is no PROJ_UNITS
file created in PERMANENT/, only DEFAULT_WIND and MYNAME. So skip the
g.proj step for that altogether and just make the dir structure
yourself.

Hamish