Thanks for the review Andrea. Comments inline.
On Wed, Jun 22, 2011 at 1:01 AM, Andrea Aime
<[email protected]>wrote:
> On Tue, Jun 21, 2011 at 1:35 AM, Justin Deoliveira
> <[email protected]>wrote:
>
>> Hi all,
>>
>> The past couple of weeks i have been working on adding joins to the
>> geotools query api in support of joins in wfs 2. The work goes well and i
>> have a working implementation for the jdbc modules that has been tested with
>> postgis, h2, and oracle.
>>
>> The proposal is here:
>>
>> http://docs.codehaus.org/display/GEOTOOLS/Join+Support
>>
>> Review and feedback welcome. The referenced jira issue has a patch.
>>
>> I would like to *note* though, this proposal is only for the api changes
>> and does not include the jdbc implementation. I plan to treat that as
>> a separate issue/change. There is also some more testing and cleanup that
>> needs to occur there before a presentable patch can emerge.
>>
>
> Hi Justin,
> I finally found some time to read the proposal for good.
> Generally speaking it seems good, I have two questions:
> - what about joins done just for the sake of filtering? "Find all the POIs
> inside a park" would
> not need to return any park. Would be good to have that option in the
> join
> - not sure about the WFS 2.0 specifics, but I believe you can choose which
> properties of
> each returned feature type need to be included in the result?
> I see now that the Join class actually has the list of properties, yet I
> did not see it while
> reading the proposal.
>
Will update the proposal to make that more evident.
>
> About the first, would it make sense to have yet another join type,
> public static enum Type {
> INNER, OUTER, LEFT, RIGHT, FILTER
> }
>
> where FILTER would instruct the machinery not to return the features from
> joined
> feature type.
>
Yeah that makes sense. I can add that in.
> I'm not 100% sure, but there should also be some way to express this in WFS
> queries,
> wouldn't it?
>
Would be nice for sure... to be able to get a regular feature collection
back with a join (and not tuples). But reading through the spec it seems to
imply that if you do a join query you must return features from all the
types, via a tuple. Although as an extension perhaps we can allow the user
to specify the mode and support this. Or maybe I am missing something int
the spec.
>
> Besides this detail, +1
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
