[GRASS-dev] Re: more proj4 inconsistencies in g.proj

[Paul Kelly]

On Thu, 5 Jul 2007, Michael Barton wrote:

> Paul and Glyn,
>
> I've been tearing my hair out for 2 days over what I thought was a Python
> problem only to discover that it's another inconsistency with the projection
> information files--with ellipse.table again.
>
> For example, the line for wgs84 is...
>
> wgs84        "World Geodetic System 1984"    a=6378137.000
> f=1/298.257223563
>
> But for it to be read into g.proj in acceptable format, it needs to be...
>
> wgs84        "World Geodetic System 1984"    a=6378137.000
> rf=298.257223563
>
> That is, 1/298.257223563 needs to be 298.257223563
>
> Why is it 1/298.257223563? Is this correct in some kind of format acceptable
> to g.proj?

No idea. I suspect whoever was originally putting the State Plane support 
(which required PROJ) into GRASS in the early 90s got a bit confused and 
it's been like that ever since. Note that f=flattening, rf=reciprocal 
flattening. So f=1/xxx is obviously wrong but that's just the way it 
always has been in GRASS.

> Anyway, with this solved, the location wizard works for all except xy
> locations (suggestions on how to make?) and extents.

What about datum names? I suspect they aren't put into the PROJ_INFO? 
Like I said in an earlier e-mail, I really don't think using g.proj for 
the custom projections is going to be a long-term workable solution unless 
we add an option to g.proj to read a PROJ_INFO, PROJ_UNITS and WIND file 
outside of a GRASS location - in which case we'd still have to create 
those files manually from the GUI wizard, so why not do that directly? I 
think that will be easier.

Anyway I'm still working on my ideas for the GUI wizard (mostly based 
around what how it should logically progress to best emphasise the 
important concepts of GRASS locations to new users..) but I have to go 
away for a few days.. I'll get back to it next week though all being well.

Paul