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. ------------------------------------------------------------------------------ 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
