Thanks for splitting out the threads. I am starting to like this idea the
more I think about it and you make a lot of great arguments. More comments
inline.
On Sat, Apr 28, 2012 at 1:47 PM, Andrea Aime
<[email protected]>wrote:
> Hum... the thread is getting long and mails deal with many topics, let met
> try to
> split this into separate sub-threads.
> This one is about filters, paging and sorting.
>
> About sorting I believe we are all on the same page, my suggestions
> about checking for fast sorting was just a random idea anyways,
> don't see any strong need to see it implemented.
>
> About the topic of the predicate API being simpler than the OGC one...
> yes,
> it has less filters, which actually makes it less useful.
> About it being harder to build filters, I don't see it.
> The filter building styles of both goes through a factory with short
> named methods and arguably OGC allows for CQL expressions to
> be used if that is perceived to be simpler.
>
Right, my point is to look at what it takes to build a filter with straight
factories. Take a relatively non complex filter:
FilterFactory2 factory = (FilterFactory2)
CommonFactoryFinder.getFilterFactory(null);
PropertyIsLike f1 = factory.like(factory.property("name"), "*roads*");
Intersects f2 = factory.intersects(factory.literal("latLongBoundingBox"
), factory.literal(new Envelope(-180,-90,180,90)));
Filter f = factory.and(f1, f2);
I mean is it doable, yes. It is convenient, imo no. What I would long for
is something like:
Filter f = new FilterBuilder().like("name", "roads").and().intersects(
"latLonBoundingBox", new Envelope(-180,-90,180,90))
Obviously CQL is a great shortcut... but if the filter is not totally
static (in that you need to plugin in variable names, etc..) it involves a
lot of string concatenation involving quotes, etc... same deal as we have
for building sql strings which is one thing that personally drives me crazy
and i never get right due to some missing quote or something.
And then take into account functions which is the mechanism to do filtering
where the predicate is not modeled in the core language. The function
syntax requires things to be looked up by name, which requires a function
factory, etc... a lot of overhead. What I would like to be able to do is
just write a straight java function or anonymous inner class and have the
rest be handled for me.
Anyways, sorry this is getting more into usability of the filter api and
away from the original point.
> I don't see many people implementing lots of catalog subsystem
> implementations,
> and those people will likely deal with GeoServer in other ways so they will
> have a passing familiarity with OGC filter concepts already.
> Having to learn another API actually makes things more confusing, you
> need to remember what each API does and how.
>
> Encoding wise, we already have a lot of code that allows to split filter
> and encode
> them in SQL and other languages, which means we have examples on
> how things are done. Filter splitters do not make any use of the feature
> type, they only know about the filter types listed in a filter
> capabilities object
> (and they can be subclassed to allow more targeted checks),
> and filter encoders are something you need to prime often with a feature
> type,
> while in this case you'll have to prime them with the bean class.
> I don't see the difference nor the difficulty.
>
> Lack of spatial filter is problematic because of possible
> CSW implementations, but also for security subsystems that often
> express spatial constraints on the data (and layers) you can actually
> see, not having an efficient way to make them run looks like a serious
> drawback to me.
>
> But also think about the case in which you are not doing multitenancy,
> but you do have tons of layers. I know of one installation in Italy at
> a research center that had, one year ago, 160k layers registered,
> with new ones showing up every day.
> Think how useful it would be for a case like this to be be able to pass
> down
> a CQL filter on the GetCapabilies to get a more focused capabilities
> document
> for WMS/WFS/WCS usage.
>
Yeah, really cool stuff, kind of outside the original use case that started
the proposal but something I think should be brought in and something made
a lot easier if we do go with geotools filters for the predicate language.
>
> About the GUI filter that is not implementable efficiently in Predicate,
> I did not notice "contains" is a well known filter, so sorry about that
> one,
> reviewing the whole work in just half a day means I could not actually read
> everything line by line (and often I had difficulties understanding what
> the
> code did, see also the other mail about catalog implementations, but
> generally speaking the proposal was rich in terms of describing api and
> architectural concepts and poor in terms of describing how things are done,
> which is equally important for something that aims at being committed).
>
> About the relationship between catalog and data stores I don't want in
> any way impose it, nor I want to have abstraction layers be broken,
> I simply recognize OGC filter as a generic data access filtering API
> while it seems that you see it as something specific to GeoTools... but
> it's not, it's not meant to be, using property extractors you can actually
> have it filter whatever, features, beans, hashmaps, spatial stuff and
> non spatial one.
>
Well specific enough that you need most of the geotools library to be able
to use it, but yes not a problem for geoserver. And I can't imagine the non
feature case is really battle tested at the point that there are literally
zero assumptions about feature objects. But those are implementation
details, to be dealt with later.
>
> The thing could then go two ways. An easy nice to have is to
> be able to build a store on top of the catalog that would allow
> to display WMS maps of where the layers are, and search over
> the catalog via simple WFS (which can be a nice way to allow
> someone that wants to search into the server without having to
> build or use a CSW client). In both cases having spatial filters would
> be really handy, but in general the richness of OGC filter would
> allow for complex searches to be made fast.
>
> Very cool idea. Building a catalog without csw. Very clever.
> The other direction is to be able to build a catalog the other way, that
> is,
> build it on top of a data store. Now, I'm not sure it would be great, and
> we may not want to use it, but it would likely make for a quick to
> implement spatially searchable catalog.
> (mind, this is not the strong argument, I'm actually just thinking out
> loud,
> the strong argument is that the filter API is good, tested, well known,
> rich and flexible, Predicate is none of that, the rest of the arguments
> are just topping on the cake).
> Feature types could be created by flattening the objects and creating
> the feature type by reflection. Of course this would break the moment
> new attributes show up, but we can call updateSchema() to add those, right?
> It would also make for a more "relational" setup on DBMS storage, which
> many people would feel more comfortable with, and would make it easier
> for other applications to directly edit the persisted catalog (something
> I'm
> sure many people will want to do).
>
Also an interesting idea. No real comment other than I think it is cool.
>
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
