[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [geomesa-users] Null geometry field values
|
Emilio:
Hmmm. I could have sworn I tried creating featuretypes without
geometries and was getting errors.
That said, that I think was back with 1.2.7. Was that something added
in 1.3.X?
I will have to try a test case and try it.
Yeah a marker row would work, something that can be easily tested in the
filter logic to eliminate the Null pointer
exceptions I was getting.
On 9/15/17 11:40 AM, Emilio Lahr-Vivaz wrote:
Hi David,
For 2, data types without native geometries are already supported (or
they should be... it's not our normal use case so it's not tested very
extensively).
For 1, there are some technical issues that allowing null geometries
creates. I'm including the dev list for a more technical discussion.
One option would be to just not include features with null geometries
in the spatial indices, and not include features with null geometries
and/or null dates in the spatio-temporal index. However, our attribute
indexing also includes a secondary spatio-temporal index, so we
wouldn't be able to index them there either... the only way to
retrieve the features would be by feature ID, which would hit the
record table. Any other query would not return them unless the record
table was specifically requested via query hint.
Currently scans without any reasonable index are run against the Z3
(or Z2) table - we do that to help the accumulo block cache. In this
scenario, we could instead scan the record table. That would help with
some queries, but attribute queries would still not return the
features correctly.
A second option is that we could index the features with some kind of
marker row (this is what you're suggesting I believe). For our spatial
index this could possibly work fairly seamlessly, as any query with a
spatial predicate would exclude the marker rows, while an inclusive
predicate would scan the whole table. Queries with just a temporal
component, however, would need special handling. We would have to add
additional scan ranges to check for the null geometries in the
spatio-temporal index. This would potentially slow down queries for
all users, even if their data doesn't have nulls.
Does anyone have any better suggestions? Comments?
Thanks,
Emilio
On 09/15/2017 10:08 AM, David Boyd wrote:
All:
I remember discussing this once before but want to follow up to
see if there is a work around or
something I am missing.
Currently, geomesa requires every feature type/schema to have a
geometry field with a valid value. This makes sense
since that is the primary element of the indexing approach.
I have two issues that I need to address:
1. Data with empty or null geometry values.
2. Data types without native geometry fields.
The first instance is the most common. Currently my hack for that
stores either a point for the south pole
or a bounding box very small at the south pole.
However, this bothers some people and even me to some extent because
it is fake data, and can get returned
in a geometry search.
Are there plans or what would it take to have geomesa accept a null
geometry field. It would be a special case
in the indexing that would require a specific bucket/partition for
those records. But in the end it would be little
different in terms of index distribution than what I am doing now.
The advantage would be none of this fake data would get returned in
queries and one could actually query for
all records with empty geometries. This would all work for all
support geometry types.
Thoughts.
FYI - in the second instance I end up adding a fake field with the
same fake values.
_______________________________________________
geomesa-users mailing list
geomesa-users@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/geomesa-users
--
========= mailto:dboyd@xxxxxxxxxxxxxxxxx ============
David W. Boyd
VP, Data Solutions
10432 Balls Ford, Suite 240
Manassas, VA 20109
office: +1-703-552-2862
cell: +1-703-402-7908
============== http://www.incadencecorp.com/ ============
ISO/IEC JTC1 WG9, editor ISO/IEC 20547 Big Data Reference Architecture
Chair ANSI/INCITS TC Big Data
Co-chair NIST Big Data Public Working Group Reference Architecture
First Robotic Mentor - FRC, FTC - www.iliterobotics.org
Board Member- USSTEM Foundation - www.usstem.org
The information contained in this message may be privileged
and/or confidential and protected from disclosure.
If the reader of this message is not the intended recipient
or an employee or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this communication
in error, please notify the sender immediately by replying to
this message and deleting the material from any computer.
