Hello Akos, Do I get this right that your are implementing this AixmDataStore which returns complex features, in other words you are not using app-schema but building your own complex features? If so, you shouldn't be using the interface DataStore because it is derived from DataAccess<SimpleFeatureType, SimpleFeature> which returns simple features. Have a look at AppSchemaDataAccess class which is derived from DataAccess<FeatureType, Feature> and therefore returns a complex feature source with getFeatureSource. You should be doing the same.
The typename is passed because a data store is assumed to be able to store different feature types. Am I right to assume your data store would only host one feature type? Then perhaps you can ignore it or, probably more consistent with the API, expect one single type name and throw an exception if another one is requested. About SLD, I am not really sure what you are trying to do here. SLD supports X-paths on complex feature types to retrieve property values. These property values can be used in filters. Some examples can be found here: http://docs.geoserver.org/latest/en/user/data/app-schema/wms-support.html Kind Regards Niels On 03/11/2013 04:17 AM, Ben Caradoc-Davies wrote: > Sorry Ákos, I do not know about WMS to answer these. Niels, are you > able to help? I think you might have had to address these issues. > > Kind regards, > Ben. > > On 06/03/13 22:04, Ákos Maróy wrote: >> Hi, >> >> After a really lot of preliminary work, I've started to implement a data >> store object that would work off AIXM documents - basically documents >> based on GML 3.2 and a set of other XML Schemas. My initial intention is >> to simply read such documents as files into memory, and then use these >> data stores to render content via SLDs. The basic code would look >> something like this: >> >> MapContent = new MapContent(); >> AixmDataStore ds = new AixmDataStore("/some/aixm.file"); >> Style style = ... >> FeatureLayer layer = new FeatureLayer(dataStore.getFeatureXXX(), style); >> map.addLayer(layer); >> >> >> and then render this map object. >> >> my knowledge is inadequate now on at least two points here. one is, for >> complex features, would one use DataStore.getFeatureSource(), which >> returns a SimpleFeatureSource, or would one use getFeatureReader()? but >> the latter cannot be supplied to a FeatureLayer() constructor call. >> >> moreover, DataStore.getFeatureSource() expects a 'typeName', which I >> can't really properly comprehend here, as all queries would be done >> later, which should simple go through all the data. >> >> >> my second area for lack of knowledge is about SLD filters in such cases. >> SLD filters seem to work well for 'flat' data, say checking if a column >> value in a database table matches a value, by using the >> <ogc:PropertyIsEqualTo/> element, etc. but in this case, the natural >> 'query language' would be XPath, where XPath statements pretty much >> contain themselves - there is no need to match against something. >> >> for example, if I want to get all elements of type<aixm:VOR>, then I >> can express it simply by the XPath statement "//aixm:VOR" - and this >> statement will simply result in the elements I'm looking for. or if I >> want to match a certain node value, I can say "//aixm:type[text() = >> 'VOR']" - here again, this is a unary predicate. but I don't see a way >> to express this in SLD, say for example: >> >> <sld:FeatureTypeStyle> >> <sld:Name>foo</sld:Name> >> <sld:Rule> >> <ogc:Filter> >> <ogc:UnaryPredicate>//aixm:VOR</ogc:UnaryPredicate> >> </ogc:Filter> >> ... >> </sld:Rule> >> </sld:FeatureTypeStyle> >> >> >> >> most probably I'm totally missing something obvious, of course :) >> >> >> Akos >> >> >> ------------------------------------------------------------------------------ >> >> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the >> endpoint security space. For insight on selecting the right partner to >> tackle endpoint security challenges, access the full report. >> http://p.sf.net/sfu/symantec-dev2dev >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
