[GRASSLIST:1879] Re: Importing USGS SDTS DLG maps from differingdatums? I'm confused. [very long]

[Markus Neteler]

On Thu, May 24, 2001 at 09:58:43PM -0700, Eric G. Miller wrote:
> On Thu, May 24, 2001 at 09:50:22PM -0600, Roger S. Miller wrote:
> > Thanks for the insight, Eric.  I see you're right.  When pj_do_proj is
> > asked to convert lat-long to lat-long it simply returns an error.  It
> > doesn't check for the datum at all.
> > 
> > OK, I can accept that as a shortcoming in the code, but it's a pretty
> > big shortcoming when you consider what's going on in North America right
> > now.
> > 
> > Although it isn't necessarily a bug in the code, it's definitely a bug
> > in the documentation.  The user is prompted for the datum when he
> > creates a location and g.region shows the datum as part of the location
> > definition.  The documentation for v.proj says that the v.proj converts
> > between mapsets in different locations so I think most GRASS users will
> > logically assume that v.proj converts between different datums.
> > 
> > At a minimum the documentation needs to be changed.  Probably the code
> > should be changed to detect when a user is trying to convert between
> > datums and return an appropriate statement.
> > 
> > I have to wonder how many people have already used GRASS for that
> > conversion and now have erroneous data as a result.  I'm pretty sure
> > that I've done it.
> 
> I don't know how many, but Andreas only completed these changes late
> last fall / early winter.  Definitely a big sign in the documentation
> should say that datum transformations aren't handled.  Better to hack
> the projection routines, though I think there we'll have to make sure
> "coorconv" gets built before "proj".  I don't know how to determine
> which method should be used for datum transformation (usually
> 3-parameter, I guess).  We still don't carry NADCON files, so nad27 to
> nad83 will be less than ideal anyway. The "proj" distribution comes with
> a nad2nad utility, but it doesn't seem to be integrated.  I've packaged
> up a library from NIMA's GeoTrans calculator which would handle datum
> shifts rather transparently.  However, it doesn't use NADCON files
> either and I think the number of supported projections is more limiting
> (25, if I remember).
> 
> A while ago, a problem with state plane was brought up, and Morten and I
> discussed some major reorgs of the g.setproj as well as modifying some
> of the support routines (for instance, a datum implies an ellipsoid so
> the user shouldn't be bothered with both).  We agreed to hold off for
> 5.1 because there've been enough hold ups to getting 5.0 out.  
> 
> I would like to see GRASS adopt the EPSG system for identifying
> projections, datums, ellipsoid (and possibly entire coordinate systems)
> as this is used by GeoTIFF and a number of commercial vendors are also
> migrating to supporting this system.  Since each of those things has a
> numeric identifier it should be easy to do lookups quickly when needed.

Hi,

a short remark on the GRASS 5.0.0 and no (not yet) datum support:

At time GRASS 5.0.0 is using PROJ 4.3 software from USGS without datum
transformation support. I agree that the query for datum is confusing,
at least a hint needs to be added that this feature will be used from 5.1
onwards.

>From GRASS 5.1 onwards GRASS will use the latest PROJ 4.x software available
from http://www.remotesensing.org/proj/ maintained by Frank Warmerdam
including datum transform. As far as I know the "coorconv" library won't ne
necessary then as PROJ4.4.x already supports datum transforms (from the web
page: "Support has also been added for 3 and 7 parameter datum shifts").

Again, this is forthcoming for 5.1.

Regards

 Markus Neteler