[GRASS-user] gps import: definition of WGS84

[Moritz Lennert]

Thanks to everyone for their answers. I've tried all the different
suggestions and the answer seems to be clear: on-the-fly projection does
not work properly in QGIS and gvSIG... Whatever I do in GRASS, I always
get correct placement of the GPS data.

Using on-the-fly projection in the other programs, I get a difference of
about 100m, so I guess it's a datum issue as Hamish suggests.

Moritz

On Sat, May 24, 2008 05:05, 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.
>
>
>> 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
>
>
>
>
>
>
>