Re: [geomesa-users] Schema of st_idx table

["vaibhav.thapliyal" <vaibhav.thapliyal@xxxxxxxxxx>]

Dear Chris,

Thanks for explaining the structure of the st_idx table. I was able to 
index the lat-lon and temporal data in the row. However I have a slight 
modification as compared to the geomesa schema. I have appended an "id" 
field in front of the existing row content. So now I have the row like this:

~48253cb63641fa0d31faa52c~0~0~featureNewsMediaV1_2~sx9~2014021818

I also used Kryo serializer library to create an encoded form of the id 
which I am storing in the value field.
So my value is like this.

\x0148253cb63641fa0d31faa52\xE3\x00\x00\x00\x00\x00

which is different from the way value is encoded in the original geomesa 
tables.

So it would be great if you could point out somewhere in the code as to 
how value is encoded and how the geomesa iterators perform query on this 
schema.

Thanks
Vaibhav

On 09/10/2015 05:56 PM, Chris Eichelberger wrote:
> Vaibhav,
>
> For what it's worth, the "st_idx" table is about to be deprecated in
> favor of a new Z3 structure.  We will shortly have documentation up
> describing how the new structure works.  (The short version is that it's
> a concatenation of the most-significant bits of T and a Z-order
> combination of X, Y, and the low-order bits of T.)
>
> In the "st_idx" table, the value is typically a Kryo-encoded version of
> the entire Feature, which allows us to do fine-grained filtering within
> the Accumulo iterators beyond the spatio-temporal constraints.
>
> Secondary indexes, those not involving (X, Y, T), are created by
> concatenating the feature-type name with the attribute name and the
> value within the "attr_idx" table.  The value in this table will be
> either a Kryo-encoded version of the Feature or the record ID (depending
> on the index type requested in the SimpleFeature specification, "full"
> or "join", respectively.)  This way, if we know that an attribute's
> value has high selectivity (high cardinality), we can seek directly to
> the part of the "attr_idx" table where those records reside.  This
> structure also enables range queries and right-hand wildcards on
> attribute values.
>
> I hope this helps.  If you have any additional questions, please just
> let us know.
>
> Thanks!
>
> Sincerely,
>    -- Chris
>
>
> On Thu, 2015-09-10 at 17:45 +0530, vaibhav.thapliyal wrote:
> > Hello everyone,
> >
> > I am trying to use geomesa for querying geo-spatial data. While doing
> > so, I came across the st_idx table which is used to index
> > spatio-temporal data. On reading the research paper I found out the way
> > indexing is being done, and how data is mapped on Row, colf and
> > col-qualifier, using geo-hashed value of the lat-lon ie how the key is
> > being generated. What I am failing to understand is what is contained
> > inside the Value field of Accumulo.
> >
> > Also if someone could explain how is non-spatial temporal data (for eg
> > Customer Name)is stored/indexed in geomesa, it would be very helpful.
> >
> > Thanks
> > Vaibhav
> > _______________________________________________
> > 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