Was not able to find much:
- http://docs.codehaus.org/display/GEOTOOLS/Expr+Examples
- http://gtirc.blogspot.com/2004/09/data-query-informal-followup.html
- http://docs.codehaus.org/display/GEOTOOLS/IRC+Breakout+Number+1
--
Jody Garnett
On Tuesday, 14 June 2011 at 8:43 AM, Jody Garnett wrote:
> Just have time to add to your random thoughts ...
>
> With respect to cross datastore joins; a current project gives me a scope to
> join you on this work (or help clean up some of the mess depending on your
> deadlines). My focus is pretty narrow - to enable a shapefile to be joined
> with a CSV file by ID.
>
> -------
> There is an old proposal with code on this topic from David Zwiers (from last
> time they tried to add it to wfs).
>
> From what I remember:
> - Query gained more methods to support "As" functionality; this resulted in a
> normal feature collection in which the attributes had been renamed. This was
> generally useful and not specific to "Join".
> - A class Join was created; that combined two queries; with similar use of
> PropertyEquals to define the join
> - DataStore.getFeatures(Join) was created to allow people to issue the request
> - Repository.getFeatures(Join) was created - for cross datastore joins. Today
> I would handle that as featureSource.join( FeatureSource, Join )
> - I like this a bit better than your proposal as Query stays pretty focused
> and is reused during the join
> --------
> There was also the design of adding methods to feature source; allowing it to
> be used rather than feature collection. Personally I think it may be a
> smoother way to handle Join.
>
> // query includes the "as" expressions used to rename attributes
> FeatureSource left = featureSource.getFeatureSource( typeName1 ).query(
> query1 );
> FeatureSource right = featureSource.getFeatureSource( typeName2 ).query(
> query2 );
>
> // join is a method on feature source
> FeatureSource join1 = left.join( right, List<PropertyEquals> );
> FeatureSource join2 = left.join( right, Join );
>
> --------
> For your discussion on the different kinds of features that could result; I
> would assume that the resulting structure would match the xpath expressions
> used during the join? Or does the specification give us any feedback here?
>
> --
> Jody Garnett
>
>
> On Tuesday, 14 June 2011 at 5:16 AM, Justin Deoliveira wrote:
>
> > Hi all,
> >
> > The last major bit of the wfs 2 work is joins. I wanted to start some
> > discussion here and post some questions with regard to the work.
> >
> > So with the wfs protocol you can do queries now that look like this:
> >
> > <wfs:Query typeNames="myns:Person myns:Person" aliases="a b">
> > <fes:Filter>
> > <fes:And>
> > <fes:PropertyIsEqualTo>
> > <fes:ValueReference>a/Identifier</fes:ValueReference>
> > <fes:Literal>12345</fes:Literal>
> > </fes:PropertyIsEqualTo>
> > <fes:PropertyIsEqualTo>
> > <fes:ValueReference>a/spouse<fes:ValueReference>
> > <fes:ValueReference>b/Identifier</fes:ValueReference>
> > </fes:PropertyIsEqualTo>
> > </fes:And>
> > </fes:Filter>
> > </wfs:Query>
> >
> > The result is a feature collection that does not contain only feature
> > members, but tuples of feature members. Something like:
> >
> > <wfs:member>
> > <wfs:Tuple>
> > <wfs:member>
> > <ns1:FeatureTypeOne>...</ns1:FeatureTypeOne>
> > </wfs:member>
> > <wfs:member>
> > <ns1:FeatureTypeTwo>...</ns1:FeatureTypeTwo>
> > </wfs:member>
> > </wfs:Tuple>
> > </wfs:member>
> >
> > With that providing a bit of context I would like to bring up some points
> > of discussion.
> >
> > * app-schema vs simple features
> >
> > With knowing zero about app-schema currently I believe there is the ability
> > to do joins via feature chaining. However my impression is that these
> > relationships are configured before hand and not really created on the fly?
> > Correct me if I am wrong.
> >
> > So perhaps we could just say that we support joins with app-schema and call
> > it a day. However that said I do think there is a case for supporting joins
> > with simple features as well. And to be honest working with app-schema,
> > because of the learning curve, would be out of scope for this project.
> >
> > * cross datastore joins
> >
> > When talking about doing joins there are varying levels of complexity. For
> > instance talking about supporting joins of feature types within a jdbc
> > datastore is one thing. Supporting joining say a shapefile feature type to
> > a jdbc feature type is a total different ball of wax. Doing cross datastore
> > joins is something i think would be neat... but far from trivial to do it
> > in a way that scales. A much simpler problem would be joining two feature
> > types within the same datastore. However still unless the datastore is one
> > that can do joins natively (jdbc is really the only one here) it is still a
> > hard problem. For instance consider attempting to join two Shapefile
> > feature types from the same datastore... doable but again difficult to do
> > in a non naive way.
> >
> > * query interface
> >
> > Given that only some datastores can do joins efficiently makes it a good
> > candidate for QueryCapabilities with the addition of a method
> > "isJoiningSupported". That interface change is relatively straight forward.
> > However one that is not is how to modify Query (if that is the way to go)
> > to support joins. I can think of a few different strategies:
> >
> > 1. Not modify it at all and come up with a new interface called
> > "JoinSupportingDataStore" or something that adds some new methods for joins.
> >
> > 2. Subclass Query and add some new join methods. Looking around I actually
> > notice that there is some code in app-schema that does just this called
> > JoiningQuery
> >
> > 3. Modify Query directly to add support for joins
> >
> > Thoughts? When I thought about the alternatives I thought (3) made the most
> > sense. Especially given how we support other concepts that are not
> > supported in all datastores like sorting.
> >
> > So I decided to go further with (3), and added a class called "Join", that
> > looks something like the following:
> >
> > class Join {
> >
> > /** the feature type being joined to */
> >
> > String getTypeName();
> >
> > /** the attributes from the joined feature type to select */
> >
> > List<PropertyName> getProperties()
> >
> > /** the join filter */
> >
> > Filter getJoinFilter();
> >
> > /** additional filter to apply to the feature type being joined to */
> >
> > Filter getFilter();
> >
> > }
> >
> > And then it was a matter of modifying Query adding a new property.
> >
> > class Query {
> >
> > List<Join> getJoins();
> >
> > }
> >
> > So with this api the above query would look something like this:
> >
> > Query q = new Query("Persons");
> > q.setFilter(PropertyIsEqualTo(PropertyName("Identifer"), Literal(12345)));
> >
> > Join j = new Join("Persons");
> > j.setJoinFilter(PropertyIsEqualTo(PropertyName("spouse"),
> > PropertyName("Identifer")));
> > q.getJoins().add(j);
> >
> > That is obviously simplified quite a bit... there still a few things to
> > iron out like handling name clashes, etc... but that would be the general
> > idea. Thoughts?
> >
> > * joined features
> >
> > Another major question is what should the result of a join look like? Given
> > that the current return from a query is features I thought it best to stick
> > with that not come up with some new class or something to represent a tuple
> > (although maybe that is something worth considering). I thought of a few
> > different alternatives. To illustrate consider two feature types:
> >
> > f1 (name, geometry)
> > f2 (name, foo, geom)
> >
> > 1. Return a single feature with attributes from joined feature types
> > "rolled into it". So the resulting joined feature would look like:
> >
> > f'(name, geometry, name, foo, geom)
> >
> > 2. Return a single feature that contains attributes for joined features:
> >
> > f'(name, geometry, f2)
> >
> > 3. Return a single feature that contains attributes for all features in the
> > join
> >
> > f'(f1,f2)
> >
> > All methods have their various issues. (1) for instance requires that we
> > break simple feature rules since we have two attributes with the same local
> > name.
> >
> > (2) requires us to have attribute types that are SimpleFeatureType. Which I
> > don't think technically violates simple feature rules although admittedly
> > not something that happens often.
> >
> > (3) Same more or less as (2) but more represents the notion of the "tuple".
> > Question is what id to give to the feature? If any?
> >
> > Pretty open to suggestions on this one... i imagine there is probably a
> > better solution than any of those three. In the end with the prototype i
> > decided to go with (2). Seemed the least invasive.
> >
> > * join types
> >
> > Joins come in many flavors... inner vs outer, etc... The wfs spec specifies
> > that the semantics are that of an inner join. But I guess we could add some
> > notion of join type to the join class so that a user could specify which
> > type of join they want? Or maybe just stick with inner join since that is
> > the requirement and the most common case?
> >
> > That is about it for now... sorry it's a lot random thoughts i know. I
> > currently have a basic implementation working in the jdbc module. It needs
> > testing and to handle some more special cases but with it I have been able
> > to do a variety of joins, both "standard" and spatial.
> >
> > Thoughts and feedback welcome. Thanks folks.
> >
> > -Justin
> >
> > --
> > 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]
> > (mailto:[email protected])
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
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
