Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upsidedown (and rotated?) Rasters Not Supported #10872

Closed
qgib opened this issue Nov 16, 2007 · 3 comments
Closed

Upsidedown (and rotated?) Rasters Not Supported #10872

qgib opened this issue Nov 16, 2007 · 3 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented Nov 16, 2007

Author Name: Frank Warmerdam - (Frank Warmerdam -)
Original Redmine Issue: 813

Redmine category:rasters
Assignee: Frank Warmerdam -


Upside rasters (that is the top is further south than the bottom) do not appear to be supported by the qgsrasterlayer code. If one is opened (as the only object) an empty extent is established for the map. I'm guessing this is because the min/max values in the layer extent are backwards.

Driver: ISIS3/USGS Astrogeology ISIS cube (Version 3)
Files: r0200357_10m_Jul20_o_i3_detatched.lbl
       r0200357_10m_Jul20_o_i3_detatched.cub
Size is 317, 559
Coordinate System is:
PROJCS["Equirectangular Mars",
    GEOGCS["GCS_Mars",
        DATUM["D_Mars",
            SPHEROID[[Mars_localRadius]],
        PRIMEM[[Reference_Meridian]],
        UNIT[[degree]],
    PROJECTION[[Equirectangular]],
    PARAMETER[[latitude_of_origin]],
    PARAMETER[[central_meridian]],
    PARAMETER[[false_easting]],
    PARAMETER[[false_northing]]
Origin = (-4766.964843750000000,-872623.625000000000000)
Pixel Size = (10.102499961853027,10.102499961853027)
Corner Coordinates:
Upper Left  (   -4766.965, -872623.625) (175d35'13.52"W,  0d 0'53.02"S)
Lower Left  (   -4766.965, -866976.328) (175d35'13.52"W,  0d 0'52.68"S)
Upper Right (   -1564.472, -872623.625) (175d35'13.32"W,  0d 0'53.02"S)
Lower Right (   -1564.472, -866976.328) (175d35'13.32"W,  0d 0'52.68"S)
Center      (   -3165.719, -869799.976) (175d35'13.42"W,  0d 0'52.85"S)
Band 1 Block=317x1 Type=Byte, [[ColorInterp]]=Undefined
  [[NoData]] Value=0

A reduced resolution analog to the above is being attached as a tiff file.


@qgib
Copy link
Contributor Author

qgib commented Nov 16, 2007

Author Name: Frank Warmerdam - (Frank Warmerdam -)


In the raster tranparency branch I have made changes () that will place rotated/sheared/upsidedown images in the right portion of the map, but without the correct orientation. Because this is a fairly serious failure still, an interactive warning is issued to the user.

This lets folks see these images, but the failure to orient them right means they won't overlay other layers properly - still quite a serious bug. So on that basis I'm leaving this bug open in the hopes that at some point we will rework the raster layer sufficient to display non-northup images properly. This will require substantial work.


  • status_id was changed from Open to In Progress

@qgib
Copy link
Contributor Author

qgib commented Nov 16, 2007

Author Name: Frank Warmerdam - (Frank Warmerdam -)


Actually, as I think about it, another alternative used by some other software packages (ie. Cadcorp SIS) is to create a GDAL "warped VRT" in memory that will take care of resampling on the fly within GDAL.

@qgib
Copy link
Contributor Author

qgib commented Nov 16, 2007

Author Name: Frank Warmerdam - (Frank Warmerdam -)


I have applied which rips out the changes from and replaces it with used of a "gdal warped vrt". This will render rotated, upside down and even "gcp controlled" images in the proper place. There is an outstanding issue of recognising nodata areas that may need action but that isn't the point of this particular bug report so I'm closing.


  • resolution was changed from to fixed
  • status_id was changed from In Progress to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats) labels May 24, 2019
@qgib qgib added this to the Branch - Raster Transparency milestone May 24, 2019
@qgib qgib closed this as completed May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

1 participant