[OSRS-PROJ] Re: [GRASS5] Fixing up projection related code...

[Frank Warmerdam]

Paul Kelly wrote:
> This is what I have chosen to go for, implementing a new file
> ('datumtransform.table') which can contain multiple entries for each
> datum. There are 4 fields: datum name, transformation parameters in PROJ.4
> syntax, "Where Used" and "Comment". The last two fields should be
> descriptive and help the user to pick the appropriate parameters.
> 
> It doesn't really make sense the way it is partially currently implemented
> in GRASS, to look up a 3-parameter transform from the datum.table and
> just use it, because as Frank said each datum may have many different
> tranformations associated with it and GRASS shouldn't pretend to be able to
> choose the best one for the user when really it needs a human making the
> decision. E.g. someone might want to use an old or custom set of parameters
> simply for compatibility with existing data.
> 
> So after selection, the datum transformation parameters will be stored in
> the PROJ_INFO file under the new key 'datumparams'.
> E.g. 'datumparams: towgs84=a,b,c' will be equivalent to the old
> 'dx: a' 'dy: b' and 'dz: c'. The pj_get_kv() wrapper function will still
> interpret the old style properly but g.setproj will only write new-style
> PROJ_INFO files.

Paul,

Do correctly understand then that each named datum in the datumtransform
table will have a *default* transformation to use with the datum, but that
by explicitly including the transformation in the PROJ_INFO file it is
intended to be easy for users to alter what transformation values are used?

> Regarding passing ellipsoid and datum names onto PROJ.4, this will only be
> done if GRASS doesn't recognise the names from its own ellipse.table and
> datum.table files. Otherwise the underlying parameters will be passed on
> but not the names. This will probably solve bug 1047 with the problem with
> the PROJ_INFO files r.in.gdal automatically creates but I will have a look
> at it soon as well.

Right.  I would add that there is a pj_get_def() function in PROJ.4 which can
be used to get an "expanded" definition of a PROJ.4 coordinate system string.
For instance, it will expand a +datum= into the actual transformation values
that would be used with it.  This is intended to be useful for applications
that want to find out the magic in certain coordinate system definitions.
This also could be used to fetch back details from lookups from the various
"cookbook" coordinate system files, like the state plane ones, and the EPSG
database.

>>I do think that import programs that report projection information, or
>>offer to setup new locations (like r.in.gdal) should offer the transformation
>>used if possible.
>
> I don't really think that programs that import data should try to
> reproject it. This is getting too complicated and then there would be too
> many modules to try to keep up to date. The conventional GRASS way seems
> to be to import the data into a location with the correct projection, then
> reproject it to your target location using [rsv].proj.

I meant that an import program like r.in.gdal should be able to associate
particular datum shift transformation information with the dataset.  That is
if it knows that a non-default datum shift should be used it could populate
the PROJ_INFO file with it.  This would seem to be very easy with your
approach.

> Some points I would appreciate if people could comment on:
> As far as I can make out a datum has a one-to-many relationship with datum
> transformations, and one-to-one with ellipsoid and prime meridian. Neither
> the datum lists in GRASS nor PROJ.4 include space for an associated prime
> meridian so I'm wondering is this correct. I would like to make the GRASS
> format as correct as possible. Probably I should investigate how PROJ.4
> uses prime meridians but I don't really have that much spare time at the
> minute and would appreciate a hint.

I don't see the prime meridian as an attribute of the datum, though it is
an attribute of a geographic coordinate system based on the datum.  That is,
I think the prime meridian handling is orthagonal to the datum shift info.

>>That info should be in the PROJ_INFO file, IMHO.  Anyway, I thought
>>we could have a Coordinate_System directory that g.setproj could
>>use.  So far, with my state plane files, I have something like:
>>
>>Coordinate_Systems/
>>   Projected/
>>      North_American/
>>         State_Plane_1927/
>>            State_Plane_Alabama_East
>>            State_Plane_Alabama_West
>>            ...
>>            State_Plane_Wyoming_West_Central
>>         State_Plane_1983/
>>            ...
>>
>>This kind of thing is easy enough to add to, and g.setproj could
>>just use directory traversals until the user selects a file, then
>>just copy the file to the new location...
> 
> 
> This sounds like a good idea but what are directory traversals and how
> should they be implemented in g.setproj? There should be a GUI version as
> well to make it look user-friendly and nice as g.setproj is a lot of
> people's first encounter with a GRASS command (mine anyway and I spent
> days over it) and it is really a terrible piece of software and very
> off-putting. Is it all right to use Tcl/Tk in GRASS 5.1 or will there be
> a different GUI?

I agree that some degree of categorization of coordinate system definitions
would be desirable.  In many systems I have looked at there is really just
one level of categorization, but each pre-defined coordinate system can be
part of more than one group.  So the groups might include:

   Common
   NAD27 State Plane
   NAD83 State Plane
   European
   North American
   EPSG Projected Coordinate Systems
   EPSG Geographic Coordinate Systems

and so on.

Some coordinate systems might appear in several groupings.  If something like
this is built, I would ideally like to see it implemented within PROJ.4, so
that other systems could easily take advantage of it.  If done within PROJ.4,
one approach would be to use each "initialization" file as a group, and add
a mechanism to supply some of the auxilary information with each coordinate
system.  The existing EPSG, and state plane files would be a good start.

I am cc:ing this to the PROJ.4 list for possible additional comment.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent


----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.