Thu, Apr 21 2005
12:29:59
|
|
Request created by guest
|
|
Subject: d.where -l is giving wrong results
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: grass61_13_04_05_1052
Seems a serious one but I didn't dare to "critical" it.
I have a following mapset:
GRASS 6.1.cvs (caves_utm33):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name : Universe Transverse Mercator
proj : utm
datum : wgs84
a : 6378137
es : 0.0066943800
zone : 33
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : metre
units : metres
meters : 1
GRASS 6.1.cvs (caves_utm33):~ > g.region -p
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: a=6378137 es=0.00669438
north: 5724924
south: 5724724
west: 572360
east: 572688
nsres: 1
ewres: 1
rows: 200
cols: 328
When query point's coordinates with d.where, I'm getting different results whether
switch -l or -w is used:
d.where -l
EAST: NORTH: LON: LAT:
572500.425 5724830.725 16:02:54.226371E 51:40:11.746412N
d.where -w
WGS84 Co-ordinates
EAST: NORTH: LON: LAT:
572500.425 5724830.725 16:02:54.226371E 51:40:11.179813N
It looks that "-l" is wrong, because cs2cs gives the same as "-w":
trawiarz@quercus trawiarz]$ echo "572500.425 5724830.725" | cs2cs +proj=utm +zone=33
+to +proj=latlong +ellps=WGS84
16d2'54.226"E 51d40'11.18"N 0.000
That's quite a difference: 17.51m N and 0.25m E.
Maciek |
|
Wed, May 11 2005
15:16:15
|
|
Comments added by msieczka
|
|
Cc: grass5@grass.itc.it
Folks
Nobody has answered on this bug. Is it really neglectable you think? Whos is
taking care of d.where?
Cheers |
|
Thu, May 12 2005
17:23:03
|
|
Mail sent by paul-grass@stjohnspoint.co.uk
|
|
Return-Path |
<paul-grass@stjohnspoint.co.uk>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 12 May 2005 16:22:53 +0100 (BST)
|
From |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3172] (grass) d.where -l is giving wrong results
|
In-Reply-To |
<20050511131615.C7F331005D2@lists.intevation.de>
|
Message-ID |
<Pine.LNX.4.60.0505121618240.10374@agrippa.ukshells.co.uk>
|
References |
<20050511131615.C7F331005D2@lists.intevation.de>
|
MIME-Version |
1.0
|
Content-Type |
TEXT/PLAIN; charset=US-ASCII; format=flowed
|
X-SA-Do-Not-Run |
Yes
|
X-SA-Exim-Connect-IP |
217.10.143.90
|
X-SA-Exim-Mail-From |
paul-grass@stjohnspoint.co.uk
|
X-SA-Exim-Scanned |
No (on customer-relay-1.mail.uksolutions.net); SAEximRunCond expanded to false
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
I read it before and it does sound like a bug, but there wasn't enough
information in the bug report for me to see what was wrong. It would be
good if you could drill it down to a single test point working with cs2cs
and reproduce the results that way. Should be easy to fix then.
Another thing to try (if you still have GRASS 5.4 around) is to try
separately with --without-proj and --with-proj options to the configure
script. The built-in proj in GRASS does things a little bit differently
from remotesensing.org proj with regards to interpreting datum paramters
as part of a co-ordinate system (i.e. it tries to ignore them if they are
only specified as part of one of the co-ordinate systems being projected
from/to).
Paul
On Wed, 11 May 2005, Maciek Sieczka via RT wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3172
>
> Request number 3172 was commented on by 'msieczka' (Maciek Sieczka).
> Responding to this message will send mail to the requestor.
>
> Request Tracker
> rt@intevation.de
>
> --------------------------------------------------------------
> Cc: grass5@grass.itc.it
>
> Folks
>
> Nobody has answered on this bug. Is it really neglectable you think? Whos is
> taking care of d.where?
>
> Cheers
>
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
|
|
Fri, May 13 2005
12:17:18
|
|
Mail sent by werchowyna@epf.pl
|
|
Return-Path |
<werchowyna@epf.pl>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<00b001c557a5$02bb3210$cee41d3e@eustahiush>
|
From |
"Maciek Sieczka" <werchowyna@epf.pl>
|
To |
"Paul Kelly" <paul-grass@stjohnspoint.co.uk>, "Maciek Sieczka via RT" <grass-bugs@intevation.de>
|
Cc |
<grass5@grass.itc.it>
|
References |
<20050511131615.C7F331005D2@lists.intevation.de> <Pine.LNX.4.60.0505121618240.10374@agrippa.ukshells.co.uk>
|
Subject |
Re: [GRASS5] [bug #3172] (grass) d.where -l is giving wrong results
|
Date |
Fri, 13 May 2005 11:56:48 +0200
|
MIME-Version |
1.0
|
Content-Type |
text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
|
Content-Transfer-Encoding |
7bit
|
X-Priority |
3
|
X-MSMail-Priority |
Normal
|
X-Mailer |
Microsoft Outlook Express 6.00.2900.2180
|
X-MimeOLE |
Produced By Microsoft MimeOLE V6.00.2900.2180
|
X-Antivirus |
avast! (VPS 0518-4, 2005-05-06), Outbound message
|
X-Antivirus-Status |
Clean
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
From: "Paul Kelly" <paul-grass@stjohnspoint.co.uk>
>I read it before and it does sound like a bug, but there wasn't enough
>information in the bug report for me to see what was wrong. It would be
>good if you could drill it down to a single test point working with cs2cs
>and reproduce the results that way.
But I did... In the bug report there *is* a comparison with the results from
cs2cs. As you can see the E coordinate is the same in all 3 cases
("d.where -l", "d.where -w" and cs2cs) but in regard to N "d.where -w" and
cs2cs are different from "d.where -l".
> Should be easy to fix then.
> Another thing to try (if you still have GRASS 5.4 around) is to try
> separately with --without-proj and --with-proj options to the configure
> script. The built-in proj in GRASS does things a little bit differently
> from remotesensing.org proj with regards to interpreting datum paramters
> as part of a co-ordinate system (i.e. it tries to ignore them if they are
> only specified as part of one of the co-ordinate systems being projected
> from/to).
I migrated to grass6 for good but if you decide it is critical to test the
problem in 5.4 I can do it next week.
siema
Maciek
|
|
Sat, Jul 2 2005
17:25:19
|
|
Comments added by pkelly
|
|
Cc: grass5@grass.itc.it
There definitely is a bug in there somewhere (and it may be 6.x-specific
rather than PROJ version-specific; I haven't been able to re-produce it in
5.4). d.where uses the PROJ function pj_latlong_from_proj() to convert from
the UTM projection definition to a latlong definition on the same ellipsoid.
This function is returning a value of es (eccentricity squared) with a very
low precision, only a few decimal places, and that seems to be what is
causing the error. I still haven't tracked down what is causing the low
number of decimal places.
Adding a call to pj_print_proj_params(&iproj, &oproj) before the pj_do_proj
line in display/d.where/where.c is helping to track this down.
|
|
Tue, Jul 5 2005
01:27:11
|
|
Comments added by pkelly
|
|
Cc: grass5@grass.itc.it
I am beginning to think the bug may be in PROJ.
Try editing line 118 in src/pj_utils.c in the PROJ.4.4.9 distribution to
change the precision of the es value from " +es=%.4f" to, say, " +es=%.16f"
Does that make a difference? I can't test thoroughly right now but will try
to do so in a day or two.
|
|
Wed, Jul 6 2005
16:03:03
|
|
Comments added by fwarmerdam
|
|
Paul created:
http://bugzilla.remotesensing.org/show_bug.cgi?id=881
I have applied his suggested patch upstream, and closed my copy of
the bug.
I'm not sure how long it will be till a new PROJ.4 release is made
with the fix.
|
|
Sun, Jul 10 2005
22:24:53
|
|
Comments added by pkelly
|
|
Cc: grass5@grass.itc.it
There definitely is a bug in there somewhere (and it may be 6.x-specific
rather than PROJ version-specific; I haven't been able to re-produce it in
5.4). d.where uses the PROJ function pj_latlong_from_proj() to convert from
the UTM projection definition to a latlong definition on the same ellipsoid.
This function is returning a value of es (eccentricity squared) with a very
low precision, only a few decimal places, and that seems to be what is
causing the error. I still haven't tracked down what is causing the low
number of decimal places.
Adding a call to pj_print_proj_params(&iproj, &oproj) before the pj_do_proj
line in display/d.where/where.c is helping to track this down.
|
|
Tue, Jul 19 2005
23:13:31
|
|
Mail sent by mneteler
|
|
Hi,
what about adding
G_debug(x,"...y",z);
here and there to understand what's ongoing?
Since Maciek insists this delays 6.0.1 release.
Markus |
|
Thu, Jul 21 2005
10:37:32
|
|
Mail sent by guest
|
|
Markus,
With proj cvs 15.07.05 this bug doesn't apply anymore. It seems proj was
guilty and Paul's patch got applied by Frank and fixed that (see Frank's
comment from Wed, Jul 6 2005 16:03:03). Or do you mean to change "d.where -l"
so that it could cope with release proj 4.4.9 as well?
Paul,
On http://intevation.de/rt/webrt?serial_num=3172&display=History
there are two identical messages from you:
Sat, Jul 2 2005 17:25:19
Sun, Jul 10 2005 22:24:53
What do you mean?
Maciek |
|
Thu, Jul 21 2005
10:42:17
|
|
Status changed to resolved by pkelly
|
|
Thu, Jul 21 2005
10:44:45
|
|
Mail sent by pkelly
|
|
Yes the bug is fixed (was not in GRASS).
Sorry for the confusion; I had too many web browser windows open on two many
computers and refreshed one that had been open for over a week, resulting in
it posting that message again.
|
|