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 <[email protected]> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
