[Geoserver-devel] Broken GML3OutputFormat feature type name assumption

[Ben_Caradoc-Davies]

Jody,

I have run into a problem at the last step of getting GeoServer to encode a complex feature WFS response. I hope you can help by suggesting a way forward.

GeoServer GML3OutputFormat uses org.geotools.feature.FeatureCollection.getSchema() to get the FeatureType that is to be returned (the content model), and uses it to find the name of the WFS feature type, to locate the FeatureTypeInfo in the catalog. GML3OutputFormat appears to make the unwarranted assumption that the WFS feature type name is the same as the XML schema type name. In general, this is not the case. For example, in GeoSciML we have a WFS feature type gsml:MappedFeature which has XML schema type gsml:MappedFeatureType.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model for an XML schema element declaration. [This is the type returned by getSchema().]
(2) The XML element declaration defines the WFS feature type and name. [This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I see that a concrete feature collection implementation was used that allowed access to the underlying feature attribute descriptor, and hence the WFS feature type name.

A possible solution is to add a getName() method to FeatureCollection to allow the discovery of the WFS feature type name used to create the FeatureCollection. This will require modification of numerous implementations. To avoid changing many implementations, I could instead add a new interface (e.g. NamedFeatureCollection) extending FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[simon.cox]

To re-inforce the point, here are a couple of extracts from GML 3.2 spec (equally applicable to GML 3.1, GML 3.0, GML 2.X but never quite spelled out before):

===
9.8 Defining application-specific feature types
All specific feature types defined in application schemas shall be implemented as global XML elements whose content model (XML Schema types) are derived from gml:AbstractFeatureType,

21.3.3 Elements representing features
All geographic features and feature collections in the application schema shall be declared as global elements in the schema, i.e. they shall be immediate child elements of the XML Schema <schema> element.
The name of an element that instantiates a GML feature shall be its feature type, in the sense described in ISO 19109.

The key point here is that each UML Class (feature type) is implemented by an XML Element.
The XML Schema types are just apparatus used by XML Schema to build element declarations, and are of no interest externally.

Simon

______
Simon.Cox@anonymised.com CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151
PO Box 1130, Bentley WA 6102 AUSTRALIA
T: +61 (0)8 6436 8639 Cell: +61 (0) 403 302 672
Polycom PVX: 130.116.146.28
<http://www.csiro.au>

ABN: 41 687 119 230

-----Original Message-----
From: Caradoc-Davies, Ben (E&M, Kensington)
Sent: Thursday, 12 March 2009 11:45 AM
To: Jody Garnett
Cc: Gabriel Roldan; Justin Deoliveira; Atkinson, Rob (CLW,
Lucas Heights); Geotools-Devel list; Geoserver-devel; Cox,
Simon (E&M, Kensington)
Subject: Broken GML3OutputFormat feature type name assumption

Jody,

I have run into a problem at the last step of getting
GeoServer to encode a complex feature WFS response. I hope
you can help by suggesting a way forward.

GeoServer GML3OutputFormat uses
org.geotools.feature.FeatureCollection.getSchema() to get the
FeatureType that is to be returned (the content model), and
uses it to find the name of the WFS feature type, to locate
the FeatureTypeInfo in the catalog. GML3OutputFormat appears
to make the unwarranted assumption that the WFS feature type
name is the same as the XML schema type name.
In general, this is not the case. For example, in GeoSciML we
have a WFS feature type gsml:MappedFeature which has XML
schema type gsml:MappedFeatureType.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the
content model for an XML schema element declaration. [This is
the type returned by getSchema().]
(2) The XML element declaration defines the WFS feature type
and name.
[This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I
see that a concrete feature collection implementation was
used that allowed access to the underlying feature attribute
descriptor, and hence the WFS feature type name.

A possible solution is to add a getName() method to
FeatureCollection to allow the discovery of the WFS feature
type name used to create the FeatureCollection. This will
require modification of numerous implementations. To avoid
changing many implementations, I could instead add a new
interface (e.g. NamedFeatureCollection) extending
FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> Software
Engineer, CSIRO Exploration and Mining Australian Resources
Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[jive]

Ack that is a lot of people CCed on this message - is the
geotools-developer list a sufficient venue for this discussion?

On Thu, Mar 12, 2009 at 1:44 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

Jody,

I have run into a problem at the last step of getting GeoServer to encode a
complex feature WFS response. I hope you can help by suggesting a way
forward.

Let me see if I can help.

GeoServer GML3OutputFormat uses
org.geotools.feature.FeatureCollection.getSchema() to get the FeatureType
that is to be returned (the content model), and uses it to find the name of
the WFS feature type, to locate the FeatureTypeInfo in the catalog.

Okay. This is the split between "descriptor" and "type" as described
in the feature model. I am not sure how this breakdown occurs exactly
in the WFS specification - I believe describeFeatureType should be
documented in terms of the element name (which will refer to the XML
type definition).

GML3OutputFormat appears to make the unwarranted assumption that the WFS
feature type name is the same as the XML schema type name. In general, this
is not the case. For example, in GeoSciML we have a WFS feature type
gsml:MappedFeature which has XML schema type gsml:MappedFeatureType.

Agreed.

We want our schema getName() to return "MappedFeature"; since that is
what describeFeatureType will be called with.

A couple ideas:
- I suspect this may just be a bug; but you should check against the
WFS specification to be sure. I would hate to put in time on this one
just to learn that there is a gap in the WFS documentation (it has
happened before)
- I mentioned the difference between descriptor and type. In your
example the feature collection memberof relationship should be a
MappedFeature descriptor that is of type MappedFeatureType. We need
this level of separation if we are to publish two different data sets
that are of the same type.
- Something to watch out for ... GeoServer has the ability to perform
some retyping of information between the raw data source and what is
returned; usually this takes the form of removing properties that we
do not wish to publish; or patching up the type name (usually just the
namespace however). You could choose to expand these capabilities to
allow for being clear about the name. So that the FeatureCollection
returned does have the name you require.
- As a short term measure you could make use of client properties to
and store the information you need in the FeatureType itself. This
facility is intended to allow applications to provide extra
information such as this (you could even store the FeatureTypeInfo).
However we will need to identify that the instance of FeatureType
returned from datastore.getSchema( typeName ) is infact used by your
returned FeatureCollection (or if a bunch of wrapping is going on due
to the post processing mentioned in the previous step we would need to
ensure the client properties are passed along from the origional
"source" feature type)

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model for an
XML schema element declaration. [This is the type returned by getSchema().]

Agreed; but getSchema() is a short cut for getMemberDescriptor().getType().

(2) The XML element declaration defines the WFS feature type and name. [This
is the feature attribute descriptor name.]

Agreed - this is what getMemberDescriptor() is.

In this case we are capturing the relationship between a feature
collection and its members. This is an aggregation relationship that
is named by the descriptor.

Looking at the old GeoServer 1.6 community-schemas fork, I see that a
concrete feature collection implementation was used that allowed access to
the underlying feature attribute descriptor, and hence the WFS feature type
name.

That is what was in the geoapi featurecollection interface as well; we
did drop this interface and perhaps not all the required depth was
moved into the geotools feature collection interface? You will need to
check for me.

A possible solution is to add a getName() method to FeatureCollection to
allow the discovery of the WFS feature type name used to create the
FeatureCollection.

In the OGC reference model where a feature collection is a feature
getName is already taken; they use "member" to capture this
relationship.

This will require modification of numerous
implementations. To avoid changing many implementations, I could instead add
a new interface (e.g. NamedFeatureCollection) extending FeatureCollection,
and use instanceof in GML3OutputFormat.

Which would you prefer?

I would prefer we clean up the FeatureCollection interface and make
the descriptor available.

Jody

[jive]

Good afternoon Simon:

Thanks for supporting Ben, I think he managed to make his point already.

To review a few notes from earlier discussion on FeatureCollection....

As I understand it these discussions stalled due to noticing two things:
- FeatureCollection was not defined in the ISO specification (when we
got our hands on it)
- the needs of the OGC Reference Model (ie an aggregation association)
could be represented by a FeatureType as it stands
- the FeatureType for a collection could contain an association
describing the contents. The association would have a name
("MappedFeature" in Ben's example) the type of that association would
capture the nature of the relationship (temporal, aggregation etc) and
the nature of the content (ie "gsml:MappedFeatureType" in Ben's
example).

Reviewing project history
(http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal) I
found this described as:
- FeatureCollectionType.getMemberDescriptor()
- and this was viewed as formalization of an association that should
already be documented by FeatureType
- FeatureCollection is now acting as a "query result" only - so no
FeatureType is available to document matters as described above

So here is a solid recommendation for Ben:
- Add a FeaturCollection.getDescriptor() to capture this information
- The name of the association would be getDescriptor().getName()
- The nature of the association would be captured as getDescriptor().getType()
- The member type would be captured as getSchmea() - would then be
defined as getDescriptor().getType().getRelatedType()

Jody

[Justin_Deoliveira]

As far as I know the one geoserver assumption/convention has always been the feature type name matches the element (as Ben stated).

With the assumption that xml schema type the for that element is <featureTypeName>_Type or <featureTypeName>Type.

In the old catalog model, on FeatureTypeInfo there was the property "schemaBase", which I believe the point of which is to manually specify what the xml schema type name is. However it was never hooked up properly so it is something that did not really survive the revamp. We could consider reviving this functionality... but I guess in this case it is beneficial to have the data store tell us what the xml schema type should be, rather then have the user specify it.

I am hesitant to add stuff to FeatureCollection for specific needs of GML/WFS. One of the problems I have always had with FeatureCollection is that it is indeed too GMLish, which makes it hard to use for the 90% case.

-Justin

Ben Caradoc-Davies wrote:

Jody,

I have run into a problem at the last step of getting GeoServer to encode a complex feature WFS response. I hope you can help by suggesting a way forward.

GeoServer GML3OutputFormat uses org.geotools.feature.FeatureCollection.getSchema() to get the FeatureType that is to be returned (the content model), and uses it to find the name of the WFS feature type, to locate the FeatureTypeInfo in the catalog. GML3OutputFormat appears to make the unwarranted assumption that the WFS feature type name is the same as the XML schema type name. In general, this is not the case. For example, in GeoSciML we have a WFS feature type gsml:MappedFeature which has XML schema type gsml:MappedFeatureType.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model for an XML schema element declaration. [This is the type returned by getSchema().]
(2) The XML element declaration defines the WFS feature type and name. [This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I see that a concrete feature collection implementation was used that allowed access to the underlying feature attribute descriptor, and hence the WFS feature type name.

A possible solution is to add a getName() method to FeatureCollection to allow the discovery of the WFS feature type name used to create the FeatureCollection. This will require modification of numerous implementations. To avoid changing many implementations, I could instead add a new interface (e.g. NamedFeatureCollection) extending FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[Andrea_Aime3]

Ben Caradoc-Davies ha scritto:

Jody,

I have run into a problem at the last step of getting GeoServer to encode a complex feature WFS response. I hope you can help by suggesting a way forward.

GeoServer GML3OutputFormat uses org.geotools.feature.FeatureCollection.getSchema() to get the FeatureType that is to be returned (the content model), and uses it to find the name of the WFS feature type, to locate the FeatureTypeInfo in the catalog. GML3OutputFormat appears to make the unwarranted assumption that the WFS feature type name is the same as the XML schema type name. In general, this is not the case. For example, in GeoSciML we have a WFS feature type gsml:MappedFeature which has XML schema type gsml:MappedFeatureType.

That assumption is valid in the current state of the things.
You're changing the rules of the game, you're making the assumption
unwarranted. I'd kind of a user saying that GeoServer is making
the "unwarranted assumption" that line labels should be straight
whilst he needs them to be curved. That's new functionality, not a bug.

To be honest, yesterday I stopped reading your mail right here, also
considering you made the GeoServer-dev list more or less just witnesses
of a conversation between you and Jody to start with.
Anyways, seeing the direction this whole thread is taking, let me
try to sound in anyways.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model for an XML schema element declaration. [This is the type returned by getSchema().]
(2) The XML element declaration defines the WFS feature type and name. [This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I see that a concrete feature collection implementation was used that allowed access to the underlying feature attribute descriptor, and hence the WFS feature type name.

A possible solution is to add a getName() method to FeatureCollection to allow the discovery of the WFS feature type name used to create the FeatureCollection. This will require modification of numerous implementations. To avoid changing many implementations, I could instead add a new interface (e.g. NamedFeatureCollection) extending FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

A different collection interface would be preferred, no need to add
extra xml specific concerns in all the use cases that do not require
it.

But quite frankly, this seems unnecessary too. In this JIRA
http://jira.codehaus.org/browse/GEOT-2385
you state:
"When GeoServer invokes an OutputFormat, it has no access to the WFS feature type name, only the name that can be determined from the FeatureCollection.getSchema(), which is the content model type name"

Reality is different, as you have full access to the Operation
even in the encoder, meaning this code (which I grabbed from
the GML3OutputFormat superclass):

GetFeatureType request = (GetFeatureType) OwsUtils.parameter(operation.getParameters(),
                     GetFeatureType.class);

will give you full access to the parsed WFS request.
You just have to scan the list of Query and you get access to the
original type name requested by the user. There is a 1-1 correspondence
between the nth QueryType and the nth FeatureCollection (which I believe
it's mandated by the WFS spec).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[jive]

Taking this to geoserver-devel; Ben if you have people that would like
to follow this discussion they can sign up.

A different collection interface would be preferred, no need to add
extra xml specific concerns in all the use cases that do not require
it.

But quite frankly, this seems unnecessary too. In this JIRA
http://jira.codehaus.org/browse/GEOT-2385
you state:
"When GeoServer invokes an OutputFormat, it has no access to the WFS feature
type name, only the name that can be determined from the
FeatureCollection.getSchema(), which is the content model type name"

Reality is different, as you have full access to the Operation
even in the encoder, meaning this code (which I grabbed from
the GML3OutputFormat superclass):

Thanks Andrea that is a much better solution; I would prefer not to
mess with the FeatureCollection interface; indeed we are trying to
reduce its scope to something Justin can stand.

Jody

[Gabriel_Roldan2]

Justin Deoliveira <jdeolive@anonymised.com> escribió:

As far as I know the one geoserver assumption/convention has always been
the feature type name matches the element (as Ben stated).

IMHO it is not an assumption nor a convention, but a HACK. A very old amd known one that deserves to be fixed. The origin of it is two fold: by one side our old feature model wasnt able to distinguish between type and instance names. By the other the hack was introduced due to this limitation driven by the WFS spec examples where type names are element names plus the "_Type" prefix, where there wouldn't have been any problem in calling them exactly the same:
<complexType name="Foo">...
</complexType>
<element name="Foo" type="Foo"/>

strange but legal.
By the other side, being forced to call all the type instances the same than the type is like being forced to call all your java variables of type String "String": private String String = "my string";

With the assumption that xml schema type the for that element is
<featureTypeName>_Type or <featureTypeName>Type.

In the old catalog model, on FeatureTypeInfo there was the property
"schemaBase", which I believe the point of which is to manually specify
what the xml schema type name is. However it was never hooked up
properly so it is something that did not really survive the revamp. We
could consider reviving this functionality... but I guess in this case
it is beneficial to have the data store tell us what the xml schema type
should be, rather then have the user specify it.

I am hesitant to add stuff to FeatureCollection for specific needs of
GML/WFS. One of the problems I have always had with FeatureCollection is
that it is indeed too GMLish, which makes it hard to use for the 90% case.

it is _not_ a GML/WFS specific issue, but a General Feature Model one, the one the Feature API is based on. It just _happens_ that Ben is facing this gap in our imnplementation due to his more complex use case than the usual "serve a table from the db and I don't care how it is called". If it happens that there's no point in having the Feature API based on the GFM at all we could as easily get rid of the whole API and use Map<String, Object> instead of Feature. I don't think that is the case though.

So, to make my point a little bit more clear:
- We're already providing a descriptor for SimpleFeature instances coming from a db table, aren't we? ie: SimpleFeature f = fc.features().next(); assert f.getDescriptor() != null;
- In the case of simple features coming from a db table it is totally fine for the descriptor and the featuretype to be called the same (eg, "ROAD"). And that's what we're already doing.
- To make this change explicit, as part of the port from the old to the new feature model, FeatureCollection.getSchema() should have been _replaced_ by FeatureCollection.getContentDescriptor() or whatever it may be called.
- And finally, this is a little bit less obvious, to encode a FeatureCollection as GML you don't really should need this, though it helps.
   * explanation: you don't need this because (correct me if I'm wrong) the only reason you want the content descriptor and content type is to figure out the namespaces being used so you can declare them at the wfs:FeatureCollection root element. Otherwise you can just go iterate the feature collection and encode the features as they apppear, not even needing all the features in the collection to be of the same type. Instead what we're doing (I think) right now is to declare in wfs:FeatureCollection all the namespaces configured in geoserver even if they're not going to be used on the gml document at all.
But that is _not_ enough to Ben/Application Schemas neither, because due to the nature of these schemas, it may well happen that there are feature attributes in other namespaces than the top level, configured one. Indeed that's the common case rather than the exception with app schemas.
So I concur that Ben needs the descriptor for the fc contents to get to both the actual feature name and also to inspect the type in deep and figure out which other namespaces are used by attributes so they can be declared and hence the resulting document be valid.

And note that this is such a need that if there's too much resistence to add (or better replace) FC.getSchema by FC.getContentDescriptor, Ben will still be able to do achieve his gloal by getting the descriptor from the first feature instance in the collection.... but we don't want to force him to that hack

My 2c.-

Gabriel

-Justin

Ben Caradoc-Davies wrote:

Jody,

I have run into a problem at the last step of getting GeoServer to
encode a complex feature WFS response. I hope you can help by suggesting
a way forward.

GeoServer GML3OutputFormat uses
org.geotools.feature.FeatureCollection.getSchema() to get the
FeatureType that is to be returned (the content model), and uses it to
find the name of the WFS feature type, to locate the FeatureTypeInfo in
the catalog. GML3OutputFormat appears to make the unwarranted assumption
that the WFS feature type name is the same as the XML schema type name.
In general, this is not the case. For example, in GeoSciML we have a WFS
feature type gsml:MappedFeature which has XML schema type
gsml:MappedFeatureType.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model
for an XML schema element declaration. [This is the type returned by
getSchema().]
(2) The XML element declaration defines the WFS feature type and name.
[This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I see that a
concrete feature collection implementation was used that allowed access
to the underlying feature attribute descriptor, and hence the WFS
feature type name.

A possible solution is to add a getName() method to FeatureCollection to
allow the discovery of the WFS feature type name used to create the
FeatureCollection. This will require modification of numerous
implementations. To avoid changing many implementations, I could instead
add a new interface (e.g. NamedFeatureCollection) extending
FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Justin_Deoliveira]

groldan@anonymised.com wrote:

Justin Deoliveira <jdeolive@anonymised.com> escribió:

As far as I know the one geoserver assumption/convention has always been
the feature type name matches the element (as Ben stated).

IMHO it is not an assumption nor a convention, but a HACK. A very old amd known one that deserves to be fixed. The origin of it is two fold: by one side our old feature model wasnt able to distinguish between type and instance names. By the other the hack was introduced due to this limitation driven by the WFS spec examples where type names are element names plus the "_Type" prefix, where there wouldn't have been any problem in calling them exactly the same:
<complexType name="Foo">...
</complexType>
<element name="Foo" type="Foo"/>

Call it what you will but the HACK works just fine for the 95% case, or any format that is not GML.

strange but legal.
By the other side, being forced to call all the type instances the same than the type is like being forced to call all your java variables of type String "String": private String String = "my string";

With the assumption that xml schema type the for that element is
<featureTypeName>_Type or <featureTypeName>Type.

In the old catalog model, on FeatureTypeInfo there was the property
"schemaBase", which I believe the point of which is to manually specify
what the xml schema type name is. However it was never hooked up
properly so it is something that did not really survive the revamp. We
could consider reviving this functionality... but I guess in this case
it is beneficial to have the data store tell us what the xml schema type
should be, rather then have the user specify it.

I am hesitant to add stuff to FeatureCollection for specific needs of
GML/WFS. One of the problems I have always had with FeatureCollection is
that it is indeed too GMLish, which makes it hard to use for the 90% case.

it is _not_ a GML/WFS specific issue, but a General Feature Model one, the one the Feature API is based on. It just _happens_ that Ben is facing this gap in our imnplementation due to his more complex use case than the usual "serve a table from the db and I don't care how it is called". If it happens that there's no point in having the Feature API based on the GFM at all we could as easily get rid of the whole API and use Map<String, Object> instead of Feature. I don't think that is the case though.

Sure, call it a "General Feature Model" issue, but what is the only realistic application of it... GML :). When i think "general" I don't think GML application schemas, I think of the flat structure that 99% of spatial data in the world has. My point was that in the past adding stuff to the FC interface to be able to handle the "General Feature model" case has made the class very hard to implement. If you want proof look at the type hierarchy of FeatureCollection in geotools now, it is an utter and complete mess. Any ways my point is don't push complexity on everyone just to handle a single case. I am with Andrea and would prefer a separate class or interface be developed for this purpose.

So, to make my point a little bit more clear:
- We're already providing a descriptor for SimpleFeature instances coming from a db table, aren't we? ie: SimpleFeature f = fc.features().next(); assert f.getDescriptor() != null;
- In the case of simple features coming from a db table it is totally fine for the descriptor and the featuretype to be called the same (eg, "ROAD"). And that's what we're already doing.
- To make this change explicit, as part of the port from the old to the new feature model, FeatureCollection.getSchema() should have been _replaced_ by FeatureCollection.getContentDescriptor() or whatever it may be called.
- And finally, this is a little bit less obvious, to encode a FeatureCollection as GML you don't really should need this, though it helps.
  * explanation: you don't need this because (correct me if I'm wrong) the only reason you want the content descriptor and content type is to figure out the namespaces being used so you can declare them at the wfs:FeatureCollection root element. Otherwise you can just go iterate the feature collection and encode the features as they apppear, not even needing all the features in the collection to be of the same type. Instead what we're doing (I think) right now is to declare in wfs:FeatureCollection all the namespaces configured in geoserver even if they're not going to be used on the gml document at all.
But that is _not_ enough to Ben/Application Schemas neither, because due to the nature of these schemas, it may well happen that there are feature attributes in other namespaces than the top level, configured one. Indeed that's the common case rather than the exception with app schemas.
So I concur that Ben needs the descriptor for the fc contents to get to both the actual feature name and also to inspect the type in deep and figure out which other namespaces are used by attributes so they can be declared and hence the resulting document be valid.

And note that this is such a need that if there's too much resistence to add (or better replace) FC.getSchema by FC.getContentDescriptor, Ben will still be able to do achieve his gloal by getting the descriptor from the first feature instance in the collection.... but we don't want to force him to that hack

My 2c.-

Gabriel

-Justin

Ben Caradoc-Davies wrote:

Jody,

I have run into a problem at the last step of getting GeoServer to
encode a complex feature WFS response. I hope you can help by suggesting
a way forward.

GeoServer GML3OutputFormat uses
org.geotools.feature.FeatureCollection.getSchema() to get the
FeatureType that is to be returned (the content model), and uses it to
find the name of the WFS feature type, to locate the FeatureTypeInfo in
the catalog. GML3OutputFormat appears to make the unwarranted assumption
that the WFS feature type name is the same as the XML schema type name.
In general, this is not the case. For example, in GeoSciML we have a WFS
feature type gsml:MappedFeature which has XML schema type
gsml:MappedFeatureType.

As Simon Cox kindly explained to me yesterday:
(1) The XML schema complex type definition provides the content model
for an XML schema element declaration. [This is the type returned by
getSchema().]
(2) The XML element declaration defines the WFS feature type and name.
[This is the feature attribute descriptor name.]

Looking at the old GeoServer 1.6 community-schemas fork, I see that a
concrete feature collection implementation was used that allowed access
to the underlying feature attribute descriptor, and hence the WFS
feature type name.

A possible solution is to add a getName() method to FeatureCollection to
allow the discovery of the WFS feature type name used to create the
FeatureCollection. This will require modification of numerous
implementations. To avoid changing many implementations, I could instead
add a new interface (e.g. NamedFeatureCollection) extending
FeatureCollection, and use instanceof in GML3OutputFormat.

Which would you prefer?

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------

Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[Andrea_Aime3]

groldan@anonymised.com ha scritto:
...

And note that this is such a need that if there's too much resistence to add (or better replace) FC.getSchema by FC.getContentDescriptor, Ben will still be able to do achieve his gloal by getting the descriptor from the first feature instance in the collection.... but we don't want to force him to that hack

Ok, let's assume for a moment we go for the change described in
http://jira.codehaus.org/browse/GEOT-2385, that is,
"Extend FeatureCollection by adding getDescriptor()"

My first reaction is... why just FeatureCollection? From what
I know:
- featureCollection.getSchema() is, in the common case, only
   a reflection of featureSource.getSchema() (factoring in
   the eventual changes due to Query attribute filtering)
- featureSource.getSchema() is, in the common case, only a
   reflection of dataStore.getSchema(<typeName>)

So, if we don't consider for a moment sources and collection
that do their own transformations, why is it ok to add
getDescriptor() only to FeatureCollection?
If the "General Feature Model" really requires a descriptor
for the feature type, then why don't we have also:
FeatureSource.getDescriptor(typeName)
DataAccess.getDescriptor(typeName)

Just adding it to FeatureCollection seems a way to deal with a
contingent issue in WFS encoding, but breaks consistency.
If this is the case, you can create a WFSFeatureCollection
in the WFS module that gives you what you need in terms of
XML schema descriptors and be done with it.
(the encoders implementation should do
instanceof checks, as they are soon to be used in
WPS output where, in the normal case, no app schema is involved).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Ben_Caradoc-Davies]

Thanks, Gabriel, for your detailed response.

groldan@anonymised.com wrote:

- And finally, this is a little bit less obvious, to encode a FeatureCollection as GML you don't really should need this, though it helps.

Indeed, it is not needed for encoding. The need is even more prosaic: we *only* need the WFS type name (element name) to retrieve the FeatureTypeInfo from the catalog. From there, the Encoder can be persuaded to Do The Right Thing.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Ben_Caradoc-Davies]

Justin Deoliveira wrote:

groldan@anonymised.com wrote:

Justin Deoliveira <jdeolive@anonymised.com> escribió:

As far as I know the one geoserver assumption/convention has always been
the feature type name matches the element (as Ben stated).

IMHO it is not an assumption nor a convention, but a HACK.

Call it what you will but the HACK works just fine for the 95% case, or any format that is not GML.

This only looks like a 5% case from the GeoServer point of view because very few people using application schemas use GeoServer, because application schemas are not well supported. This is a chicken and egg problem.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Ben_Caradoc-Davies]

