Re: [geomesa-users] Temporal filter bug? Temporal filtering seems to be

[Jim Hughes <jnh5y@xxxxxxxx>]

Hi Beau,

Great question.  Let me start with two general notes:

First, our current goal is to support ECQL as implemented by GeoTools.  By that I mean that if you have a collection of features, add them to GeoMesa and then apply a filter to the collection and to GeoMesa, you should see the same results.  In a quick test, I was able to use your ECQL and cook up a SimpleFeature with a Date between the end points of the filter.  The filter did accept the feature, so, yes, I'm calling this a bug.*

Second, as a more general note, we have added an "explainQuery" function/feature recently so that users (and developers) can take a peek under the hood and see how their query is being planned and executed.  Some notes about how to use it from the Scala console are in the commit message: https://github.com/locationtech/geomesa/commit/775634b831255f0f787415decd1e705dbbbd50af  The query explanation is also available when the log level for the class geomesa.core.index.IndexQueryPlanner is set to TRACE.

At the moment, I'm working on how we plan queries from the ECQL filter.  We have also added 'secondary' indexes for non-spatio-temporal attributes.  In the future, we are considering allowing additional spatio- and/or temporal- indexes (with different resolutions).  As that work continues, the query explainer will be able to describe why we choose to treat a query in one way or another. 

As a practical note about the query explainer, I haven't had a chance to think through using it from Java.  If you try it out and there are inter-op issues, let us know.

* Back to your original question:  Hunter is working up some unit tests.  From a cursory look, I'd ask if you are setting the "SF_PROPERTY_START_TIME" in userData on the SimpleFeatureTypes.  While encoding/ingesting data, if there was miscommunication about the name of the time field to index, GeoMesa might not be encoding the Date in the index entries.  Without the userData set, on the query side of things, we may misunderstand the query and do something silly.

Thanks again,

Jim

On 07/30/2014 03:40 PM, Beau Lalonde wrote:

Hi,

 

We just installed the latest GeoMesa (actually it was from yesterday).  I am happy to report that I have noticed that several bugs have been fixed since the mid-June version; however, I have noticed a new bug related to temporal querying.

 

I am indexing the temporal component of my data using a Date object, and I am querying using CQL analogous to the following:

        ((myTime BEFORE 2014-07-30T19:29:07.917Z) AND (myTime AFTER 2014-07-30T19:29:07.519Z))

 

It appears to me that the temporal bounds of my above CQL query are truncated to the second before the query is performed.  I have verified that the actual Date data in GeoMesa is not truncated or modified.

 

For example, the following scenario fails to return any query results (even though logically it should):

      Indexed time: 2014-07-30T19:29:07.520Z

      CQL query string: ((myTime BEFORE 2014-07-30T19:29:07.917Z) AND (myTime AFTER 2014-07-30T19:29:07.519Z))

      My guess at the effective query string based upon observation: ((myTime BEFORE 2014-07-30T19:29:07) AND (myTime AFTER 2014-07-30T19:29:07))

 

But the following scenario does return results as expected:

      Indexed time: 2014-07-30T19:34:40.746Z

      CQL query string: ((myTime BEFORE 2014-07-30T19:34:41.143Z) AND (myTime AFTER 2014-07-30T19:34:40.745Z))

      My guess at the effective query string based upon observation: ((myTime BEFORE 2014-07-30T19:34:41) AND (myTime AFTER 2014-07-30T19:34:40))

 

 

I know that most people are probably not querying on a per-millisecond basis, but my code does.  Is this a GeoMesa bug?  Or do I need to modify my code to reflect that querying can only be performed at a resolution of one second?

 

Thanks in advance,

 

Beau

_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geomesa-users