[Geoserver-devel] Stuck trying to encode versioned feature collection

Andrea_Aime3 · December 11, 2007, 6:31pm

Hi,
I basically spent the afternoon trying to get the WFSV versioned
feature collection encoded to no avail so far. Well, no avail
is an exxageration, I know what's going on, just don't know how
to fix it.

The versioned feature collection is supposed to contain
versioned features, that is, features whose schema has 4 extra
attributes such as author, date of last change, version
and commit comment.

Now, the returned GML3 looks like:

<wfs:FeatureCollection numberOfFeatures="2" timeStamp="2007-12-11T18:33:29.106+01:00" xsi:schemaLocation="http://www.opengis.net/wfsv http://localhost:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd http://www.openplans.org/topp http://localhost:8080/geoserver/wfs?service=WFSV&version=1.1.0&request=DescribeVersionedFeatureType&typeName=topp:archsites">
  <gml:featureMembers>
  <topp:archsites gml:id="archsites.26">
  <gml:boundedBy>
  <gml:Envelope srsName="http://www.opengis.net/gml/srs/epsg.xml#26713">
<gml:lowerCorner>604000.0 4930000.0</gml:lowerCorner>
<gml:upperCorner>604000.0 4930000.0</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<topp:cat>2</topp:cat>
<topp:str1>Alien crash site</topp:str1>
−
  <topp:the_geom>
−
  <gml:Point>
<gml:pos>604000.0 4930000.0</gml:pos>
</gml:Point>
</topp:the_geom>
</topp:archsites>
...

As you can see http://www.openplans.org/topp is bound to
an alternative DescribeFetaureType calls that will
return the extra feature types. Too bad the encoder
won't listen to it, and use a precanned schema
for topp:archsites that only contains the basic
attributes that comes from the WFSSchemaLocator object.
Now, if I change the config to return a plain SchemaLocator
I'm greeted by a nice NPE (the FeaturePropertyExtractor
fails to find the element declaration in schema index).

Now, the WFSSchemaLocator builds schemas using the
FeatureTypeSchemaBuidler, so I used the one I use
the create describe feature type in the first place (which
makes features extending AbstactVersionedFeatureType,
which in turn does have the 4 extra attributes), but I keep on getting only the base attributes...

Why is this happening? Confused...
Cheers
Andrea

Justin_Deoliveira · December 11, 2007, 11:17pm

Ok, after a lot of debugging I have some answers. First off, apologies.
The feature type building stuff was not meant to be extended in this
way, hence the problems. Fixing some of these issues is somethign i have
wanted to but not had that much time. I have the geotools part done with
the better xsd management, but have not gotten around to fixing the
geoserver schema management. As I said before it is doing some silly
things like hacking the wfs schema object directly, which his just plain
wrong. Anyways, enough whining and on to some answers.

So, the reason why you do not see the additional attributes is because
the VErsionedSchemaBuilder was still using the proper gml schema, which
has no notion of the versioned feature type. You were on the right track
with trying to implement the schema locator to build the correct schema.
However, there is a pretty severe issue with this. It has to do with the
fact that hte types are in the wfs schema itself. Anyways long story
short when the schema is built a circular dependency occurs and kaboom,
stack overflow. The issue is more of an implementation issue. But as i
said before it is not trivial, and part of it is fixed on trunk, not on
2.4.x

So... moving along, I tried building the schema so that the
AbstractVersionedFeautreType is in the gml namespace, and not wfsv. This
worked somewhat. There are still some issues with how the encoder is
being set up:

1. It is encoding WFS.FeatureCollection, when it should be encoding
WFSV.VersionedFeatureCollection.

2. The xsd definition for VersionedFeatureCollection does not seem to
refrence the "_VersionedFeature" element at all. Which means again the
encoder misses the required versioning attributes, only asking the
bindigns for the one defined by "_Feature".

And the light at the end of the title... creating a
VersionedPropertyExtractor which returns the versioned properties
directly, this is what Gabriel suggested. However I did not suggest this
at first because the whole PropertyExtractor interface is again a hack
and something that I plan to fix on trunk so that it is unnecessary.
However a quick test and it did work.

So the only question is will it be possible to move the versioned
feature type definition to the gml namespace?

-Justin

Andrea Aime wrote:

Hi,
I basically spent the afternoon trying to get the WFSV versioned
feature collection encoded to no avail so far. Well, no avail
is an exxageration, I know what's going on, just don't know how
to fix it.

The versioned feature collection is supposed to contain
versioned features, that is, features whose schema has 4 extra
attributes such as author, date of last change, version
and commit comment.

Now, the returned GML3 looks like:

