Opened 13 years ago
Closed 8 years ago
#1500 closed defect (fixed)
g.region returns wrong convergence angle
Reported by: | annakrat | Owned by: | |
---|---|---|---|
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 by , 13 years ago
Component: | Default → Projections/Datums |
---|---|
Milestone: | → 7.0.0 |
follow-up: 3 comment:2 by , 13 years ago
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 by , 13 years ago
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 by , 12 years ago
Keywords: | g.region convergence → g.region, convergence |
---|---|
Milestone: | 7.0.0 → 6.4.4 |
Priority: | normal → major |
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 by , 8 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
follow-up: 7 comment:6 by , 8 years ago
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 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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!
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