Andrea Aime wrote:

But quite frankly, this seems unnecessary too. In this JIRA
http://jira.codehaus.org/browse/GEOT-2385
you state:
"When GeoServer invokes an OutputFormat, it has no access to the WFS feature type name, only the name that can be determined from the FeatureCollection.getSchema(), which is the content model type name"

Reality is different, as you have full access to the Operation
even in the encoder, meaning this code (which I grabbed from
the GML3OutputFormat superclass):

GetFeatureType request = (GetFeatureType) OwsUtils.parameter(operation.getParameters(),
                     GetFeatureType.class);

will give you full access to the parsed WFS request.
You just have to scan the list of Query and you get access to the
original type name requested by the user. There is a 1-1 correspondence
between the nth QueryType and the nth FeatureCollection (which I believe
it's mandated by the WFS spec).

Andrea, you are a champion. This looks to be several orders of magnitude less painful than any API change. I will try this.

Many thanks,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Gabriel_Roldan2]

On Saturday 14 March 2009 05:51:21 Andrea Aime wrote:

groldan@anonymised.com ha scritto:
…

And note that this is such a need that if there’s too much resistence
to add (or better replace) FC.getSchema by FC.getContentDescriptor,
Ben will still be able to do achieve his gloal by getting the
descriptor from the first feature instance in the collection… but
we don’t want to force him to that hack

