[GRASS-dev] problems with datum parameters tables

Michael Barton michael.barton at asu.edu
Tue Oct 13 15:08:40 EDT 2009

On Oct 13, 2009, at 3:51 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Tue, 13 Oct 2009 02:18:32 -0700 (PDT)
> From: Hamish <hamish_b at yahoo.com>
> Subject: Re: [GRASS-dev] problems with datum parameters tables
> To: list GRASS developers <grass-dev at lists.osgeo.org>,  Michael Barton
>        <michael.barton at asu.edu>
> Message-ID: <230683.60053.qm at web110011.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=utf-8
> Michael Barton wrote:
>> I'm working on the GUI location
>> manager and have run into a couple of irregularities in a
>> couple of the projections parameters files. I'm sending this
>> to the list instead of keeping it in the location wizard
>> track ticket because they are a more general issue that will
>> affect projection/location creation by other means too.
>> In proj-parms.table, the entry for "GEOS" is incorrect.
>> There should be 3 subentries for each entry: projection
>> code, projection description, and required parameters.
>> However, GEOS is missing the projection description.
>> GEOS:HEIGH=ask,35800000.0;LON0=ask,20.0
>> The following entry has the correct format
>> GINS8:Ginsburg VIII (TsNIIGAiK):LAT0=ask,0.0;LON0=ask,20.0
>> GEOS is the only incorrect formatted entry in the file.
> That's the view-from-a-geostationary-satellite projection. (e.g.  
> Google
> Earth app zoomed way out from space)  I guess the missing name is a  
> typo.
>  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.

> It's a really neat one to reproject world wide datasets into.
> View of the Earth/Mars/Moon from space from any angle and any  
> distance.
> FWIW at those distances 100m offset from a datum probably ain't much  
> to
> worry about.

Sounds cool.

>> It also is NOT in the datums.table file.
> It shouldn't be. Generally speaking, projections and datums are  
> completely
> independent animals and can be mixed at will. Popular convention  
> means that
> in practice some datums are always used with some projections, but  
> that's
> not to satisfy the math, just history.
> I doubt any of the proj-*.table entries will be found in the  
> datum.table
> file, except perhaps as a footnote comment.

I meant to say that it is not in the projections file, not the  
datum.table file. 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.  
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?

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?

>> Also, in the proj-desc.table, several entries are
>> incorrectly formatted. None of them are used by the
>> proj-parms.table and so they probably should be removed from
>> the proj-desc.table file.
> IMO fixing is better than removing..
>> All are missing their description fields that are needed so that they
>> can be read by a user.
> I'm guessing the missing descriptions are due to lack of explanation
> of what they do by the person who made the table.
>> They are:
>> 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:
> the format looks ok as far as having the correct number of  
> delimiters, the
> only issue is that the description is an empty string. Parsing  
> should be
> made to deal with that, but descriptions should be found too.
> These terms are not unique to GRASS btw, they come from PROJ.4 or  
> prior.
> +guam has been around for a long while, you probably have to dig into
> the PROJ source code to see what they do exactly (or ask Gerald E).
> I've tried to document as many as I know about here:
>  https://trac.osgeo.org/proj/wiki/GenParms

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.

> Hamish
> ps- lest it be forgot, FYI currently we are completely ignoring  
> built-in State Plane support; currently those are only available via  
> the
> EPSG files and user knowing+entering custom +proj4 terms.

??? It is in the projections file and hence in the list of projections  
to choose from in the current location wizard.



More information about the grass-dev mailing list