Opened 10 years ago
Closed 10 years ago
#788 closed defect (fixed)
WCS scaling extension wrongly maps scale-factor to WCPS
Reported by: | Piero Campalani | Owned by: | Piero Campalani |
---|---|---|---|
Priority: | critical | Milestone: | 9.0.x |
Component: | petascope | Version: | development |
Keywords: | scale factor wcs | Cc: | gxinghua |
Complexity: | Medium |
Description
WCS scaling extensions makes a wrong mapping to WCPS query in case of scale factors, turning lo
and hi
bounds to lo/factor
and hi/factor
bounds, but this breaks when lo
or hi
are 0 since the
service=WCS& version=2.0.1& request=GetCoverage& coverageId=mr& subset=i(0,7)& subset=j(0,7)& scalefactor=0.1
becomes:
select csv(scale( c[0:7,203:210], [0:70,2030:2100] )) from mr AS c
but the index extent then is scaled from 8 to 71 cells, while it should go to 80 cells.
Change History (5)
comment:1 by , 10 years ago
Cc: | added; removed |
---|---|
Status: | new → accepted |
comment:3 by , 10 years ago
a note: this does not actually depend on the index values (0 or not).
The current implementation scales the single bounds but this does never work since the formula of the extent includes the +1 term:
EXTENT := (hi - lo) + 1 = W SCALED_EXTENT := EXTENT/F := [(hi - lo) + 1]/F = W/F := [(hi/F - lo/F) + 1/F]
whereas the current implementation yields an extent of [(hi/F - lo/F) + 1]
.
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Note:
See TracTickets
for help on using tickets.
Proper scaling is on the
lo
/hi
extent: fix upcoming.