Thank you to Eric, Tom and Andrea for the ideas, I appreciate your input. I
have started investigating whether the GeoServer SQL View can work for us.
Thanks again,
Jeffrey Wood
Software Engineer
Geocent
Email: [email protected]<mailto:[email protected]>
Ph (BR): 225-214-4346
From: [email protected] [mailto:[email protected]] On Behalf Of Andrea
Aime
Sent: Wednesday, November 20, 2013 3:42 AM
To: Jeffrey Wood; Justin Deoliveira
Cc: [email protected]
Subject: Re: [Geoserver-devel] request for GeoServer developer ideas re: "outer
join like" WFS request results
On Tue, Nov 19, 2013 at 7:34 PM, Jeffrey Wood
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I am working on a WFS request where we want results like an outer join, that
is, we want to get all features from one table even if they do not have a match
in the other.
Hi,
I concur with the solutions proposed by Tom, they both should help you get what
you want, or close to it, without having
to deal with the generality required for a core change (plus WPS supports
asynch requests, which is good if you plan to extract
large amounts of data, or if the joins end up being expensive).
Anyways, let's entertain the notion of doing it in the WFS protocol, as an
extension to the base protocol instead.
If we go beyond inner joins, we should consider setting up something that
leaves the door option to the other three join types, left, right, outer,
even if the initial implementation considers only outer.
The other issue to consider is that, in general terms, a query can contain more
than two feature types to be joined, or in other terms, more
than one join.
In SQL databases you specify the type of join, and then you don't need to
overload the meaning of and or or, because it's the type of
join that specified the desired behavior.
I'm wondering if something as follows could work, that is, adding a vendor
attribute specifying what kind of join should be considered:
<wfs:Query typeNames="layer1:ft1 layer2:ft2 layer3:ft3" aliases="ft1 ft2 ft3"
jointype="inner outer">
And then the filters could be reorganized and split amount joining and non
joining:
* a filter is considered part of a join if it binds togheter more than one
feature type, and associated to the join that can see all the involved types
* anything involving a single feature type is non joining instead
And then the Join class and the machinery associated to in in the JDBC data
store should be updated accordingly.
Unfortunately I'm not very much up to speed with WFS 2.0 joining, so not sure
how much of the above is actually feasible:
we'd really need Justin to chime in, as he implemented the existing joining
code.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
