[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