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.
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.
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.
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.
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).
Cheers
Andrea
------------------------------------------------------------------------------
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
