Hi guys,
Yes, the ability to join on custom filters was done intentionally, mostly to
support spatial joins. If app-schema were to move to this api for joining
for the time being maybe it would be possible just to throw an exception.
If you look at the join class it has a Type property which is an
enumeration, INNER, OUTER, etc... so allows you to specify the type of join
you wish to do.
It is probably best to think about this specific proposal as "joining for
simple features" (I can see the look of disdain now). In the proposal
document I propose what the schema of "joined feature" should look like, but
don't mention any restriction about how actual features are returned which
was sort of intentional. In my case indeed i intent to return the same
feature multiple times, as would happen in an SQL query. I realize this is
not the app-schema / complex feature way but perhaps we can keep that an
implementation detail? Maybe we assume that any DataStore (DataStore here
meaning simple features) follows the SQL semantics, and anything not
implementing DataStore (DataAccess) will return complex features. Or perhaps
we declare the behaviour somewhere in QueryCapabilities. Not sure. Anywho,
if possible I would like to keep this proposal with just the api... and
again hopefully keep how the features are returned to be an implementation
detail.
-Justin
On Mon, Jun 20, 2011 at 10:06 PM, Niels <[email protected]> wrote:
> **
> Hi Justin,
>
> Your proposal looks a lot like what I did in the 'JoiningQuery' class in
> app-schema.
> The difference is though that this supports joining on custom filters while
> my implementation only allows to joining field expressions to be specified
> (so there is always a "=" comparison).
> I think some of my code can be re-used, have a look at it.
> This would have huge implications for app-schema though, the joining
> extensions would need to be rewritten for a great part when geotools
> supports joining (something I won't be around for anymore...)
>
> Questions are, though, which kind of join is performed: inner/left outer ?
> And what Rob said, what will you do with multiple rows being joined to the
> same parent feature? Return multiple times the same feature with different
> joined features, or allow multiple joined features of the same type in one
> feature?
> It seems to me that you need some form of complex features as data model to
> cover all this.
>
> Regards,
> Niels
>
>
> On 21/06/11 07:35, Justin Deoliveira 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.
>
> Thanks folks.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> --
> *Niels Charlier*
>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Phone: +61 8 6436 8914
>
> Australian Resources Research Centre
> 26 Dick Perry Avenue, Kensington WA 6151
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel