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?
Anyway, with this solved, the location wizard works for all except xy locations (suggestions on how to make?) and 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
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