[GRASS-user] gps import: definition of WGS84
michael.barton at asu.edu
Fri May 23 14:09:17 EDT 2008
On 5/23/08 10:38 AM, "grass-user-request at lists.osgeo.org"
<grass-user-request at lists.osgeo.org> wrote:
> Date: Fri, 23 May 2008 19:12:39 +0200
> From: Moritz Lennert <mlennert at club.worldonline.be>
> Subject: Re: [GRASS-user] gps import: definition of WGS84
> To: Nikos Alexandris <nikos.alexandris at felis.uni-freiburg.de>
> Cc: grass-user at lists.osgeo.org
> Message-ID: <4836FB07.6060402 at club.worldonline.be>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> On 23/05/08 18:45, Nikos Alexandris wrote:
>> On Fri, 2008-05-23 at 18:39 +0200, Moritz Lennert 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 <>
>> 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,
My bet is that this is the problem. We've had regular requests to implement
on-the-fly projection in GRASS but have not done it so far. It is
convenient, but tends to have errors that don't show up until you actually
try to do something that requires precise rectification and overlays. This
means that, unless you have something to compare it with, you can have
errors and not know it.
> 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...
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
More information about the grass-user