Hi,
so, we have cite 1.1 which is not passing due to an issue
we already discussed on some chat (I hoped it was already
fixed, it's not).
Basically, cite wfs 1.1 tests checks the bounds
property and pretends it has a CRS and a non null value,
even if the geometry properties are not
requested and are nillable (with nulls in the sample data btw),
thus we should not return them.
Now, looking at the test I'm left wondering if not stating
the envelope at all (boundedBy is optional) would work (that
is, is the test checking that element only if it's there?).
Unfortunately I cannot find any way to disable boundedBy generation
in the GML3 encoder (documentation pretty please!).
If the case is the opposite one, or in the general situation
where the user asks for the feature bounds to be computed even
when geometries are not there, we should do the following imho:
* read all geometry properties (our feature model computes
the bounds on the geometries loaded)
* wrap the feature collection into a morphing feature collection,
that returns wrapping feature objects, advertising the schema
that was requested, and delegating most requests to
the inner feature that has all the geometries, so that we
can still compute the bbox.
Opinions? In the meantime I'm off trying out WCS, WMS and WFS 1.0
hoping at least these ones do pass.
Ah, btw, I'm getting quite a bit of other failures as well, for
example null pointer exceptions in logic filter tests and so on.
Wondering, what was the last time we did pass the cite wfs 1.1.0
tests? They have never worked for me....
Cheers
Andrea
To be honest I am not surprised at all. For the last six months trunk as
been a dumping ground for patches and experimental development. Some
fixes which inevitably never made it over.
As for the bounds issue, I think the wrapper approach is the best way to
go. I am not sure but i think just blindly supplementing the requested
properties with all geometric properties will cause additional failures.
-Justin
Andrea Aime wrote:
Hi,
so, we have cite 1.1 which is not passing due to an issue
we already discussed on some chat (I hoped it was already
fixed, it's not).
Basically, cite wfs 1.1 tests checks the bounds
property and pretends it has a CRS and a non null value,
even if the geometry properties are not
requested and are nillable (with nulls in the sample data btw),
thus we should not return them.
Now, looking at the test I'm left wondering if not stating
the envelope at all (boundedBy is optional) would work (that
is, is the test checking that element only if it's there?).
Unfortunately I cannot find any way to disable boundedBy generation
in the GML3 encoder (documentation pretty please!).
If the case is the opposite one, or in the general situation
where the user asks for the feature bounds to be computed even
when geometries are not there, we should do the following imho:
* read all geometry properties (our feature model computes
the bounds on the geometries loaded)
* wrap the feature collection into a morphing feature collection,
that returns wrapping feature objects, advertising the schema
that was requested, and delegating most requests to
the inner feature that has all the geometries, so that we
can still compute the bbox.
Opinions? In the meantime I'm off trying out WCS, WMS and WFS 1.0
hoping at least these ones do pass.
Ah, btw, I'm getting quite a bit of other failures as well, for
example null pointer exceptions in logic filter tests and so on.
Wondering, what was the last time we did pass the cite wfs 1.1.0
tests? They have never worked for me....
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,468a2ae3179382143011171!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
To be honest I am not surprised at all. For the last six months trunk as
been a dumping ground for patches and experimental development. Some
fixes which inevitably never made it over.
Hmm... if we want to release 1.6.0 cite tests have to pass the
cite tests... so I guess I have quite a bit of work to be done.
Shall we release 1.6.0 beta with known failures, or delay it
until I fix all of the problems?
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
To be honest I am not surprised at all. For the last six months trunk as
been a dumping ground for patches and experimental development. Some
fixes which inevitably never made it over.
Hmm... if we want to release 1.6.0 cite tests have to pass the
cite tests... so I guess I have quite a bit of work to be done.
Agreed, and it might not be as much work as you think. Often the same
bug in the code can lead to multiple cite tests failures.
Shall we release 1.6.0 beta with known failures, or delay it
until I fix all of the problems?
Well it is a beta so its not like the entire world is going to jump on
it right away.
Cheers
Andrea
!DSPAM:4007,468a505b206861439371379!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Let's go ahead and release. Though I'd like to have WFS 1.1 tests passing, since that's supposedly the main thrust of this release, I think our policies point to early betas not being required to pass all CITE tests. So put it out, and let's try for cite tests all passing and the new connection pooling for beta2 next week.
Chris
Andrea Aime wrote:
Justin Deoliveira ha scritto:
To be honest I am not surprised at all. For the last six months trunk as
been a dumping ground for patches and experimental development. Some
fixes which inevitably never made it over.
Hmm... if we want to release 1.6.0 cite tests have to pass the
cite tests... so I guess I have quite a bit of work to be done.
Shall we release 1.6.0 beta with known failures, or delay it
until I fix all of the problems?
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,468a5066207042458217002!
All the tests are passing now except for one transaction test. I have
committed all the fixes minus one that i am waiting discussion about on
the geotools devel list.
I was able to make these tests pass by setting the featureBounding
property in the citewfs-1.1 configuration. However to truly fix the
issue the gml encoder needs to be hooked up to it. Right now it encodes
the bounds by default. I am scheduling a task for this.
Andrea Aime wrote:
Hi,
so, we have cite 1.1 which is not passing due to an issue
we already discussed on some chat (I hoped it was already
fixed, it's not).
Basically, cite wfs 1.1 tests checks the bounds
property and pretends it has a CRS and a non null value,
even if the geometry properties are not
requested and are nillable (with nulls in the sample data btw),
thus we should not return them.
Now, looking at the test I'm left wondering if not stating
the envelope at all (boundedBy is optional) would work (that
is, is the test checking that element only if it's there?).
Unfortunately I cannot find any way to disable boundedBy generation
in the GML3 encoder (documentation pretty please!).
If the case is the opposite one, or in the general situation
where the user asks for the feature bounds to be computed even
when geometries are not there, we should do the following imho:
* read all geometry properties (our feature model computes
the bounds on the geometries loaded)
* wrap the feature collection into a morphing feature collection,
that returns wrapping feature objects, advertising the schema
that was requested, and delegating most requests to
the inner feature that has all the geometries, so that we
can still compute the bbox.
Opinions? In the meantime I'm off trying out WCS, WMS and WFS 1.0
hoping at least these ones do pass.
Ah, btw, I'm getting quite a bit of other failures as well, for
example null pointer exceptions in logic filter tests and so on.
Wondering, what was the last time we did pass the cite wfs 1.1.0
tests? They have never worked for me....
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,468a2ae3179382143011171!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
All the tests are passing now except for one transaction test. I have
committed all the fixes minus one that i am waiting discussion about on
the geotools devel list.
I was able to make these tests pass by setting the featureBounding
property in the citewfs-1.1 configuration. However to truly fix the
issue the gml encoder needs to be hooked up to it. Right now it encodes
the bounds by default. I am scheduling a task for this.
Arg! It seemed strange when I first read it... and in fact it is.
Yesterday by mistake I committed the following patch to GetFeature (rev 7152):
--- trunk/geoserver/wfs/src/main/java/org/geoserver/wfs/GetFeature.java 2007-07-03 16:59:02 UTC (rev 7151)
+++ trunk/geoserver/wfs/src/main/java/org/geoserver/wfs/GetFeature.java 2007-07-03 17:23:03 UTC (rev 7152)
@@ -18,6 +18,7 @@
import org.geotools.data.crs.ReprojectFeatureResults;
import org.geotools.feature.FeatureCollection;
import org.geotools.feature.FeatureType;
+import org.geotools.feature.GeometryAttributeType;
import org.geotools.filter.expression.AbstractExpressionVisitor;
import org.geotools.filter.visitor.AbstractFilterVisitor;
import org.geotools.referencing.CRS;
@@ -199,10 +200,13 @@
if (propName.matches("(\\w+:)?" + ati.getName())) {
tmp.add(ati.getName());
-
break;
}
}
+
+ if(wfs.isFeatureBounding() && meta.getFeatureType().getAttributeType(ati.getName()) instanceof GeometryAttributeType
+ && !tmp.contains(ati.getName()))
+ tmp.add(ati.getName());
}
//replace property names
So as you can see, if feature bounding is true, now all geometry properties are loaded and returned 
It was a test I made and committed by mistake, but it's not the
intended behaviour (is it? fun the tests now pass...).
Cheers
Andrea
Justin Deoliveira ha scritto:
All the tests are passing now except for one transaction test. I have
committed all the fixes minus one that i am waiting discussion about on
the geotools devel list.
I was able to make these tests pass by setting the featureBounding
property in the citewfs-1.1 configuration. However to truly fix the
issue the gml encoder needs to be hooked up to it. Right now it encodes
the bounds by default. I am scheduling a task for this.
Yeah, I noticed the old one (wfs 1.0, gml2) did not... but could not figure out how to make this configurable based on the "force feature bbox computation" configuration we have in the WFS service.
Cheers
Andrea