Ok, let’s assume for a moment we go for the change described in
http://jira.codehaus.org/browse/GEOT-2385, that is,
“Extend FeatureCollection by adding getDescriptor()”

My first reaction is… why just FeatureCollection? From what
I know:

• featureCollection.getSchema() is, in the common case, only
  a reflection of featureSource.getSchema() (factoring in
  the eventual changes due to Query attribute filtering)
• featureSource.getSchema() is, in the common case, only a
  reflection of dataStore.getSchema()

So, if we don’t consider for a moment sources and collection
that do their own transformations, why is it ok to add
getDescriptor() only to FeatureCollection?
If the “General Feature Model” really requires a descriptor
for the feature type, then why don’t we have also:
FeatureSource.getDescriptor(typeName)
DataAccess.getDescriptor(typeName)
As per the introduction of DataAccess, both DataAccess and FeatureSource work upon the “descriptor name” and not the name of the type. If you check the documentation in FeatureSource.getName(), my impression is it was introduced for this same reason. So, given a FeatureSource we already can know the name of the descriptors it creates, given a FeatureCollection we cannot. I’m open to any solution that given a FC allows to know the name of the contained features and not only their type name.

Just keep in mind that FeatureSource now has both getSchema() and getName(), FeatureCollection doesn’t.

Cheers,

