[GRASS-user] gps import: definition of WGS84
Moritz Lennert
mlennert at club.worldonline.be
Fri May 23 13:12:39 EDT 2008
On 23/05/08 18:45, Nikos Alexandris wrote:
> On Fri, 2008-05-23 at 18:39 +0200, Moritz Lennert wrote:
>> Hello,
>>
>> 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 <>
>>
>> ?
>
> Dear Moritz,
>
> I think the first definition is not complete. If the "+datum=WGS84"
> parameter was at least present it should be ok since a datum includes
> (or should include) all required information.
The "problem" is that it's the first that works.
To be more precise:
I have data in a GPS.
I have a raster topographic map of the area where the GPS data was
taken. This map is in ESPG 31370.
I create my EPSG 31370 location and use, import my raster and use
v.in.gpsbabel to import the gps data, not setting the proj= parameter.
The gps points and tracks are perfectly positioned compared to the topo map.
However, when I try to use QGIS (or gvSIG) with on-the-fly projection,
defining the projection of my tracks/points as EPSG 4326 (and I've tried
a few others), or as a custom projection defined as
+proj=longlat +towgs84=0.000,0.000,0.000 +ellps=WGS84
my topo map projection as 31370, and my project/view projection as
31370, I always see my GPS data several tens of meters off...
Moritz
More information about the grass-user
mailing list