[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
> 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.

-- 
Eric G. Miller <egm2 at jps.net>




More information about the grass-user mailing list