Hi all,
I'm writing this email since I would like to propose a small change on
the GeoServer WCS behavior when checking for requestResponseCRS
against a getCoverage request.
The actual implementation of the WCS at a getCoverage request arrival
checks if the requested CRS is listed on the CoverageConfig
requestResponseCRSs attribute and if not throws an exception even if
it would be able to reproject the coverage on the requested CRS. This
behavior is of course compatible with the OGC protocol specifications,
but is due to the user to add all the allowed CRS codes to the
CoverageConfig requestResponseCRSs attribute since by default
GeoServer cannot insert the whole list of GeoServer allowed CRSs by
default (even because we would have enormous getCapabilities and
describeCoverage responses back).
What I'm proposing here is basically to add a small configuration
option for the WCS which allows the user to choose if by default the
WCS should enable or not the requestResponseCRSs check when creating a
new Coverage config, which the user can always change later by editing
the Coverage properties and setting this option value explicitly if
different by the default.
In the case of the community accepts this small proposal, I also want
to ask if it can be committed 1.7.x branch or I have to wait the
official release first.
Thanks all,
Alessio.
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
http://www.geo-solutions.it
-------------------------------------------------------
Alessio Fabiani ha scritto:
Hi all,
I'm writing this email since I would like to propose a small change on
the GeoServer WCS behavior when checking for requestResponseCRS
against a getCoverage request.
The actual implementation of the WCS at a getCoverage request arrival
checks if the requested CRS is listed on the CoverageConfig
requestResponseCRSs attribute and if not throws an exception even if
it would be able to reproject the coverage on the requested CRS. This
behavior is of course compatible with the OGC protocol specifications,
but is due to the user to add all the allowed CRS codes to the
CoverageConfig requestResponseCRSs attribute since by default
GeoServer cannot insert the whole list of GeoServer allowed CRSs by
default (even because we would have enormous getCapabilities and
describeCoverage responses back).
What I'm proposing here is basically to add a small configuration
option for the WCS which allows the user to choose if by default the
WCS should enable or not the requestResponseCRSs check when creating a
new Coverage config, which the user can always change later by editing
the Coverage properties and setting this option value explicitly if
different by the default.
The proposed change look fine to me.
In the case of the community accepts this small proposal, I also want
to ask if it can be committed 1.7.x branch or I have to wait the
official release first.
You have to wait, we're in deep freeze trying to get the damn 1.7.0
out of the door, any commit that is not related to a critical bug
fix or to increase testing will be rolled back at once.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ok, thanks Andrea, I'll wait for the release.
Cheers,
Alessio.
On Fri, Oct 10, 2008 at 4:25 PM, Andrea Aime <aaime@anonymised.com> wrote:
Alessio Fabiani ha scritto:
Hi all,
I'm writing this email since I would like to propose a small change on
the GeoServer WCS behavior when checking for requestResponseCRS
against a getCoverage request.
The actual implementation of the WCS at a getCoverage request arrival
checks if the requested CRS is listed on the CoverageConfig
requestResponseCRSs attribute and if not throws an exception even if
it would be able to reproject the coverage on the requested CRS. This
behavior is of course compatible with the OGC protocol specifications,
but is due to the user to add all the allowed CRS codes to the
CoverageConfig requestResponseCRSs attribute since by default
GeoServer cannot insert the whole list of GeoServer allowed CRSs by
default (even because we would have enormous getCapabilities and
describeCoverage responses back).
What I'm proposing here is basically to add a small configuration
option for the WCS which allows the user to choose if by default the
WCS should enable or not the requestResponseCRSs check when creating a
new Coverage config, which the user can always change later by editing
the Coverage properties and setting this option value explicitly if
different by the default.
The proposed change look fine to me.
In the case of the community accepts this small proposal, I also want
to ask if it can be committed 1.7.x branch or I have to wait the
official release first.
You have to wait, we're in deep freeze trying to get the damn 1.7.0
out of the door, any commit that is not related to a critical bug
fix or to increase testing will be rolled back at once.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
http://www.geo-solutions.it
-------------------------------------------------------