Hamish pisze:
but they are incomplete! compare the entry for epsg:31370 in
/usr/share/proj/epsg and in /usr/share/qgis/resources/srs.sb (using
sqlitebrowser or such). you will see the srs.db version is missing
the +towgs84= part.
Definitely, it is a defect in QGIS srs.db. I have posted a scr
I have finally come around to looking at this issue again...
On Mon, May 26, 2008 05:01, Hamish wrote:
> Moritz Lennert:
> strictly speaking the "projection" (lcc) is there and fine, but (AFAIU)
> the datum transform params for a given datum are left out if there are
> more than one option in the
Moritz Lennert ha scritto:
I agree 100%. I'm not pleading for on-the-fly projection at all. However,
since I'm currently teaching a training course which also includes QGIS
and gvSIG, I also use that feature, but apparently I'd better not !
agreed: same experience for me, here in Evora.
pc
___
Moritz Lennert:
> I don't have the feeling that either 4326 or 31370
> offer multiple possibilities for transform parameters,
> but don't know for 100% sure.
no, they don't. LL WGS84 is just that (as long as we consider it the root
coordinate system), and 31370 explicitly gives 7 term +towgs84= p
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 plac
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 b
On Sun, May 25, 2008 12:47, Nikos Alexandris wrote:
> On Sun, 2008-05-25 at 12:43 +0200, Moritz Lennert wrote:
>> 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...
On Sun, 2008-05-25 at 12:43 +0200, Moritz Lennert wrote:
> 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
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 progra
Frank:
> I'm not sure what the implications are in this context,
> but any valid PROJ.4 coordinate system ought to include
> the ellipsoid definition - either directly or via the
> datum parameter. So if the coordinate system is
> intended to be WGS84 I'd encourage it to be declared as
> "+proj=la
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
> 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 defa
Hi all,
In settings -> options -> projection, try to set "prompt for projection" and
select the desired projection (define a custum one, if you prefer) every
time you import points (or whatever) using gpsbabel. Probably you set to use
a projection (different from the one defined with gpsbabel) as
On 5/23/08 10:38 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Date: Fri, 23 May 2008 19:12:39 +0200
> From: Moritz Lennert <[EMAIL PROTECTED]>
> Subject: Re: [GRASS-user] gps import: definition of WGS84
> To: Nikos Alexandris <[EMAIL PROTECT
On Fri, 2008-05-23 at 19:12 +0200, Moritz Lennert wrote:
> 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,
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
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 th
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 defa
18 matches
Mail list logo
