[GRASS-dev] reading georeferencing tables for GRASS

Glynn Clements glynn at gclements.plus.com
Sun Jul 1 23:26:14 EDT 2007


Michael Barton wrote:

> I'm ready to move ahead and try to create PROJ.4 strings in the wxgrass
> location wizard, but am confused about the parameters tables in
> $GISBASE/etc.
> 
> It looks kind of like proj-params.table and maybe proj-units.table are the
> files used by g.setproj.

Yes. These files contain data which was previously hard-coded in
lib/gis/geo_init.c. They determine the set of available projections,
along with the parameters will be prompted for when you select a
particular projection.

> and that the others (datum.table,
> datumtranform.table, ellipse.table, and projections) are there to help
> create a PROJ.4 string for GRASS. Is this correct?

At least datum.table and ellipse.table are used by libgis functions
which don't require proj, e.g. G_get_datum_by_name() and
G_get_ellipsoid_by_name().

> If this is the case, I'm not quite sure how to use these.

All of the tables essentially describe choices which are made by the
user.

> The datumtransforms.table seems the most straightforward--just search for
> the line with a projection that matches the location projection and read of
> the datum transformation parameters ("towgs84=24,-130,-92") as a single
> PROJ.4 string to add on to the PROJ.4 string of the location projection.

The first column of datumtransform.table is a datum name. Many datums
have multiple entries (e.g. nad27 has 9 entries). The idea is to
select all entries matching the desired datum, display a list of the
corresponding names and/or descriptions (columns 3 and 4) to the user,
then use the PROJ string (column 2) for the entry which the user
selects.

> I do use projections? That is, choose the projection code that is
> appropriate for the description that I want.

Display the descriptions (column 2) to the users, record the
GRASS/PROJ code (column 1) for the entry which the user selects.

> the datum.table and ellipse.table are more confusing. The datum table seems
> to include ellipsoids, but only a subset and does not include the ellipsoid
> parameters. I can look up the ellipsoid in the ellipse.table file that
> matches the ellipsoid in the datum.table file and grab the ellipsoid
> parameters. But what about all the ellipsoids that are not in the
> datum.table file? Can they be used?

The user can choose to use an ellipsoid without choosing a datum. If a
datum is chosen, then the ellipsoid is determined by the datum; if no
datum is chosen, the ellipsoid must be chosen manually.

Also, the user could choose a named ellipsoid along with a custom
datum (i.e. a 3- or 7-parameter transform specified by its
coefficients), or a custom ellipsoid specified by its equatorial axis
and either the polar axis, flattening, or eccentricity-squared with
either a custom datum or no datum.

> It seems that, hypothetically, you could use a different ellipsoid with a
> datum besides the one associated with it in the datum.table file. But I
> don't know why those particular ellipsoids are in the datum.table file. Are
> these simply the most common for that datum or do I *need* to use the
> ellipsoid associated with that datum?

AFAIK, it doesn't make any sense to use an ellipsoid other than the
one associated with the datum.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list