Gabriel

Just adding it to FeatureCollection seems a way to deal with a
contingent issue in WFS encoding, but breaks consistency.
If this is the case, you can create a WFSFeatureCollection
in the WFS module that gives you what you need in terms of
XML schema descriptors and be done with it.
(the encoders implementation should do
instanceof checks, as they are soon to be used in
WPS output where, in the normal case, no app schema is involved).

Cheers
Andrea

Gabriel Roldan
http://www.opengeo.org

[Gabriel_Roldan2]

On Friday 13 March 2009 08:36:35 Jody Garnett wrote:

Taking this to geoserver-devel; Ben if you have people that would like
to follow this discussion they can sign up.

A different collection interface would be preferred, no need to add
extra xml specific concerns in all the use cases that do not require
it.

But quite frankly, this seems unnecessary too. In this JIRA
http://jira.codehaus.org/browse/GEOT-2385
you state:
“When GeoServer invokes an OutputFormat, it has no access to the WFS
feature type name, only the name that can be determined from the
FeatureCollection.getSchema(), which is the content model type name”

Reality is different, as you have full access to the Operation
even in the encoder, meaning this code (which I grabbed from
the GML3OutputFormat superclass):

Thanks Andrea that is a much better solution; I would prefer not to
mess with the FeatureCollection interface; indeed we are trying to
reduce its scope to something Justin can stand.

