[GRASS-dev] problems with datum parameters tables

[Hamish]

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

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.


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


> 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


Hamish


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