Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Ok... reading through the javadocs of the geoapi feature model it appears that geotools is doing the correct thing. FeatureType.getCRS() is derived from the default geometric attribute of the type. In this case there is none, so null is acceptable.. nasty.
So I guess we will have to work around this case in geoserver, and in the case of no crs reported look it up from feature type info metadata. Not ideal but doable. I guess the bright side is that we won't have to go through the hassle of creating a geoapi release.
-Justin
Justin Deoliveira wrote:
Hi all,
Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface
It was not clear to me from this bug report what change to geoapi is needed.
Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
Justin the timing is not bad on the geoapi side; I would like to make a GeoAPI 2.2.0 anyways (so we can close off that branch with GeoTools 2.5.x as its only user). I am doing a bunch of hacking this weekend with Mark and would be willing to apply the patch and make a new GeoAPI release for your Monday.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
If this is an option; the timing for a geoapi release is good; I will check on IRC if you are around to talk this over.
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
Ok... reading through the javadocs of the geoapi feature model it appears that geotools is doing the correct thing. FeatureType.getCRS() is derived from the default geometric attribute of the type. In this case there is none, so null is acceptable.. nasty.
I see - if it is nasty perhaps the javadocs can be changed. I did suspect that we added that method as short cut to asking people to check the default geometry all the time? The gml model allows for a SRSName to be defined at any level regardless of if a geometry is actually used.
So I guess we will have to work around this case in geoserver, and in the case of no crs reported look it up from feature type info metadata. Not ideal but doable. I guess the bright side is that we won't have to go through the hassle of creating a geoapi release.
See above; one will be needed anyways - but this way there is no time pressure.
Jody
Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface
It was not clear to me from this bug report what change to geoapi is needed.
The changes are pretty simple. Basically:
1) Change the javadoc of FeatureType a little bit, basically making the crs a first class property, and deriving it in cases where it is unset.
2) modify FeatureTypeFactory.createFeatureType() and createSimpleFeatureType() to take a CRS object.
Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
Justin the timing is not bad on the geoapi side; I would like to make a GeoAPI 2.2.0 anyways (so we can close off that branch with GeoTools 2.5.x as its only user). I am doing a bunch of hacking this weekend with Mark and would be willing to apply the patch and make a new GeoAPI release for your Monday.
I could go for this, but it involves getting people to agree that this is a worthy change. It sounds like we agree that it is.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
If this is an option; the timing for a geoapi release is good; I will check on IRC if you are around to talk this over.
I won't be around for most of today, and then I will be traveling over the weekend. I will give you my +1, but I would like to get approval from others like Andrea, Ben, Gabriel, etc... before proceeding.
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
Jody
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
This is my fault, and I'm totally ok to just revert the change that
triggered this issue (and I'm sorry for wasting your time on this)
(so I'd choose "pill" number 2).
However, I'm a little confused by the whole issue. When no
geometric attributes are extracted and feature bounding
is requested nevertheless, GetFeature does two things:
* it puts the geometry attributes in the list of attributes
that have to be extracted anyways
* wraps the the returned feature collection with a
FeatureBoundsFeatureCollection that will return only
the requested attributes, but will leverage the raw
feature collection to compute the collection bounds and
the single feature bounds
Soo... all of the above should not be happening?
What's going on?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Running the wfs 1.1 cite tests popped out some issues with the bug fix for GEOS-2583, which outputs bounds for wfs 1.1 feature collections, and respects the service "featureBounding" configuration.
The issues (of course) pops up in corner cases, such as encoding feature collections which have no geometric attributes, and empty feature collections. The first is a bug in the construction of simple feature types. Filed here:
The fix is more or less trivial, but to do it cleanly requires a change to a geoapi interface Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.
The issue of empty feature collection is an issue with one of the gml bindings, and is easily fixed.
So options on how to proceed:
1) do the right thing, fix the bug in geotools, update geoapi and push back the release a few days
2) roll back the fix for GEOS-2583, and live with the bug until the next release.
3) hack around the problem for now in geotools, and "promise" to fix it correctly for 1.7.4.
Thoughts? I personally am ok with pushing back the release a few days to do the fix properly. Serves us right for trying to fix bugs at the last minute ;).
This is my fault, and I'm totally ok to just revert the change that
triggered this issue (and I'm sorry for wasting your time on this)
(so I'd choose "pill" number 2).
However, I'm a little confused by the whole issue. When no
geometric attributes are extracted and feature bounding
is requested nevertheless, GetFeature does two things:
* it puts the geometry attributes in the list of attributes
that have to be extracted anyways
* wraps the the returned feature collection with a
FeatureBoundsFeatureCollection that will return only
the requested attributes, but will leverage the raw
feature collection to compute the collection bounds and
the single feature bounds
Not sure exactly, i would have to debug again to be sure what is happening. But at some point the CRS is lost. The envelope returned by FCFB.getBounds() has no CRS set on it. Perhaps this is the main issue and could be patched in FCFB directly. And asking the FCFB.getSchema() (which unless i am mistaken is the "view" of the actual type) for its CRS results in the issue I described above.
Soo... all of the above should not be happening?
What's going on?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
However, I'm a little confused by the whole issue. When no
geometric attributes are extracted and feature bounding
is requested nevertheless, GetFeature does two things:
* it puts the geometry attributes in the list of attributes
that have to be extracted anyways
* wraps the the returned feature collection with a
FeatureBoundsFeatureCollection that will return only
the requested attributes, but will leverage the raw
feature collection to compute the collection bounds and
the single feature bounds
Not sure exactly, i would have to debug again to be sure what is happening. But at some point the CRS is lost. The envelope returned by FCFB.getBounds() has no CRS set on it. Perhaps this is the main issue and could be patched in FCFB directly. And asking the FCFB.getSchema() (which unless i am mistaken is the "view" of the actual type) for its CRS results in the issue I described above.
Ok. FCFB returns the "target", geometryless feature type, but has a reference to the native feature type inside. So I believe this
can be patched by having FCFB extract the CRS from its wrapped
feature collection schema and rebuilding the RereferenceEnvelope
with it before getBounds() returns (call it an educated guess,
I did not actually try).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
However, I'm a little confused by the whole issue. When no
geometric attributes are extracted and feature bounding
is requested nevertheless, GetFeature does two things:
* it puts the geometry attributes in the list of attributes
that have to be extracted anyways
* wraps the the returned feature collection with a
FeatureBoundsFeatureCollection that will return only
the requested attributes, but will leverage the raw
feature collection to compute the collection bounds and
the single feature bounds
Not sure exactly, i would have to debug again to be sure what is happening. But at some point the CRS is lost. The envelope returned by FCFB.getBounds() has no CRS set on it. Perhaps this is the main issue and could be patched in FCFB directly. And asking the FCFB.getSchema() (which unless i am mistaken is the "view" of the actual type) for its CRS results in the issue I described above.
Ok. FCFB returns the "target", geometryless feature type, but has a reference to the native feature type inside. So I believe this
can be patched by having FCFB extract the CRS from its wrapped
feature collection schema and rebuilding the RereferenceEnvelope
with it before getBounds() returns (call it an educated guess,
I did not actually try).
Sounds good to me. The current "workaround" in FeatureCollectionTypeBinding is probably still a good idea imho, leaving it in as a defense mechanism can't hurt. Want to open a jira issue for 1.7.4?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Ok. FCFB returns the "target", geometryless feature type, but has a reference to the native feature type inside. So I believe this
can be patched by having FCFB extract the CRS from its wrapped
feature collection schema and rebuilding the RereferenceEnvelope
with it before getBounds() returns (call it an educated guess,
I did not actually try).
Sounds good to me. The current "workaround" in FeatureCollectionTypeBinding is probably still a good idea imho, leaving it in as a defense mechanism can't hurt. Want to open a jira issue for 1.7.4?
Which then requires us to do another geoapi milestone release, etc... I could hack around the problem and instantiate the SimpleFeatureTypeImpl directly... but I can see people having an issue with this, including myself.