Hi,
looking at the WCS describeCoverage response I've noticed
coverages by default can be requested in their native
CRS only. Now, the user interface is designed so that
coverages can be requested in other CRS as well, but it's
good only if you want to support a handful of them and know
the SRS id by heart.
I'm wondering if this has been done to prevent issues
with denial of service attacks, since coverage reprojection
is CPU intensive. Yet, since we serve the coverages from
WMS too, a coverage reprojection can be performed there too.
Or is it because reprojection can ruin/alter the
data contents of geophisics grids?
Cheers
Andrea
On 1/21/07, Andrea Aime <aaime@anonymised.com> wrote:
Hi,
looking at the WCS describeCoverage response I've noticed
coverages by default can be requested in their native
CRS only.
Hello Andrea:
Last time I tried reprojecting a WCS coverage, it seemed to work well.
I think I tried in uDig, as well as getmap requests.
Alex
Here is a thought from a user/analysts of coverage-type datasets...
Reprojection certainly does alter the data contents of the grid, but I don't
think it should be a reason to limit or prevent reprojection of coverages.
Reprojection either alters the coordinates (nearest neighbor interpolation)
of grid points or changes the value (bilinear interpolation, cubic
convolution, kriging, etc...). Any of these methods will 'alter' the data
contents and introduce some type of uncertainty, but it is a necessary evil
and can be accounted for when analyzing the data. Reprojection is often a
requirement for merging geophysical datasets together, especially satellite
remote sensing data that is collected from different sensor platforms.
aaime wrote:
Hi,
looking at the WCS describeCoverage response I've noticed
coverages by default can be requested in their native
CRS only. Now, the user interface is designed so that
coverages can be requested in other CRS as well, but it's
good only if you want to support a handful of them and know
the SRS id by heart.
I'm wondering if this has been done to prevent issues
with denial of service attacks, since coverage reprojection
is CPU intensive. Yet, since we serve the coverages from
WMS too, a coverage reprojection can be performed there too.
Or is it because reprojection can ruin/alter the
data contents of geophisics grids?
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
View this message in context: http://www.nabble.com/WCS-reprojection--tf3049067.html#a8522854
Sent from the GeoServer - Dev mailing list archive at Nabble.com.
Tyler Erickson ha scritto:
Here is a thought from a user/analysts of coverage-type datasets...
Reprojection certainly does alter the data contents of the grid, but I don't
think it should be a reason to limit or prevent reprojection of coverages. Reprojection either alters the coordinates (nearest neighbor interpolation)
of grid points or changes the value (bilinear interpolation, cubic
convolution, kriging, etc...). Any of these methods will 'alter' the data
contents and introduce some type of uncertainty, but it is a necessary evil
and can be accounted for when analyzing the data. Reprojection is often a
requirement for merging geophysical datasets together, especially satellite
remote sensing data that is collected from different sensor platforms.
Indeed I agree. Well, Geoserver can reproject coverages, it just defaults to not doing so, you have to manually add the other projections
you want to support in responses for each coverage.
I did not receive an answer from Simone or Alessio, but I think from
their perspective it's a kind of protection against requests that could
tear Geoserver to his knees: they are working with gigabyte sized coverages, think about what happens if someone asks for a reprojection
of those (either OOM, or Geoserver starts to work for a very long long time on a very CPU bound task).
What we miss here is an equivalent of the max features limit we do have
in WFS: the administrator can set up a maximum number of features that
will be served, no matter how many the WFS requests do really require.
Here it should be the same somehow, a maximum number of pixels returned
in a request (I may have said bytes, but since some formats are compressed, other aren't, maybe we do want to limit by the pixel count).
Cheers
Andrea