Opened 8 years ago

Closed 3 years ago

#1500 closed defect (fixed)

g.region returns wrong convergence angle

Reported by: annakrat Owned by: grass-dev@…
Priority: major Milestone: 6.4.6
Component: Projections/Datums Version: svn-trunk
Keywords: g.region, convergence Cc: grass-dev@…
CPU: Unspecified Platform: Unspecified

Description

When I run

g.region -n

in G7 in spearfish dataset, I get a nonsense and every time it's different value:

(Tue Nov 29 08:04:55 2011)                                                      
g.region -n                                                                     
convergence angle: -65.370921
(Tue Nov 29 08:04:55 2011) Command finished (0 sec)                             
(Tue Nov 29 08:04:58 2011)                                                      
g.region -n                                                                     
convergence angle: -112.346011
(Tue Nov 29 08:04:58 2011) Command finished (0 sec)                             
(Tue Nov 29 08:04:59 2011)                                                      
g.region -n                                                                     
convergence angle: -0.922875
(Tue Nov 29 08:04:59 2011) Command finished (0 sec)                             

When I switch to different location (nc_spm_08), it seems to be OK. In grass 6.5 it works (both locations).

Change History (7)

comment:1 Changed 8 years ago by hamish

Component: DefaultProjections/Datums
Milestone: 7.0.0

try g.region -d first.

if you are far out of the valid coordinates for a given CRS the math blows up. and the valid extent for any given CRS is undefined, although there are usually vague rules of thumb for how far outside you can go before the distortion gets too wild.

see #791

cpu? os? 32 or 64 bit? compiler version?

Hamish

comment:2 Changed 8 years ago by annakrat

Setting default region doesn't help. I have Ubuntu 10.04, 32 bit, gcc 4:4.4.3, proj 4.7.0-2

comment:3 in reply to:  2 Changed 8 years ago by hamish

Replying to annakrat:

Setting default region doesn't help. I have Ubuntu 10.04, 32 bit, gcc 4:4.4.3, proj 4.7.0-2

ok, just thought I'd check. when I was testing this earlier I wasted more than a bit of time having it fail in a new location with the default w=0 e=1 s=0 e=1 region. oops.

so I expect this report is a duplicate of #791, The valgrind log indicates that a variable (fact.conv?) may be being used uninitialized.

I just tried on ubuntu 10.04 64bit, proj 4.7.0-1--

  • official 6.4 package 6.4.0~rc5+39438-1build2: works
  • (a bit old) self-built 6.5svn: fails

debian/squeeze 64bit, proj 4.7.0-1--

  • official GRASS 6.4.0+42329 pkg: fails
  • self-built 6.4.2svn: works
  • self-built 6.5svn: works
  • self-built 7svn: works

Hamish

comment:4 Changed 6 years ago by hamish

Keywords: g.region convergenceg.region, convergence
Milestone: 7.0.06.4.4
Priority: normalmajor

still working for me in debian/squeeze 64bit, proj 4.7.0-1.

does not work for me on ubuntu 12.04 + self built 6.4.3svn packages + spearfish default region. (0.00000)

proj package is official ubuntu 4.7.0-1.

The valgrind log indicates that a variable (fact.conv?) may be being used uninitialized.

Hamish

comment:5 Changed 3 years ago by neteler

Milestone: 6.4.46.4.6

comment:6 Changed 3 years ago by olly

I suspect the bug here is due to fact not being initialised here:

https://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/printwindow.c#L488

I'd try changing that line to:

struct FACTORS fact = { 0 };

Or zero it out with memset() if you prefer.

If this function is called with previously unused stack space, you'll probably get "lucky" and fact will be zero initialised (which explains why hamish failed to reproduce this), but if the stack has been previously used, you'll get arbitrary values there, and likely different ones for each call.

I'm not a grass developer, or even a grass user, so I've not attempted to test this change in grass itself.

I'm actually just trying to calculate convergence using PROJ.4 in my own code. That's much harder than it ought to be due to the pj_factors() function not being in proj_api.h. Reading past discussion of that led me to this code in grass.

However testing the same approach in my code gave incorrect convergence values, and different ones for the same input coordinates and projection. Running under valgrind showed uninitialised data being used inside libproj. I have no debug symbols to hand for that so I couldn't see exactly where, but zero initialising the struct FACTORS cured the valgrind errors, and consistently gives me the correct convergence, so it seems pj_factors() expects that.

comment:7 in reply to:  6 Changed 3 years ago by annakrat

Resolution: fixed
Status: newclosed

Replying to olly:

I suspect the bug here is due to fact not being initialised here:

https://trac.osgeo.org/grass/browser/grass/trunk/general/g.region/printwindow.c#L488

Awesome! It does fix it indeed, committed in r68462 and backported in r68463. Thank you!

Note: See TracTickets for help on using tickets.