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