Hi Jody, thanks for your response. This probably would mean significant reworking of the application, and I just have a few questions before doing so:
- Is there a FeatureCollection for handling and filtering of FeatureImpl objects? Trying to store a FeatureImpl in a DefaultFeatureCollection throws a ClassCastException. - Can the Geotools StreamingRenderer also work with FeatureImpl objects? - Are there important differences in this regard (using FeatureImpl) between 2.5.8 (which I'm still using) and the current 2.6.2 release? Thanks again & kind regards, Thorsten Jody Garnett schrieb: > For this idea you do not want to use a SimpleFeatureImpl; what you have a is > a more general "Feature" that is not under the same restrictions. > > A simple feature is our own "subclass" of Feature that is set up to match the > case where the attributes are ordered and not complex (ie not a relationship > or a nested feature such as your describe). I think of them as "records" in > a file; or rows in a database ... nothing more. > > So grab FeatureImpl and you should be good to go. > > Such features are kind of exotic and we only really have the "App Schema" > data access in GeoTools producing them. That said we are doing our best to > support them and are keen to learn from your experience. > > Jody > > > > On 24/04/2010, at 5:16 AM, Thorsten Reitz wrote: > >> Hi all, >> >> I have a SimpleFeatureImpl object with several properties, some of which >> are complex, i.e. they are themselves Features, as in this example: >> >> + CadastralParcel >> + inspireId (IdentifierType) >> - namespace (String) >> - localid (String) >> - versionId (String) >> + geographicalName (GeographicalNameType) >> + spelling (SpellingOfNameType) >> - script (String) >> - text (String) >> - transliteration (String) >> >> In my application, I often have to directly set such a nested property >> (e.g. "script" under spelling of geographicalname). For that purpose, I >> also need to create all missing Features "on the path", in this case, >> spelling. >> >> I have now found that at runtime, these complex properties are actually >> of type SimpleFeatureImpl$Attribute, which is a non-public inner class >> and therefore cannot be accessed directly. This is an issue for me since >> I am trying to create such complex properties and to add them to a >> Feature after the feature has been created. >> >> This is the source code I am using so far (which fails obviously): >> http://community.esdi-humboldt.eu/repositories/entry/cst/eu.esdihumboldt.cst.corefunctions/src/main/java/eu/esdihumboldt/cst/corefunctions/RenameAttributeFunction.java?rev=3473 >> >> Relevant lines #: around 75 to 100. >> >> I'd welcome any insights or ideas on how I could solve this issue. My >> current guess would be to subtype SimpleFeatureImpl (to change the >> behaviour of creating/returning attribute objects when the object in >> question is actually a Feature), but I'd welcome other ideas... >> >> Kind regards, >> >> Thorsten >> >> -- >> Thorsten Reitz >> >> Fraunhofer-Institut für Graphische Datenverarbeitung IGD >> [email protected] | www.igd.fraunhofer.de -- Thorsten Reitz Fraunhofer-Institut für Graphische Datenverarbeitung IGD [email protected] | www.igd.fraunhofer.de ------------------------------------------------------------------------------ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
