Details Ticket 3172


Comment | Reply | Take | Open


Serial Number 3172
Subject d.where -l is giving wrong results
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Thu Jul 21 10:44:45 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Jul 21 10:44:45 2005 (3 yr ago)
Created Thu Apr 21 12:29:59 2005 (3 yr ago)

Transaction History Ticket 3172


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.
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request