Thanks much for this information. I've got a start on rebuilding the
UTM page to show parameters of all projections. I've got the usual
formatting hangups (currently can't figure out how to clear the page
if you want to look at another projection), but it is moving along.
I agree that we should get this other stuff working and then look into
state plane. It may need some kind of enhancement to g.proj.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Oct 13, 2009, at 9:30 PM, Hamish wrote:
Hamish:
That's the view-from-a-geostationary-satellite projection.
http://www.remotesensing.org/geotiff/proj_list/geos.html
Michael:
Need to add this so that we can use it. If it has the wrong
number of parameters it won't be parsed correctly.
now fixed in SVN.
I meant to say that it is not in the projections file, not
the datum.table file.
oh, ok. fixed in devbr6 and trunk. no problem in 6.4, it will just
never be looked up.
But this brings up a related issue. Except for the missing GEOS
projection, it looks to me like all the information in the
projections
file is also contained in the proj-parms.table file.
(for those playing along at home this is $GISBASE/etc/projections,
see also general/g.setproj/README)
So it seems like we should be parsing the latter rather than the
former for getting projections. What is the point of the projections
file anyway if all the same stuff is in the proj-parms.table
file?
Use the etc/projections file as the master list. the g.setproj
proj-*.table files are lookup tables specifically to aid g.setproj,
but useful for reuse.
One difference is that projection codes are in caps in
proj-parms.table and in lower case in the projections file.
Does this make any difference when making a PROJ4 string?
see the g.setproj README file. they would need to be lower cased
for the string compare/lookup.
GUAM:bool:guam:
OALPHA:lat:o_alpha:
OLAT1:lat:o_lat_1:
OLAT2:lat:o_lat_2:
OLON1:lon:o_lon_1:
OLON2:lon:o_lon_2:
OLONC:lon:o_lon_c:
...
We will need the human readable description if we ever want
to use these parameters.
The description is what is presented to the user in order to get
him/her to input a value.
the o_ ones seems to come from the General Oblique Transformation code
in proj4 (PJ_ob_tran.c)
+guam seems to have to do with Azimuthal Equidistant's Guam elliptical
(PJ_aeqd.c)
... http://www.remotesensing.org/geotiff/proj_list/
?
currently we are completely ignoring GRASS's built-in State Plane
support;
...
??? It is in the projections file and hence in the list of
projections to choose from in the current location wizard.
State Plane is not a projection itself, it is the name of an index of
projections: there are 1~9 definitions per state. e.g. due to
latitude,
geographic extent, and shape, Alaska needs to use a radically
different
projection than Michigan, and another totally different projection is
needed for California etc. So 1st the user selects the 1927 or 1983
version of SP defn's, then they select their state, and finally they
choose the County code projection within that.
the county codes are listed in the $GISBASE/etc/FIPS.code file.
There is no +stp proj4 term, it is just an alias within GRASS to
tell it
to launch the interactive get_stp.c part of g.setproj.
note in the etc/projection list that ll, utm, and stp are grouped at
the
top before any of the "real" projections. (technically LL is
unprojected)
I see a bug in g.setproj getting stuck in a loop for the Virgin
Islands,
but I suggest to delay work on the SP stuff until after the main
datum and
real projection stuff is sorted out. Maybe just have that pop to an
error
message for SP saying to use the text version for now.
regards,
Hamish
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
