jimjonesbr / lod4wfs

Server application for publishing Geographic Linked Open Datasets via Web Feature Services.
MIT License
13 stars 7 forks source link

CQL Support #28

Open semanticfire opened 8 years ago

semanticfire commented 8 years ago

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 ?

jimjonesbr commented 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?

semanticfire commented 8 years ago

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.

jimjonesbr commented 8 years ago

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.

semanticfire commented 8 years ago

okay we will look into it, and look at the FDA module

jimjonesbr commented 8 years ago

One approach would be to edit the FactoryFDAFeatures.java in such a way that the CQL expressions are first validated ...

https://github.com/jimjonesbr/lod4wfs/blob/master/lod4wfs/src/main/java/de/ifgi/lod4wfs/factory/FactoryFDAFeatures.java#L144

... 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.

https://github.com/jimjonesbr/lod4wfs/blob/master/lod4wfs/src/main/java/de/ifgi/lod4wfs/factory/FactoryFDAFeatures.java#L192

semanticfire commented 8 years ago

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.

jimjonesbr commented 8 years ago

I see. Since it comes from the GIS, it should be first properly parsed in the listener...

https://github.com/jimjonesbr/lod4wfs/blob/master/lod4wfs/src/main/java/de/ifgi/lod4wfs/web/ServletWFS.java#L46