[GRASSLIST:1874] Re: Importing USGS SDTS DLG maps from
differingdatums? I'm confused. [very long]
Eric G. Miller
egm2 at jps.net
Fri May 25 00:58:43 EDT 2001
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
> 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.
Eric G. Miller <egm2 at jps.net>
More information about the grass-user