<wfs:FeatureCollection numberOfFeatures="2"
timeStamp="2007-12-11T18:33:29.106+01:00"
xsi:schemaLocation="http://www.opengis.net/wfsv
http://localhost:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd
http://www.openplans.org/topp
http://localhost:8080/geoserver/wfs?service=WFSV&version=1.1.0&request=DescribeVersionedFeatureType&typeName=topp:archsites">
  <gml:featureMembers>
  <topp:archsites gml:id="archsites.26">
  <gml:boundedBy>
  <gml:Envelope srsName="http://www.opengis.net/gml/srs/epsg.xml#26713">
<gml:lowerCorner>604000.0 4930000.0</gml:lowerCorner>
<gml:upperCorner>604000.0 4930000.0</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<topp:cat>2</topp:cat>
<topp:str1>Alien crash site</topp:str1>
−
  <topp:the_geom>
−
  <gml:Point>
<gml:pos>604000.0 4930000.0</gml:pos>
</gml:Point>
</topp:the_geom>
</topp:archsites>
...

As you can see http://www.openplans.org/topp is bound to
an alternative DescribeFetaureType calls that will
return the extra feature types. Too bad the encoder
won't listen to it, and use a precanned schema
for topp:archsites that only contains the basic
attributes that comes from the WFSSchemaLocator object.
Now, if I change the config to return a plain SchemaLocator
I'm greeted by a nice NPE (the FeaturePropertyExtractor
fails to find the element declaration in schema index).

Now, the WFSSchemaLocator builds schemas using the
FeatureTypeSchemaBuidler, so I used the one I use
the create describe feature type in the first place (which
makes features extending AbstactVersionedFeatureType,
which in turn does have the 4 extra attributes), but I keep on getting
only the base attributes...

Why is this happening? Confused...
Cheers
Andrea

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,475ed7a7277718362916074!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Andrea_Aime3 · December 12, 2007, 8:25am

Justin Deoliveira ha scritto:

Ok, after a lot of debugging I have some answers. First off, apologies.
The feature type building stuff was not meant to be extended in this
way, hence the problems. Fixing some of these issues is somethign i have
wanted to but not had that much time. I have the geotools part done with
the better xsd management, but have not gotten around to fixing the
geoserver schema management. As I said before it is doing some silly
things like hacking the wfs schema object directly, which his just plain
wrong. Anyways, enough whining and on to some answers.

So, the reason why you do not see the additional attributes is because
the VErsionedSchemaBuilder was still using the proper gml schema, which
has no notion of the versioned feature type. You were on the right track
with trying to implement the schema locator to build the correct schema.
However, there is a pretty severe issue with this. It has to do with the
fact that hte types are in the wfs schema itself. Anyways long story
short when the schema is built a circular dependency occurs and kaboom,
stack overflow. The issue is more of an implementation issue. But as i
said before it is not trivial, and part of it is fixed on trunk, not on
2.4.x

So... moving along, I tried building the schema so that the
AbstractVersionedFeautreType is in the gml namespace, and not wfsv. This
worked somewhat. There are still some issues with how the encoder is
being set up:

1. It is encoding WFS.FeatureCollection, when it should be encoding
WFSV.VersionedFeatureCollection.

Right, I did not manage to get that far with my tests

2. The xsd definition for VersionedFeatureCollection does not seem to
refrence the "_VersionedFeature" element at all. Which means again the
encoder misses the required versioning attributes, only asking the
bindigns for the one defined by "_Feature".

Hum... there are a couple of problems I can see here:
* xml wise having a plain FeatureCollection contain _VersionedFeature
   is ok, since _VersionedFeature is in the _Feature substitution group.
   But there is no way to tell the encoder to use it, right? In theory,
   if the query is against multiple types, I may end up having to answer
   with both _Feature (for non versioned types) and _VersionedFeature
   (for the versioned ones)
* schema wise, how do I make a VersionedFeatureCollection that extends
   the normal WFS FeatureCollection but it's restricted to use
   _VersionedFeature instead? Afaik restriction works only on simple
   types?

And the light at the end of the title... creating a
VersionedPropertyExtractor which returns the versioned properties
directly, this is what Gabriel suggested. However I did not suggest this
at first because the whole PropertyExtractor interface is again a hack
and something that I plan to fix on trunk so that it is unnecessary.
However a quick test and it did work.

I'll follow this path.

So the only question is will it be possible to move the versioned
feature type definition to the gml namespace?

Hmm... yeah, but if the property extractor thing allows me to keep
it in the wfsv namespace, that would seem better, xml wise, to me?
Cheers
Andrea

Justin_Deoliveira · December 12, 2007, 10:27am

