Open semanticfire opened 8 years ago
CQL would be a nice extension for the WFS Adapter. However, I have so far no use case to "motivate the development". Could you maybe tell me more about your specific needs?
I'd like to create a WFS which shows events on a map, Some of the ideas I have
Prerequisite is obviously that the properties you want to filter on are in the result clause of the query We might actually contribute the code, it should be fairly straight forward to compile a CQL expression into a bunch of Sparql FILTER clauses on top of the existing result variables.
Just to make sure I got it right: So your approach would be to extend the FDA Features module to offer CQL to generate the FILTER clauses. Honestly, I'm not very familiar with CQL, but it seems to be a feature worth implementing. A contribution from your know-how would be much appreciated.
okay we will look into it, and look at the FDA module
One approach would be to edit the FactoryFDAFeatures.java in such a way that the CQL expressions are first validated ...
... and later on added to the SPARQL Query as FILTER clauses ...
https://github.com/jimjonesbr/lod4wfs/blob/master/lod4wfs/src/main/java/de/ifgi/lod4wfs/factory/FactoryFDAFeatures.java#L268 https://github.com/jimjonesbr/lod4wfs/blob/master/lod4wfs/src/main/java/de/ifgi/lod4wfs/factory/FactoryFDAFeatures.java#L275
Looking at the code now I realize there is some redundancy in the query execution, but it can be cleaned later on.
Another approach (probably the easiest one) would be to store the expressions in a different field in the feature's json file (by now named .sparql), so that the query executor can convert and add it to the SPARQL at query execution time. This would mean a minimum change in the application structure.
Another approach (probably the easiest one) would be to store the expressions in a different field in the feature's json file (by now named .sparql), so that the query executor can convert and add it to the SPARQL at query execution time. This would mean a minimum change in the application structure.
This is not going to work, since the CQL is going to be dynamic, you'll write them in the frontend, e.g. QGIS, there is no other way then adding dynamic filters.
I see. Since it comes from the GIS, it should be first properly parsed in the listener...
Did you ever thought about CQL support, to extend the queries with automated filters to select a subset of features based on a attribute value ?