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

Show scales for pyramid creation #18970

Open
qgib opened this issue Jun 12, 2014 · 6 comments
Open

Show scales for pyramid creation #18970

qgib opened this issue Jun 12, 2014 · 6 comments
Labels
Feature Request Rasters Related to general raster layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented Jun 12, 2014

Author Name: Jonathan Moules (Jonathan Moules)
Original Redmine Issue: 10563

Redmine category:rasters


Currently in QGIS on the "Pyramids" tab on the right there is a "resolutions" box which actually has tile sizes for the pyramid levels.

The feature request is to replace these tile sizes with the native scales of the pyramids. This will allow users to make a more informed choice when creating their pyramids.

I envision something like:

Native Scales for pyramids:
(1:5000 - Raw Data)
1:10,000
1:20,000
1:40,000
1:80,000
1:160,000

The top item clearly differentiating and stating the native scale of the raw data (no pyramids).

@qgib
Copy link
Contributor Author

qgib commented Jun 12, 2014

Author Name: Jukka Rahkonen (Jukka Rahkonen)


QGIS has now two tools for building overviews: In "Layer - Properties - Pyramids" and in "Raster - Miscellaneous - Build overviews". I think that the latter one is better and the other one could be removed. It gives UI for creating compressed overviews and custom overview levels and for power users it shows also the corresponding gdaladdo command in an editable text box.

The Properties-Pyramids tab reports under "Resolutions" something that for my mind means "Sizes" - how many pixels it takes to cover the whole layer. Gdalinfo reports the same like
Size is 12000, 12000
Pixel Size = (0.500000000000000,-0.500000000000000)
...
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Overviews: 6000x6000, 3000x3000, 1500x1500, 750x750, 375x375, 188x188

For me the most natural and exact unit for overviews is the one that is used as gdaladdo "levels" and in the "Raster - Miscellaneous - Build overviews" tool - the ratio of the pixel size in the overview to the native pixel size. I would say that the Native scale of 1:20000 is the most obscure alternative. Native scale on computer screen or on high resolution mobile device or on print? Compare with #15674. See also http://www.gdal.org/gdaladdo.html which recommends to use levels 2, 4, 8... for performance reasons.

@qgib
Copy link
Contributor Author

qgib commented Jun 12, 2014

Author Name: Etienne Tourigny (@etiennesky)


the second one is in gdaltools (a core python plugin) which may not be available. It would be nice to create a new widget for this which could be used by both, with different back-ends doing the job (i.e. gdaladdo or gdal api).

@qgib
Copy link
Contributor Author

qgib commented Jun 12, 2014

Author Name: Etienne Tourigny (@etiennesky)


Also note that using scales instead of sizes, while practical for the user, is not practical from a software perspective. The best way to build overviews is an integer fraction of raster size (2,4,8,16,etc). If you want the exact scale that will result in a fractional ratio between native size and overview size.

@qgib
Copy link
Contributor Author

qgib commented Jun 12, 2014

Author Name: Jonathan Moules (Jonathan Moules)


I wasn't aware of the Raster - Miscellaenous - Build Overviews function. I'd agree that having the same function twice is sub-optimal (more maintenance for no user-gain).

I may not have been clear - I'm not suggesting users be able to manually type in their own scales. I'm suggesting that whatever the scales (that correspond to the 2 4 8 etc in GDAL) are be shown to the user instead of either 2 4 8 or "20002000" "10001000" etc. Neither of these later two will mean something to 95% of the users. And even though I know what they mean, the numbers themselves are still relatively meaningless because I don't know what scales they equate to (even approximately).

I'm not in any way suggesting changing the actual function of pyramid building, simply the interface to it.
I guess it could even show all of them, but again to a regular user none of them are going to mean anything.
Hope that's clearer.

@qgib
Copy link
Contributor Author

qgib commented Jun 24, 2014

Author Name: Paolo Cavallini (@pcav)


  • category_id was configured as Rasters

@qgib
Copy link
Contributor Author

qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0

@qgib qgib added Feature Request Rasters Related to general raster layer handling (not specific data formats) labels May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

1 participant