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