[GRASS5] Fixing up projection related code...
paul-grass at stjohnspoint.co.uk
Mon Apr 7 12:05:08 EDT 2003
A little bit more of this is done now...
On Mon, 26 Aug 2002, Eric G. Miller wrote:
> I've been looking at some of the projection related code, and I'm
> trying to come up with a course of action to clean it up in places.
> Eventually, this should result in:
> 1. Having better defined projection files.
> 2. Creation of a set of predefined well known coordinate systems
> 3. A rewrite of g.setproj with these ideas in mind:
Not re-written yet, just fixed up a bit. Re-write with a GUI can go in
> - Types of coordinate system are XY, geographic, or projected
> - Ask users if they want to use a predefined coordinate
> system (state plane, UTM, others...) or if they want to
> define their own. Having a collection of predefined
> coordinate systems where the user can just pick it by
> "name", will simplify user's lives as well as insuring the
> info is correctly specified.
> - Both projected and geographic require datum/ellipsoid info.
> Ask for datum first, ellipsoid parameters can be looked up
> from it. Otherwise, just get ellipsoid parameters.
This is now mostly sorted out in the correct order
> - Remove state plane from projection list, it'll be covered
> by the predefined systems above (though still need units...)
> - Allow user defined datums??
This is possible; the PROJ.4 datum string (e.g. "towgs84=...") needs to be
> - Other...?
> 4. Have transparent handling for a variety of datum transformations
> incorporated into the library wrappers for proj4. Most of the
> necessary work for the transformations has been done by Andreas
> Lange, it's a matter of working in the strategies. Perhaps the
> programs can pass on a preferred stategy when specified by the
> user (for instance, NADCON vs. Bursa Wolf).
Anything possible with a parameter in the string passed to PROJ.4 can now
be used by including it in the 'datumparams: ...' line in the PROJ_INFO
file (or specify a custom datum in g.setproj). g.setproj can be re-run to
change the transformation parameters, though it would be wise to make a
copy of the current projection parameters by running g.projinfo first;
probably easier just to edit the PROJ_INFO file directly if you know the
parameters you want.
> Get rid of GRASS
> copy of proj4 and make a dependency on proj4 >= whatever version.
Today I have done this (well not get rid of the GRASS copy; I just made it
optional to use an external PROJ.4 library). This can be invoked by using
the --with-proj=yes option to the configure script and the usual
--with-proj-includes=... --with-proj-libs=... also apply if needed. It
needs to be PROJ.4.4.6 or later as the earlier versions had some bugs in the
The changes required to the modules that use proj were:
1. Include gprojects.h instead of projects.h
2. Include $(PROJINC) in the EXTRA_CFLAGS in the Gmakefile
I had to split the projects.h up into PROJ.4 internal stuff and bits
specific to the GRASS proj wrapper functions, and rename it so it wouldn't
conflict with an externally-installed copy of PROJ.4.
As far as I can see, under some circumstances a 'make clean' might be
needed, or maybe just delete the old libproj.a in src/libes/LIB.arch. The
library containing the GRASS proj wrapper functions is now called libgproj
instead of libproj, again so as not to conflict with the external version.
> It should be a fatal error if a datum transformation is impossible.
> 5. Miscellaneous:
> - Specify vertical datums? MSL, ellipsoid height, others... Mostly
> for documentation, since very few can be translated.
> - Add missing usfoot/usfeet <-> metric conversions. usinch? usmile?
> - Add prime meridian as datum parameter.
Frank said he didn't see this as an attribute of the datum, but of the
co-ordinate system, so I have left it for now.
> 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...
Frank thought it would be a good idea to put this into PROJ.4, also I
don't know how to do directory traversals, so I will forget about this
One point that will need to be emphasised (for American users I suppose)
when this work is incorporated into a release of GRASS: The last few releases
(5.0.0pre4 to 5.0.1 approx.) have, for the specific case of transforming NAD27
to NAD83 and vice versa, ignored the dx dy dz-style transformation parameters
given in the PROJ_INFO file and used the nadcon conversion tables. Under
the new 'improvements' the 3-parameter shift will be used if it is
specified in the PROJ_INFO file, and g.setproj will need to be re-run on
the location (or the PROJ_INFO file edited manually) to remove the dx dy
dz and add a 'datumparams: nadgrids=conus' line.
Hoping for some testing and feedback,
More information about the grass-dev