Jim,
Thanks for
the response. My workaround for the temporal truncating bug
right now is to add a second to the time that I use along
with the BEFORE portion of my query. For my purposes, this
workaround has no ill effects.
I am
definitely setting the "SF_PROPERTY_START_TIME" in
userData to the “myTime” attribute (see example in my original
post). I am doing it in a way analogous to the following
which is how I’ve been doing it for a while now:
SimpleFeatureType featureType = null;
… // instantiate featureType
featureType.getUserData().put(Constants.SF_PROPERTY_START_TIME,
“myTime”);
As far as the “explainQuery”
function/feature in Java. I would be content setting the log
level for the
geomesa.core.index.IndexQueryPlanner
class to TRACE in order to see the explain query
output. I would probably only do this during
development/debugging.
I do see that you have added ‘secondary’
indexes for non-spatio-temporal attirbutes. I notice that the
latest version of GeoMesa generates multiple accumulo tables
for each feature type, e.g.
TableName
…
TableName_FeatureName_attr_idx
TableName_FeatureName_records
TableName_FeatureName_st_idx
I am not an
accumulo expert, so I yield to your expertise. But I
thought I would ask if it is necessary to create separate
accumulo tables for the “_attr_idx”, “_records”, and
“_st_idx” tables instead of simply creating new feature
types within the original accumulo table? I ask because I
find that I now have tons of GeoMesa-created accumulo tables
which seem to clutter things up. I have been sticking a lot
of different feature types in the same GeoMesa/accumulo
table and I used to only have one GeoMesa-created accumulo
table. Now I have 34 GeoMesa-created accumulo tables.
Again, if indexing/querying is faster using multiple tables,
then I probably need to get over this “clutter”. What are
your thoughts?
Is there a
quick command to delete accumulo tables using a regular
_expression_ via the accumulo shell?
Thanks,
Beau
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