[GRASS-user] gps import: definition of WGS84

[Moritz Lennert]

On Sun, May 25, 2008 15:16, Hamish wrote:
> 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.
>
> This seems to be QGIS bug # 1079
>   http://trac.osgeo.org/qgis/ticket/1079
>
> (usual suspects reporting in :)
>
>
>> 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.
>
> It would seem so. I can reproduce it here (see bug report). In my case
> looking in the layer's "P"roperies projection tab I see the the +datum=
> and/or +towgs84= terms are  missing* versus what is found in the EPSG
> file.
>
> [*] file: /usr/share/qgis/resources/srs.db (SQLite DB)
>
> Root cause seems to be that QGIS lacks a "pick appropriate datum transform
> parameters to use" GUI in the case when there are multiple possibilities,
> and so it doesn't try any datum transform at all:
> http://www.nabble.com/why-is-EPSG%3A2180-not-recognised--td16505409.html#a16592790

Thanks for following up on this.

I don't have the feeling that either 4326 or 31370 offer multiple
possibilities for transform parameters, but don't know for 100% sure. But
the way I read the above nabble thread (and especially Frank's quote) the
issue is that some projections are missing in the proj and thus the QGIS
database because of the multiple transform possibilities (so when you use
the default proj epsg file in GRASS the same problem probably applies).
However both of the projections _are_ in the database and QGIS recognizes
them.

So, I'm not sure whether this is an issue with the epsg codes, or rather a
problem with the transformation code.

But I think it's time to take this over to the relevant QGIS and gvSIG
(which has the same problem) mailing lists...

Moritz