Hi Justin,
right now we have three wfs xml configurations,
wfs 1.1 configuration in geotools
wfs 1.1 configuration in geoserver
wfs 1.0 configuration in geoserver
I wonder if there's anything special on them that prevents us to have a single
copy of 1.0 and 1.1 configurations on geotools.
That would, by one side, simplify maintainance of 1.1 config by having a single
one and porting the 1.0 config to geotools would make it really easy to migrate
the WFS 1.0 datastore to work upon supported and maintained code.
So do you think that's doable?
Cheers,
Gabriel
Hi Gabriel,
Its definitely doable, and we should do it. Right now in GeoServer a lot of "manual" work is done that the EMF based bindings in geotools also do. The tough part is ensuring no regressions.
But yeah, +1 on this.
-Justin
Gabriel Roldán wrote:
Hi Justin,
right now we have three wfs xml configurations,
wfs 1.1 configuration in geotools
wfs 1.1 configuration in geoserver
wfs 1.0 configuration in geoserver
I wonder if there's anything special on them that prevents us to have a single copy of 1.0 and 1.1 configurations on geotools.
That would, by one side, simplify maintainance of 1.1 config by having a single one and porting the 1.0 config to geotools would make it really easy to migrate the WFS 1.0 datastore to work upon supported and maintained code.
So do you think that's doable?
Cheers,
Gabriel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi Gabriel,
Its definitely doable, and we should do it. Right now in GeoServer a lot of "manual" work is done that the EMF based bindings in geotools also do. The tough part is ensuring no regressions.
But yeah, +1 on this.
Afaik the configurations are also feeding some specific context parameteres for WFS bindings overrides to use (see for example
my work at http://jira.codehaus.org/browse/GEOS-1189).
So a GeoServer configuration should extend from a GeoTools one?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Friday 28 November 2008 14:42:47 Andrea Aime wrote:
Justin Deoliveira ha scritto:
> Hi Gabriel,
>
> Its definitely doable, and we should do it. Right now in GeoServer a lot
> of "manual" work is done that the EMF based bindings in geotools also
> do. The tough part is ensuring no regressions.
>
> But yeah, +1 on this.
Afaik the configurations are also feeding some specific context
parameteres for WFS bindings overrides to use (see for example
my work at http://jira.codehaus.org/browse/GEOS-1189).
So a GeoServer configuration should extend from a GeoTools one?
That seems like the right thing to do to me. Yet, in the specific case of
featurebounding it may even be a desirable thing at the geotools level too?
Cheers
Andrea
Gabriel Roldán ha scritto:
On Friday 28 November 2008 14:42:47 Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Gabriel,
Its definitely doable, and we should do it. Right now in GeoServer a lot
of "manual" work is done that the EMF based bindings in geotools also
do. The tough part is ensuring no regressions.
But yeah, +1 on this.
Afaik the configurations are also feeding some specific context
parameteres for WFS bindings overrides to use (see for example
my work at http://jira.codehaus.org/browse/GEOS-1189).
So a GeoServer configuration should extend from a GeoTools one?
That seems like the right thing to do to me. Yet, in the specific case of featurebounding it may even be a desirable thing at the geotools level too?
Indeed it would. The issue is what to conjure up in order to make
Pico container feed the proper information. Since it feeds object
setters based on the class only, we cannot just add a boolean into
the context, but we would have to wrap it somehow.
Maybe a WFSEncodingOptions object, that for the moment contains
only a boolean flag (or could contain two if we wanted to separate
feature collection and feature bounds generation, like the
GML2 translator does now).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hmmm... I think it would be simpler to just have GeoServer override the AbstractFeatureTypeBinding (I think it might already) and check the configuration directly to see if feature bounds should be output.
But if we think that having the option directly in GeoTools is worth the additional work then yeah. We could more or less do the same thing. Create a subclass of AbstractFeatureTypeBinding which does not output bounds. Would be trivial to implement. Then add a flag to GMLConfiguration, setFeatureBounding(). And then the flag could be checked during binding register and the appropriate binding set up.
An alternative would be to just throw the GMLConfiguration itself into the binding context, and have the AbstractFeatureTypeBinding take it as a constructor arg and check the flag directly. That might be the simplest solution of all in terms of amount of code.
-Justin
Andrea Aime wrote:
Gabriel Roldán ha scritto:
On Friday 28 November 2008 14:42:47 Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Gabriel,
Its definitely doable, and we should do it. Right now in GeoServer a lot
of "manual" work is done that the EMF based bindings in geotools also
do. The tough part is ensuring no regressions.
But yeah, +1 on this.
Afaik the configurations are also feeding some specific context
parameteres for WFS bindings overrides to use (see for example
my work at http://jira.codehaus.org/browse/GEOS-1189).
So a GeoServer configuration should extend from a GeoTools one?
That seems like the right thing to do to me. Yet, in the specific case of featurebounding it may even be a desirable thing at the geotools level too?
Indeed it would. The issue is what to conjure up in order to make
Pico container feed the proper information. Since it feeds object
setters based on the class only, we cannot just add a boolean into
the context, but we would have to wrap it somehow.
Maybe a WFSEncodingOptions object, that for the moment contains
only a boolean flag (or could contain two if we wanted to separate
feature collection and feature bounds generation, like the
GML2 translator does now).
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.