#1588 closed enhancement (wontfix)
WMS_Support pyramid levels for big coverage as a layer in Petascope
Reported by: | Bang Pham Huu | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 9.5 |
Component: | petascope | Version: | development |
Keywords: | Cc: | Peter Baumann, Dimitar Misev, Vlad Merticariu | |
Complexity: | Medium |
Description
Introduction:
WMS 1.3 implemented in Petascope follow the OGC WMS 1.3 standard http://portal.opengeospatial.org/files/?artifact_id=4756&passcode=8trkf8nkchqpkn0ywu5c, and only support 2D coverage now. It can be implemented to N-D as in my comment: http://rasdaman.org/ticket/1304#comment:7.
Problem:
The main problem is that this implementation works with small coverage, but will not work with big coverage which is imported from WCS as a WMS layer due to the big domain to handle from WMS client in every request.
For example a WMS layer imported from 2D WCS coverage of Europe which has domain [0:10000, 0:10000], then all WMS client (OpenLayers, QGIS,…) will first query the whole layer at zoom level 0 (WMS client always has a zoom-level to go to lower or higher resolutions).
This is not efficient as at zoom level-0 the whole layer is too big to query and scale to WMS tiles (normally WMS tile size is 256 x 256), so the RASQL query will be:
select scale(c[0:10000,0:10000], [0:255, 0:255], "png") from big_coverage
While a query to a lightweight collection is enough for this zoom level 0, as with tile 256x256, all the collections with bigger domain than it will return the same result.
select scale(c[0:1000,0:1000], [0:255, 0:255], "png") from big_coverage_scale_level_8
In short, Petascope should depend on zoom-level of WMS client to query on scaled Rasdaman collections and this will be much more efficient.
Proposed changes:
Same as other WMS servers like MapServer, GeoServer, we need to support the pyramid levels for big coverage by inserting multiple scaled collections in Rasdaman.
Basically, it needs to determine in WMS handler which collection it should query by calculating the grid intervals of input bounding box on a big_coverage_scale_level1, e.g:
xMin=0,yMin=0,xMax=10000,yMax=10000, it covers whole layer so go to the lowest scaled level, in this case is: big_coverage_scale_level8.
If with smaller input bounding box, then the query will go to lower scaled collection by counting the numbers of grid points.
e.g: xMin=20,yMin=30,xMax=500,yMax=500, then it is: 481x471 points, this request should go to the collection with highest resolution: big_coverage_scale_level1.
So WCTS_Import should add an option for levels of WMS in recipes, e.g: "level": 8. Then Petascope will create 1 coverage (e.g: big_coverage) with 4 collections in Rasdaman: level 1, 2, 4, 8 (big_coverage_scale_level1, bigcoverage_scale_level2, big_coverage_scale_level4, big_coverage_scale_level8), higher level means lower interval for X, Y axes (e.g: level 1 domain is [0:10000,0:10000], level 2 is [0:5000,0:5000], level 4 is [0:2500, 0:2500], level 8 is [0:1250, 0:1250].
Then when update slice for the coverage, first it will update big_coverage_scale_level1 with the input file, then it will need the insert into query with scale by level to other collections, e.g:
insert into big_coverage_scale_level2 values select scale(c[0:10000, 0:10000], [0:5000, 0:5000]) from big_coverage_scale_level1 as c.
I mentioned about X, Y axes because WMS can support not only 2 dimensions but also as WCS with N-dimensions. However, only X, Y axes are the subject of zoom level from WMS client so only need to scale on these axes.
Change History (3)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
n-D pyramids are massively more complicated, see the PhD thesis of Angelica Gutierrez for details.
This one is important for WMS when requesting big layer, do you have any problem?