Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#608 closed defect (fixed)

GIS.m: Lat/Lon support broken in Map Display zooms

Reported by: hamish Owned by: grass-dev@…
Priority: blocker Milestone: 6.4.0
Component: Tcl/Tk Version: svn-develbranch6
Keywords: gis.m, LL Cc:
CPU: All Platform: All



when in a lat/lon location the gis.m Map Display zooming is quite broken. Previously you'd get many "Error setting region: child process exited abnormally [ok]" popping up*, and if you zoom out to the global scale everything pretty much goes haywire.

[*] because g.region n=$mapcanvas_value>90

there's a partial fix in SVN now (r37285) -- it will switch into constrained mode if you try to zoom out beyond 90 degrees N,S. But it's not quite right, you still get white borders and the canvas coords get all messed up after that. I expect that besides switching to constrained mode it needs to either recalc the resolution after resetting N,S to 90, or just break out of the routine it's in because the premise for being there becomes invalid.

I've taken it about as far as I can go. ???


Change History (8)

comment:1 by cmbarton, 14 years ago

I'm not having any trouble with this using 6.4 compiled today (10 September 2009). I get a message about not being able to stay in "explore" mode if you zoom out beyond the poles. But I can still zoom out and in and get a map. No errors. The only oddity was that once I zoomed out beyond the poles and tried to zoom in with a box, it centered the display in the wrong place. If I just clicked, it zoomed in OK.

I'm doing this on a Mac.


comment:2 by hamish, 14 years ago

It will still be broken. (afaik no one has touched the code since I last did).

from memory: try with the etopo2 dataset or some 180E-180W, 90S-90N raster with a 15 degree d.grid overlay. adjust map box so you have white bands at the top and bottom. zoom in, then zoom out and back out to global view. compare the position shown on the status bar with what should be the value from the grid lines. you will notice it counts as pixels from the top of the map window, not from the bottom of the upper white >90N band.


comment:3 by cmbarton, 14 years ago

Thanks for the additional info. I'll try this specific test and see what happens.


comment:4 by cmbarton, 14 years ago

Cc: hamish_b@… added
Resolution: fixed
Status: newclosed
Version: 6.4.0 RCssvn-develbranch6

I think I've fixed this bug. Please test GRASS 6.5 svn R39213.

It does not crash and display and zooming work in both constrained and unconstrained ("explore") modes. If you try repeatedly to zoom out beyond the maximum latlon (i.e., beyond 90N or 90S), the behavior is unpredictable. But it gives a clean error when it can no longer handle zoom out beyond what is permissible.

Coordinates all seem to be accurate (i.e., the pointer seems to return the correct coordinate), and coordinates beyond 180E become West, and vice versa.

Please test. If it is satisfactory, it can be backported to 6.4.

Note that it seems that the wxpython display does not seem to suffer from the latlon zooming bug, but functions pretty much as the fixed TclTk GUI does now. That is, it is unpredictable if you try to zoom beyond the maximum latlon, but otherwise works fine.


comment:5 by hamish, 14 years ago

Cc: hamish_b@… removed

If you try repeatedly to zoom out beyond the maximum latlon (i.e., beyond 90N or 90S), the behavior is unpredictable.

mmmph. that's what I was trying to address with the if(y>90)y=90; stuff. Instead of that maybe it could just invoke pan mode or return with the same bounds as it started with?

Please test. If it is satisfactory, it can be backported to 6.4.

sure. I'm using the etopo2 dataset for testing. (see grass wiki global datasets page)

fyi- if you are the reporter or have commented to the bug report you are automatically added to the cc list. Also if adding to the cc list it is better to use the osgeo ID than full email addr, as exposing that just adds to the spam load..

thanks for taking this one on, Hamish

comment:6 by cmbarton, 14 years ago

Good to know about the cc'ing. I don't know your OSGEO ID. Is there a place to find this easily?

I wasn't very specific about what had changed in the zooming and will try to explain more here.

When I started (at least on my system), any zoom out or panning raised a g.region error. Full window ('explore') mode was turned off for latlon locations because it raised an error when you tried to load the map. EW coordinates could be far beyond 180 degrees.

Now, all coordinates seem correct. Full screen mode works as well as constrained mode (maybe a bit better). All zooming and panning works with the following 2 exceptions:

1) If you keep trying to zoom out beyond 90N, 90S, 180E, 180W with constrained mode (and maybe in full screen mode if you do it some more), it will produce a viewing region that is too small and the error "maximum zoom in limit exceeded" is raised.

2) If you zoom out beyond the max geographic coordinates more than once, the map view may not be what you were expecting (though I'm not sure what a user who keeps doing this IS expecting). That is, it may not be centered in the zoom out box, the displayed map may have an unexpected ht/width geometry, or it may even seem to zoom IN a little. This seems more pronounced in constrained mode than full-screen mode.

I do have it set to just pan if the map is at or attempts to go beyond the max zoom out. However, we don't want this to take effect until the max zoom out. So the slightest bit below the max coordinates and it goes back to "normal" behavior. I could just have it return to the previous bounds too, but it would still have the same issue. I'm assuming that sometimes the user will want the map to show the entire world (i.e., max zoomout) and might like it centered on different longitudes (i.e., other than 0 E/W) and have tried to preserve that possibility.

What seems to happen is that if you try to zoom out beyond bounds once, it behaves well (i.e., goes into pan mode an shifts the center to be in the zoom out box or at the pointer for one-click zoom out). If you keep doing this, it begins to behave erratically and, with constrained mode, eventually reaches a max zoom in error.

Hope that helps explain better where the functioning is at currently.


in reply to:  6 comment:7 by hamish, 14 years ago

Replying to cmbarton:

Good to know about the cc'ing. I don't know your OSGEO ID. Is there a place to find this easily?

Yup, and it's right under your nose :)

#608: GIS.m: Lat/Lon support broken in Map Display zooms
  Reporter:  hamish   |       Owner:  grass-dev
Comment (by cmbarton):

thanks for the thorough explanation of the new behavior. it sounds like it is just about there. More once I've had the chance to try it out.


comment:8 by cmbarton, 14 years ago


I guess I didn't get enough coffee this morning...

Let me know what you think of the fixes. I have an alternate idea for fixing this, but can't guarantee that it will give any better results, especially after looking at the behavior in the wx GUI. Zoom out beyond a width of 360 degrees is likely to always be squirrelly because the coordinates wrap back around a cylindrical earth map rather than extend in endlessly increasing/decreasing values as you expand east and west in a projection like UTM.


Note: See TracTickets for help on using tickets.