Hum... there are a couple of problems I can see here:
* xml wise having a plain FeatureCollection contain _VersionedFeature
  is ok, since _VersionedFeature is in the _Feature substitution group.
  But there is no way to tell the encoder to use it, right? In theory,
  if the query is against multiple types, I may end up having to answer
  with both _Feature (for non versioned types) and _VersionedFeature
  (for the versioned ones)
* schema wise, how do I make a VersionedFeatureCollection that extends
  the normal WFS FeatureCollection but it's restricted to use
  _VersionedFeature instead? Afaik restriction works only on simple
  types?

I believe you could use extension via restriction. And then override
"featureMember" to reference "_VersionedFeature" instead. However that
limits anything else you can put on "VersionedFeatureCollection".
Inheiretence with xml schema is kind of rigid unforunately.

And the light at the end of the title... creating a
VersionedPropertyExtractor which returns the versioned properties
directly, this is what Gabriel suggested. However I did not suggest this
at first because the whole PropertyExtractor interface is again a hack
and something that I plan to fix on trunk so that it is unnecessary.
However a quick test and it did work.

I'll follow this path.

So the only question is will it be possible to move the versioned
feature type definition to the gml namespace?

Hmm... yeah, but if the property extractor thing allows me to keep
it in the wfsv namespace, that would seem better, xml wise, to me?

Well the main issue here is the issue with how the schemas are built.
While this is possible from an xml schema point of view, i am not sure
it will work all that well, like i said when i tried to do it it lead to
a circular dependency between the wfsv and gml schemas being built.

Which brings up another question about the wfsv namespace? I am sure
this has come up before but I cant quite remember the rationale for
putting all the operations in a different namespace? Instead of just
using the wfs one, and including, rather then importing the wfs schema
proper.

Cheers
Andrea

!DSPAM:4007,475f9b02254233362379201!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Andrea_Aime3 · December 12, 2007, 10:38am

Justin Deoliveira ha scritto:

Hum... there are a couple of problems I can see here:
* xml wise having a plain FeatureCollection contain _VersionedFeature
  is ok, since _VersionedFeature is in the _Feature substitution group.
  But there is no way to tell the encoder to use it, right? In theory,
  if the query is against multiple types, I may end up having to answer
  with both _Feature (for non versioned types) and _VersionedFeature
  (for the versioned ones)
* schema wise, how do I make a VersionedFeatureCollection that extends
  the normal WFS FeatureCollection but it's restricted to use
  _VersionedFeature instead? Afaik restriction works only on simple
  types?

I believe you could use extension via restriction. And then override
"featureMember" to reference "_VersionedFeature" instead. However that
limits anything else you can put on "VersionedFeatureCollection".
Inheiretence with xml schema is kind of rigid unforunately.

Can you make an example of how this can be achieved for the old man?
I can only find restrictions examples using simple types on the net.

And the light at the end of the title... creating a
VersionedPropertyExtractor which returns the versioned properties
directly, this is what Gabriel suggested. However I did not suggest this
at first because the whole PropertyExtractor interface is again a hack
and something that I plan to fix on trunk so that it is unnecessary.
However a quick test and it did work.

I'll follow this path.

So the only question is will it be possible to move the versioned
feature type definition to the gml namespace?

Hmm... yeah, but if the property extractor thing allows me to keep
it in the wfsv namespace, that would seem better, xml wise, to me?

Well the main issue here is the issue with how the schemas are built.
While this is possible from an xml schema point of view, i am not sure
it will work all that well, like i said when i tried to do it it lead to
a circular dependency between the wfsv and gml schemas being built.

Which brings up another question about the wfsv namespace? I am sure
this has come up before but I cant quite remember the rationale for
putting all the operations in a different namespace? Instead of just
using the wfs one, and including, rather then importing the wfs schema
proper.

Well, it just seemed cleaner since wfs-v it's only an experimental
extension, not an official wfs thing. But I did not put that much thoughts in it, I just did it

Cheers
Andrea

Justin_Deoliveira · December 12, 2007, 11:01am

Can you make an example of how this can be achieved for the old man?
I can only find restrictions examples using simple types on the net.

Actually looking at the type of AbstractFeatureCollection type i am not
sure it is possible, because it uses a ref to gml:featureMemeber. I am
not sure you can add a restriction to change this. I would have to pull
out an xml schema guide to figure out if this is possible.

Well, it just seemed cleaner since wfs-v it's only an experimental
extension, not an official wfs thing. But I did not put that much
thoughts in it, I just did it

Fair enough. But I think the same namespace would have been cleaner.
Take WFS-T with wfs 1.0 schemas as an example. That is a clean extension
via an include in the same namespace.

Cheers
Andrea

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,475fba2a295611096210785!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org