Indeed Andrea your solution is good as far as getting the feature name in the encoder stands. I just wanted to point out that going from FeatureSource to Featurecollection one looses the ability to know beforehand how those features are to be called, FeatureSource has getName(), FC doesn’t. And wonder how much that impacts more code than Ben’s one once we start getting used to work over the more general DataAccess/Feature apis. (ie, everytime there’s a feature collection right now it is assumed its features are named the same than the schema, which is only a good solution -or better a coincidence- for controlled types like shapefiles and database tables as far as how they’re implemented, but not for app-schemas nor for a WFSDataStore).

That said, I’m perhaps being too picky about FC which is not my focus at all, I’m all for getting it as thin as possible, and I should have backed my opinion by a more exhaustive evaluation of where in the code that’s going to be a problem. But at least we agree there’s a gap in loosing the ability to get the descriptor name when going from FeatureSource to FeatureCollection.

Cheers,

Gabriel.

Jody

---

— Apps built with the Adobe(R) Flex(R) framework and Flex Builder™ are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse™based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
http://www.opengeo.org

[Andrea_Aime3]

Gabriel Roldán ha scritto:

On Friday 13 March 2009 08:36:35 Jody Garnett wrote:
> Taking this to geoserver-devel; Ben if you have people that would like
> to follow this discussion they can sign up.
>
> > A different collection interface would be preferred, no need to add
> > extra xml specific concerns in all the use cases that do not require
> > it.
> >
> > But quite frankly, this seems unnecessary too. In this JIRA
> > http://jira.codehaus.org/browse/GEOT-2385
> > you state:
> > "When GeoServer invokes an OutputFormat, it has no access to the WFS
> > feature type name, only the name that can be determined from the
> > FeatureCollection.getSchema(), which is the content model type name"
> >
> > Reality is different, as you have full access to the Operation
> > even in the encoder, meaning this code (which I grabbed from
> > the GML3OutputFormat superclass):
>
> Thanks Andrea that is a much better solution; I would prefer not to
> mess with the FeatureCollection interface; indeed we are trying to
> reduce its scope to something Justin can stand.

Indeed Andrea your solution is good as far as getting the feature name in the encoder stands. I just wanted to point out that going from FeatureSource to Featurecollection one looses the ability to know beforehand how those features are to be called, FeatureSource has getName(), FC doesn't. And wonder how much that impacts more code than Ben's one once we start getting used to work over the more general DataAccess/Feature apis. (ie, everytime there's a feature collection right now it is assumed its features are named the same than the schema, which is only a good solution -or better a coincidence- for controlled types like shapefiles and database tables as far as how they're implemented, but not for app-schemas nor for a WFSDataStore).

That said, I'm perhaps being too picky about FC which is not my focus at all, I'm all for getting it as thin as possible, and I should have backed my opinion by a more exhaustive evaluation of where in the code that's going to be a problem. But at least we agree there's a gap in loosing the ability to get the descriptor name when going from FeatureSource to FeatureCollection.

I would not say no about the idea of adding getName() to
FeatureCollection, as at least we're not breaking existing client
code with that change.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.