Bug report #3504

Zoom to full or layer extent fails after OTF transformation

Added by Gary Sherman over 9 years ago. Updated almost 5 years ago.

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 9 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 9 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 9 years ago

This problem was introduced by which fixed issue #3471.

#4 Updated by Gary Sherman over 9 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 9 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 about 9 years ago

See also #3508 and #2426

#7 Updated by Richard Duivenvoorde about 9 years ago

Pretty sure #2349 is also a dateline problem

#8 Updated by Alexander Bruy about 9 years ago

Probably fixed in 79c0c470 (SVN r15755)

#9 Updated by Giovanni Manghi over 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#10 Updated by Paolo Cavallini about 8 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 almost 8 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#12 Updated by Jürgen Fischer about 6 years ago

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#13 Updated by Nyall Dawson almost 5 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.

Also available in: Atom PDF