The first thing to note is that handing Literals and Context may be the same problem:
- For Literal: we need a String literal interpreted according to context
- For Context: we need an Expression result interpreted according to context
If we are "Eager" we need to ensure that we handle Literals correctly at parse time, if we are lazy we can put this off to evaualtion time. Give our uses cases (handling the same literal as both an Integer and String) my money is on the lazy approach.
Property expressions need to be able to extract information from a number of sources:
- Bean (ie POJOs)
- Maps & Lists
And they need to implement a subset of XPath (as documented by the Filter specification.
The morph part is well covered by the #Evaluation Context, an initial implementation based on WKT can morph from everything into JTS Geometry - where the functions work. More advanced implementations like Oracle SDO Geometry, or the PostGIS Geometry classes, can take the WKB route and not lose accuracy.
All of the above examples need to work with the cross product of:
- JTS Geometry
- GeoAPI Geometry
- Oracle Geometry
- PostGIS Geometry
Geometry Filter Alternatives