Bug report #3504
Zoom to full or layer extent fails after OTF transformation
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Marco Hugentobler | ||
Category: | Projection Support | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | All | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 13564 |
Description
Load a layer (e.g. alaska.shp from the sample data set). Turn on OTF transformation and choose NAD27 as the target coordinate system. Once set, click on Zoom full or zoom to layer extent. It doesn't work. Using the zoom to point plugin and putting -150, 60 and zooming shows the data is there and reprojected to NAD27 geographic.
This problem has been confirmed in HEAD on Windows, Mac, and Ubuntu.
History
#1 Updated by Jürgen Fischer over 13 years ago
Are you sure that worked with 1.6? landice works, alaska or airports does not. Looks like it's a problem with extents crossing the dateline. I think we don't have a way to express that a bounding box for a latlong crs is including the dateline instead of excluding it.
#2 Updated by Gary Sherman over 13 years ago
Yes, I'm sure. It works on both 1.5 and 1.6 on OS X. It also works on 1.6 on Windows with the standalone installer. I don't have earlier versions for other platforms to test.
#3 Updated by Gary Sherman over 13 years ago
This problem was introduced by which fixed issue #3471.
#4 Updated by Gary Sherman over 13 years ago
The change in may not be the root cause. Projection is not getting set when loading a layer (e.g. from the alaska sample set). If you load the layer, set the projection to Alaska Albers NAD27 then reproject to geographic the zoom full works.
#5 Updated by Gary Sherman over 13 years ago
Ignore my last comment about projection not getting set. Must have been an anomaly--- is the cause and there must be away to deal with projections that span 180 degrees while still fixing issue #3471.
#6 Updated by Alexander Bruy over 13 years ago
#7 Updated by Richard Duivenvoorde over 13 years ago
Pretty sure #2349 is also a dateline problem
#8 Updated by Alexander Bruy over 13 years ago
Probably fixed in 79c0c470 (SVN r15755)
#9 Updated by Giovanni Manghi almost 13 years ago
- Target version changed from Version 1.7.0 to Version 1.7.4
#10 Updated by Paolo Cavallini over 12 years ago
- Target version changed from Version 1.7.4 to Version 1.8.0
- Affected QGIS version set to master
- Crashes QGIS or corrupts data set to No
#11 Updated by Paolo Cavallini about 12 years ago
- Target version changed from Version 1.8.0 to Version 2.0.0
#12 Updated by Jürgen Fischer over 10 years ago
- Target version changed from Version 2.0.0 to Future Release - Lower Priority
#13 Updated by Nyall Dawson over 9 years ago
- Status changed from Open to Closed
- Pull Request or Patch supplied set to No
Closed due to lack of feedback (last comment was a probable fix). Please re-open if still an issue in current version.