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 > > ------------------------------------------------------------------------------ > _______________________________________________ > Geotools-gt2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users ------------------------------------------------------------------------------ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
