> 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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
