[GRASS-user] gps import: definition of WGS84

[Frank Warmerdam]

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, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org