Re: [Geotools-devel] Parsing and encoding GML geometry metadata properties

[Gabriel R. <gr...@op...>]

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 <jde...@op...> 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
gr...@op...
Expert service straight from the developers