Hamish wrote:
I'm trying to figure out why we are seeing different results when
importing GPS data into different software (GRASS is doing
great, it's the others that are having the trouble). It must be
linked to the definition of the projection the GPS data comes in.
v.in.gpsbabel defines the default projection as
IN_PROJ="+proj=longlat +towgs84=0.000,0.000,0.000"
Now my question: is this equivalent to EPSG 4326, which is
defined as
<4326> +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs <>
?
It is intended to be the same as GPSs use WGS84. With the changes to the latest version of PROJ.4 I
am not 100% sure that the semantics are not subtly changed for that. (issue of datum transform only
happens if datum is/is not present in both "to" and "from" projection
definitions; see the proj release notes + news for more on that)
I had /thought/ that the +towgs84= was enough to trigger a datum shift.
Folks,
I'm not sure what the implications are in this context, but any valid
PROJ.4 coordinate system ought to include the ellipsoid definition - either
directly or via the datum parameter. So if the coordinate system is
intended to be WGS84 I'd encourage it to be declared as
"+proj=latlong +datum=WGS84" rather than "+proj=latlong +towgs84=0,0,0".
In normal practice a default ellipsoid of WGS84 is used, and in combination
with +towgs84=0,0,0 this would be equivelent to +datum=WGS84 - but why
risk the defaults file not being found?
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
