[GRASSLIST:1879] Re: Importing USGS SDTS DLG maps from
differingdatums? I'm confused. [very long]
neteler at geog.uni-hannover.de
Sat May 26 13:44:30 EDT 2001
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.
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
>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.
More information about the grass-user