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

[Paul Kelly]

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