[GRASS-dev] problems with datum parameters tables

Hamish hamish_b at yahoo.com
Wed Oct 14 00:30:56 EDT 2009

> > That's the view-from-a-geostationary-satellite projection.
> >  http://www.remotesensing.org/geotiff/proj_list/geos.html

> 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

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



More information about the grass-dev mailing list