I believe at some point in history we lacked Property.userData but had PropertyDescriptor.userData, which was cumbersome, then Property.userData was added and that's where we _could_ store this kind of metadata, as long as: - app-schema config allows to map database properties to Property/Attribute/Feature userData with a clientProperty mapping. - There's a common understanding (contract) for what kind of object is expected there for the specific case of GeometryAttribute, since it has a binding to JTS geometry already (and hence flattens out what's a complex property in the schema to a simple one in the gt object model) geomAtt.getUserData().put(GML.metadataProperty, List<? extends Property>, if you get my pseudo code (where GML.metadataProperty is a QName).
may something like that work? Gabriel On Sat, 2010-10-02 at 19:34 +0200, Andrea Aime wrote: > On Sat, Oct 2, 2010 at 6:12 PM, Justin Deoliveira <[email protected]> > wrote: > > Yeah, unfortunately this is a nasty issue. Rob has had this issue before as > > well. > > On the encoding front the plan was to instead of create a geometry not as a > > jts geometry but as a generic complex attribute. And then have the encoding > > subsystem ignore the regular geometry binding (since it is not a geometry > > object) and encode it (along with the metadta) as a generic complex > > attribute. > > Wow wow, slow down a little. This seems like a nice idea but I've lost you > at the beginning of the sentence :-) > > So say in the database I store something like: > > <GeometryWithMetadata> > <myMetadata>... > <myGeometry>... > </GeometryWithMetadata> > > How do I go then to turn it into a GML geometry with with metadata like: > > <gml:Polygon> > <gml:metaDataProperty> > <gml:GenericMetaData> > <extention> > <area uom="m2">8476875.000000</area> > <length uom="m">108.706000</length> > <width uom="m">13.863100</width> > </extention> > </gml:GenericMetaData> > </gml:metaDataProperty> > <gml:exterior> > <gml:LinearRing> > <gml:posList> > 31.214218 43.833347 31.215328 43.833862 31.216240 43.833717 ... > </gml:posList> > </gml:LinearRing> > </gml:exterior> > </gml:Polygon> > > Do you have some code skeleton I can follow? > > > The parsing front is much harder as Andrea noted. What has been done in the > > past for cases like this and what I think the app-schema folks do is use the > > geometry user data as Andrea noted. But storing a map there that can store > > anything from the crs to this generic metadata. A hack to me sure but not > > sure we have much else. Unless we introduced some sort of geometry wrapper > > that stored all the metadata explicitly. > > All in all rolling your own parser is probably better for your sanity since > > the parsing story for complex features is not quite there yet when compared > > to the encoding story. > > Cool > > Cheers > Andrea > > -- Gabriel Roldan [email protected] Expert service straight from the developers ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
