Menu
▾
▴
geotools-devel
|
From: Andrea A. <and...@ge...> - 2010-10-01 12:45:39
|
Hi,
the fancy app-schema I'm dealing with these days has the following twist:
<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>
See the metadata property? Well, GenericMetadata can contain xs:any.
And it's part
of the GML standard, not something made up for the occasion.
I wondering how one can make the above parseable, WFS queriable, and of course
generate it as GML3 output too. And coming out empty handed if I only
consider what GeoTools
can offer me.
One potential place to store those metadatas could be the geometry
user map... but it's
normally already busy with the CRS.
Even assuming it was free, the encoder would normally just ignore it...
And there would also be the issue of representing that nesting with
the complex data store
starting from the usual flat table. Does not seem to be doable either,
I mean, I see no
way to attach metadata read from a flat feature type into the geometries.
I guess I'll have to skip the geotools parser, write my own
(thankfully the structure
is always going to be the same so it's not too hard), store those metadata as a
property with multiplicity > 1, and when it's time to output, xlst it
into the right shape...
(and forget about making those metadata queriable)
Any better suggestion? :)
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
|
|
From: Jody G. <jod...@gm...> - 2010-10-01 12:49:54
|
Andrea can you store it on the GeometryAttribute somehow? There may be a user map or something for you to record extra information in. Jody On Fri, Oct 1, 2010 at 10:45 PM, Andrea Aime <and...@ge...> wrote: > Hi, > the fancy app-schema I'm dealing with these days has the following twist: > > <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> > > See the metadata property? Well, GenericMetadata can contain xs:any. > And it's part > of the GML standard, not something made up for the occasion. > > I wondering how one can make the above parseable, WFS queriable, and of course > generate it as GML3 output too. And coming out empty handed if I only > consider what GeoTools > can offer me. > > One potential place to store those metadatas could be the geometry > user map... but it's > normally already busy with the CRS. > > Even assuming it was free, the encoder would normally just ignore it... > > And there would also be the issue of representing that nesting with > the complex data store > starting from the usual flat table. Does not seem to be doable either, > I mean, I see no > way to attach metadata read from a flat feature type into the geometries. > > I guess I'll have to skip the geotools parser, write my own > (thankfully the structure > is always going to be the same so it's not too hard), store those metadata as a > property with multiplicity > 1, and when it's time to output, xlst it > into the right shape... > (and forget about making those metadata queriable) > > Any better suggestion? :) > > Cheers > Andrea > > > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > > ------------------------------------------------------------------------------ > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Andrea A. <and...@ge...> - 2010-10-01 14:23:10
|
On Fri, Oct 1, 2010 at 2:49 PM, Jody Garnett <jod...@gm...> wrote: > Andrea can you store it on the GeometryAttribute somehow? > There may be a user map or something for you to record extra information in. If was driving the code that could be a place. Unfortunately the metadata is inside the geometry, and the xml handler returns just a JTS geometry throwing away the rest. Not sure if the xml parsing would allow me to grab something parsed there and put it into an attribute (which is a couple of level up, since that polygon is also contained into a GeometryArrayProperty) Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- |
|
From: Justin D. <jde...@op...> - 2010-10-02 16:12:47
|
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. 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. 2c. -Justin On Fri, Oct 1, 2010 at 8:22 AM, Andrea Aime <and...@ge...>wrote: > On Fri, Oct 1, 2010 at 2:49 PM, Jody Garnett <jod...@gm...> > wrote: > > Andrea can you store it on the GeometryAttribute somehow? > > There may be a user map or something for you to record extra information > in. > > If was driving the code that could be a place. Unfortunately the > metadata is inside > the geometry, and the xml handler returns just a JTS geometry throwing away > the rest. Not sure if the xml parsing would allow me to grab something > parsed > there and put it into an attribute (which is a couple of level up, > since that polygon > is also contained into a GeometryArrayProperty) > > Cheers > Andrea > > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > > > ------------------------------------------------------------------------------ > 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
|
From: Andrea A. <and...@ge...> - 2010-10-02 17:34:26
|
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
--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
|
|
From: Gabriel R. <gr...@op...> - 2010-10-02 17:55:42
|
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 |
|
From: Justin D. <jde...@op...> - 2010-10-02 17:45:57
|
On Sat, Oct 2, 2010 at 11:34 AM, Andrea Aime <and...@ge...>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? > Again this is just an idea at this point but the idea would be to represent the geometry fully via the geotools feature model rather than a JTS geometry. So in very rough pseudo code: ComplexAttribute genericMetaData = createComplexAttribute(...) ComplexAttribute metadataProperty = createComplexAttribugte(..., genericMetadata) ... ComplexAttribute exterior = createCompexAttribute(...) ComplexAttribute polygon = createComplexAttribute(..., metadataProperty, polygon) And then pass the "polygon: ComplexAttribute to the encoder. And because the polygon is not a jts object the regualr GMLPolygonBinding would not execute. INstead processing would move up the binding chain to a binding that can generically encode any ComplexAttribute instance. Does that make any sense? > > 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 > > > -- > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
|
From: Andrea A. <and...@ge...> - 2010-10-02 18:04:52
|
On Sat, Oct 2, 2010 at 7:45 PM, Justin Deoliveira <jde...@op...> wrote: > Again this is just an idea at this point but the idea would be to represent > the geometry fully via the geotools feature model rather than a JTS > geometry. So in very rough pseudo code: > ComplexAttribute genericMetaData = createComplexAttribute(...) > ComplexAttribute metadataProperty = createComplexAttribugte(..., > genericMetadata) > ... > ComplexAttribute exterior = createCompexAttribute(...) > ComplexAttribute polygon = createComplexAttribute(..., metadataProperty, > polygon) > And then pass the "polygon: ComplexAttribute to the encoder. And because the > polygon is not a jts object the regualr GMLPolygonBinding would not execute. > INstead processing would move up the binding chain to a binding that > can generically encode any ComplexAttribute instance. > Does that make any sense? It does. At this point this begs the question of how I make the app schema store generate such structure. In the end I have to serve those as WFS 1.1, so on one side the DescribeFeatureType should report the schema with GML geoemtries, and on the GetFeature side there should be the app schema somehow building that structure and a custom binding generating the expected GML result. Hummm... not quite sure how to do that. As a backup plan I was thinking of creating a non GML structure with app schema like I reported before (the <GeometryWithMetadata> one) and then perform an XSLT transform towards the desired result. Maybe using a dispatcher callback that intercepts the GetFeature input and mangles the filters, its output to xslt it, and DescribeFeatureType to lie about the schema (as the app schema would report the modified one I'd use to drive the creation of <GeometryWithMetadata>. Oh my poor head... Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X