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