Hi,
wfs 1.1.0 basic tests are failing for me.
Now, tests failing have a null feature bbox whilst they should have
bounds according to the suite.
Yet, in those requests, only non geometric attributes are requested,
and the feature type in the sample data states the geometries
are nullable:
<xsd:complexType name="PrimitiveGeoFeatureType">
<xsd:complexContent>
<xsd:extension base="gml:AbstractFeatureType">
<xsd:sequence>
<xsd:element name="surfaceProperty" minOccurs="0" type="gml:SurfacePropertyType" />
<xsd:element name="pointProperty" minOccurs="0" type="gml:PointPropertyType" />
<xsd:element name="curveProperty" minOccurs="0" type="gml:CurvePropertyType" />
<xsd:element name="intProperty" type="xsd:integer" />
<xsd:element name="uriProperty" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="measurand" type="xsd:float" />
<xsd:element name="dateTimeProperty" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="dateProperty" type="xsd:date" minOccurs="0"/>
<xsd:element name="decimalProperty">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:totalDigits value="4"/>
<xsd:fractionDigits value="2" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
So, it seem that user complaing about not having the bbox around
when geometry properties were not around was right?
Justin, is there any magic switch I have to turn on to make cite
tests pass?
Cheers
Andrea
Hi Andrea,
Nope, there is no magic switch or anything. I know the getFeature code
supplements any requested attributes with those attributes which are
required by the schema, but as we see in this case none of them are.
Although I seem to remember coming up against this issue...
Its kind of a tough call. If you ask me the right answer is that
features should always return a bounds even if the feature is not
carrying around any geometric attributes. The rationale being that we
model our features on gml and gml says that every feature has a
boundedBy attribute. But as you well know our implementation dynamically
calculates the boundedBy attributes from other attributes...
I wonder if we always supplemented the list of attributes with those
geometric ones it would throw off cite... Although in this case that
would mean picking up three additional attributes.. uggh, nasty.
Andrea Aime wrote:
Hi,
wfs 1.1.0 basic tests are failing for me.
Now, tests failing have a null feature bbox whilst they should have
bounds according to the suite.
Yet, in those requests, only non geometric attributes are requested,
and the feature type in the sample data states the geometries
are nullable:
<xsd:complexType name="PrimitiveGeoFeatureType">
<xsd:complexContent>
<xsd:extension base="gml:AbstractFeatureType">
<xsd:sequence>
<xsd:element name="surfaceProperty" minOccurs="0"
type="gml:SurfacePropertyType" />
<xsd:element name="pointProperty" minOccurs="0"
type="gml:PointPropertyType" />
<xsd:element name="curveProperty" minOccurs="0"
type="gml:CurvePropertyType" />
<xsd:element name="intProperty" type="xsd:integer" />
<xsd:element name="uriProperty" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="measurand" type="xsd:float" />
<xsd:element name="dateTimeProperty" type="xsd:dateTime"
minOccurs="0"/>
<xsd:element name="dateProperty" type="xsd:date" minOccurs="0"/>
<xsd:element name="decimalProperty">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:totalDigits value="4"/>
<xsd:fractionDigits value="2" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
So, it seem that user complaing about not having the bbox around
when geometry properties were not around was right?
Justin, is there any magic switch I have to turn on to make cite
tests pass?
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,467fd8e692331961014482!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hi Andrea,
Nope, there is no magic switch or anything. I know the getFeature code
supplements any requested attributes with those attributes which are
required by the schema, but as we see in this case none of them are.
Although I seem to remember coming up against this issue...
Its kind of a tough call. If you ask me the right answer is that
features should always return a bounds even if the feature is not
carrying around any geometric attributes. The rationale being that we
model our features on gml and gml says that every feature has a
boundedBy attribute. But as you well know our implementation dynamically
calculates the boundedBy attributes from other attributes...
I wonder if we always supplemented the list of attributes with those
geometric ones it would throw off cite... Although in this case that
would mean picking up three additional attributes.. uggh, nasty.
Ok, but what I'm wondering here is... how is it that cite tests passed
for reference and 1.6.0-alpha2... and what did change? Is it my own
db, some code change, what?
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
Nope, there is no magic switch or anything. I know the getFeature code
supplements any requested attributes with those attributes which are
required by the schema, but as we see in this case none of them are.
Although I seem to remember coming up against this issue...
Its kind of a tough call. If you ask me the right answer is that
features should always return a bounds even if the feature is not
carrying around any geometric attributes. The rationale being that we
model our features on gml and gml says that every feature has a
boundedBy attribute. But as you well know our implementation dynamically
calculates the boundedBy attributes from other attributes...
I wonder if we always supplemented the list of attributes with those
geometric ones it would throw off cite... Although in this case that
would mean picking up three additional attributes.. uggh, nasty.
Ok, but what I'm wondering here is... how is it that cite tests passed
for reference and 1.6.0-alpha2... and what did change? Is it my own
db, some code change, what?
Good question, but something is definitely going on. I am porting the
wfs test cases from ows branch to trunk and getting failures because of
this issue... continuing to look into it.
Cheers
Andrea
!DSPAM:4007,468005a0182914901796417!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
AFAIK gml:name, gml:description and gml:bounds are all optional in GML 3.1.1
I think if you want to populate it, for a feature with no geometry (or one you dont understand ) you would need to do so with a GML null value
RA
Justin Deoliveira wrote:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
Nope, there is no magic switch or anything. I know the getFeature code
supplements any requested attributes with those attributes which are
required by the schema, but as we see in this case none of them are.
Although I seem to remember coming up against this issue...
Its kind of a tough call. If you ask me the right answer is that
features should always return a bounds even if the feature is not
carrying around any geometric attributes. The rationale being that we
model our features on gml and gml says that every feature has a
boundedBy attribute. But as you well know our implementation dynamically
calculates the boundedBy attributes from other attributes...
I wonder if we always supplemented the list of attributes with those
geometric ones it would throw off cite... Although in this case that
would mean picking up three additional attributes.. uggh, nasty.
Ok, but what I'm wondering here is... how is it that cite tests passed
for reference and 1.6.0-alpha2... and what did change? Is it my own
db, some code change, what?
Good question, but something is definitely going on. I am porting the
wfs test cases from ows branch to trunk and getting failures because of
this issue... continuing to look into it.
Cheers
Andrea
!DSPAM:4007,468005a0182914901796417!
Hmmm... I could be wrong but when i read through the spec I interpreted
the boundedBy property to *not* be a refection of the attributes present
on the feature instance, but the actual real world bounds of the
feature. I could be wrong though... this is probably a question best
answered on the wfs-dev list.
-Justin
Rob Atkinson wrote:
AFAIK gml:name, gml:description and gml:bounds are all optional in GML
3.1.1
I think if you want to populate it, for a feature with no geometry (or
one you dont understand ) you would need to do so with a GML null value
RA
Justin Deoliveira wrote:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
Nope, there is no magic switch or anything. I know the getFeature code
supplements any requested attributes with those attributes which are
required by the schema, but as we see in this case none of them are.
Although I seem to remember coming up against this issue...
Its kind of a tough call. If you ask me the right answer is that
features should always return a bounds even if the feature is not
carrying around any geometric attributes. The rationale being that we
model our features on gml and gml says that every feature has a
boundedBy attribute. But as you well know our implementation
dynamically
calculates the boundedBy attributes from other attributes...
I wonder if we always supplemented the list of attributes with those
geometric ones it would throw off cite... Although in this case that
would mean picking up three additional attributes.. uggh, nasty.
Ok, but what I'm wondering here is... how is it that cite tests passed
for reference and 1.6.0-alpha2... and what did change? Is it my own
db, some code change, what?
Good question, but something is definitely going on. I am porting the
wfs test cases from ows branch to trunk and getting failures because of
this issue... continuing to look into it.
Cheers
Andrea
!DSPAM:4007,46806291286902143011171!
-------------------------------------------------------------------------
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/
!DSPAM:4007,46806291286902143011171!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,46806291286902143011171!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org