[GRASS-user] gps import: definition of WGS84

[Hamish]

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


> And if not, which EPSG code would be the equivalent of the
> v.in.gpsbabel line ?

you can try modifying the v.in.gpsbabel script to use WGS84's epsg code if you like and see if you get a difference. what version of PROJ.4 do you use?


another test is to run v.in.gpsbabel into a wgs84 location, then use v.proj to project to your target projection, and see if it lines up exactly with the direct v.in.gpsbabel (with reprojection) way.


If you are only seeing error of a few meters, it may be that the maths of the reverse-projection used by the on-the-fly software is not the same in both directions. e.g. see the forward and reverse transform error given by the gis.m georeferencing tool.

If it is an error of approx 100m, I would expect that to be an incorrect  datum issue.

I would note that with current ArcGIS 9 on-the-fly reprojection that* datum shift is totally ignored and only reprojection is done, leading to badly incorrect results. Couple that with "user friendly" rubber sheet drag-and-drop georectifying to match the incorrect reprojection and you get a few wasted afternoons trying to figure out what the hell is going on.

[*] at least for our tests with the NZGD49 datum, no idea if it works with better tested datums like NAD27


Hamish