[GRASS-dev] problems with datum parameters tables

[Michael Barton]

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