[QGIS-trac] Re: [Quantum GIS] #1716: improvements to ZoomLast,
ZoomNext tools (extent history)
Quantum GIS
qgis at qgis.org
Fri Nov 27 09:59:34 EST 2009
#1716: improvements to ZoomLast, ZoomNext tools (extent history)
-------------------------------------+--------------------------------------
Reporter: smizuno | Owner: mhugent
Type: patch | Status: new
Priority: minor: annoyance | Milestone: Version 1.4.0
Component: GUI | Version: HEAD
Resolution: | Keywords:
Platform_version: | Platform: All
Must_fix: No | Status_info: 0
-------------------------------------+--------------------------------------
Comment (by smizuno):
Replying to [comment:8 marisn]:
While I was only fixing the extent history mechanics to enable/disable the
buttons and track the history correctly, I considered what happens when
the map CRS is changed.
While it would be a good idea to have the extent history track the map
CRS, there are situations where a previous extent could 'blow up' a CRS
transformation. This should be trapped so it doesn't cause a segfault, be
what should QGIS behavior be in this case? Doing nothing is confusing.
Popping an error dialog gets really annoying after the first one.
The most common scenario I have seen is forgetting to set the map CRS
before loading data that has a UTM projection, for example, after starting
QGIS. In this case the extents are more correct for the UTM, not the
default EPSG:4326, if the map CRS is now changed to UTM. The extents are
likely way out of bounds, as well.
I almost put a clear extent history on map CRS change, but decided not to
because that behavior could be confusing and annoying.
I believe that all consequences of map CRS change on the extent history
should be considered before doing anything further.
--
Ticket URL: <http://trac.osgeo.org/qgis/ticket/1716#comment:9>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats
More information about the QGIS-trac
mailing list