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