问题标签 [geomesa]

我正在查询一个 geomesa 功能，其中包括join两个属性（r和di）的索引。查询r=<int-value>运行并返回指定r值的数据（如果有）。但是，尽管存在相同的记录，但 Querydi=<int-value>没有找到任何匹配的记录！

这是我的功能架构：

r:Long:cardinality=high:index=join,*g:Point:srid=4326,di:Integer:index=join,al:Float,s:Float,b:Float,an:Float,he:Float,ve:Float,t:Float,m:Boolean,i:Boolean,ts:Long;geomesa.table.sharing='true',geomesa.indices='attr:4:3,records:2:3,z2:3:3',geomesa.table.sharing.prefix='\\u0001'

我无法找出根本原因。我不能在一个模式中有多个属性索引吗？

更新 1

附加查询计划

我正在尝试使用 geomesa 查询累积表，一切正常，我得到了正确的查询结果，但收到了有关“关闭输出流时出错”的警告。这是示例日志：

我还在 accumulo Web 界面上获取日志：

我搜索了相同的内容，但发现它说的是与集群过载有关的内容（我认为不会发生这种情况）。如何解决这个问题？

欢迎任何帮助和建议。

geomesa 是否支持聚合功能？像1。

1. COUNT计算给定查询的匹配特征。
2. 指定查询集合的属性的最大值/最小值。
3. 指定查询集合的属性值的平均值。

我尝试使用geotools 聚合函数，但它们没有为插入的新记录而更新。我也尝试使用该功能的偏移量，但它不起作用（正如其中一位开发人员所建议的那样，geomesa 不支持偏移量）。可以做些什么来实现这样的操作？

我Point在 geomesa 中使用几何类型来获取特征类型中的强经纬度细节。在存储新功能的用例中，我没有 lat-long 的价值，所以我尝试null为函数发送对象createPoint，但库“jts”在处理空几何类型时抛出异常。这是源代码。通过查看jts库的实现，在geomesa Point中存储null似乎很困难。我可以尝试哪些可能性？这是我的代码的快照：

附加异常日志：

我正在使用 geomesa 对 acccumulo 存储进行索引。我有一个存储时间戳值的属性。我对根据索引性能使用哪个 TYPE 和 INDEX 来存储时间戳值感到困惑。

有两种情况

1. 用作Long时间戳类型并创建属性索引。
2. 使用Date类型并使用默认日期索引。

我想知道在搜索和排序数百万条记录方面，这两种技术中哪种技术更好。

我正在使用 Geomesa 索引库将 3D 位置数据（经度、纬度、时间）索引到 1D 索引数据中。

这是我的 Scala 代码

问题是去索引的数据不准确，不像原始数据，我需要准确的索引，小数点后至少有 6 个第一位数字。

程序的输出（去索引的数据）

我知道 GeoMesa 可以像带有时间戳标签的空间线段一样索引时空形状，但在我的工作中，一个对象可能会在一个位置（点）停留一段时间（登录时间+持续时间），所以我怎么能在时间维度而不是空间维度上处理这样的线段？

我正在通过本机 api 将 shapefile（TM_WORLD_BORDERS-0.3.shp）中的数据摄取到 geomesa（在 accumulo 上）。然后，我想再次使用 Native Api，查询包含用户给出的点（纬度，经度）的 geomesa 中的任何数据（基本上是包含该点的 geomesa 中的任何多边形）。

或多或少模仿http://docs.geotools.org/latest/userguide/library/main/filter.html中的“Q. 我点击了什么？：使用点来检查多边形图层”

但是，当我运行查询时，我得到一个错误（累积）：

我可以看到我的功能具有 *geom 类型，但不是“the_geom”类型。然后我尝试覆盖 SimpleFeatureView 'populate' 和 'getExtraAttributes' 方法，但 getExtraAttributes 不允许我绑定几何图形...（注意：我还尝试从填充签名中为 setAttribute 赋予 gmtr 相同的错误） .

有错误：

综上所述，是否可以使用 GeoMesa 的 Native Api 的过滤器进行多边形点包含检查？我无法使用 ff.property 查询几何（“geom”的任何版本，例如“the_geom”、“*geom”等）

Geomesa 是一个时空数据库，更多详细信息可在此处获得： http ://www.geomesa.org/

我正在尝试示例教程，方法是使用它设置 Hbase 数据库。我正在运行Hbase 快速入门教程 http://www.geomesa.org/documentation/tutorials/geomesa-quickstart-hbase.html

本教程运行良好，以下是我在边界框查询中注意到的一些问题。

假设边界框查询类似于 (30,60) 到 (31,61)。这意味着我想在纬度 30 到 31 和经度 60 到 61 之间进行空间查询。我从 geomesa 得到的结果包括一些位置如下的点：
(29.5,61.5)
(29.6,61.3) 等等-在。
显然，这些点不在边界框内。我想问一下，有没有办法解决这个问题。以下是我向 Geomesa 团队提出的一些问题：

1. 默认的边界框查询精度是多少？
2.有没有办法在某处指定边界框查询的准确性，以便它离开边界框之外的点。

我尝试搜索文档和设置，但找不到任何对我有用的东西。

Geomesa是一个时空数据库，更多详细信息可在此处获得：http ://www.geomesa.org/

我正在尝试示例教程，方法是使用它设置 Hbase 数据库。我正在运行 Hbase 快速入门教程http://www.geomesa.org/documentation/tutorials/geomesa-quickstart-hbase.html该教程运行良好，以下是我在边界框查询性能中注意到的一些问题。

我插入了 lat、lng 范围 (30,60) 到 (35,65) 的数据

在此设置中，我在本地机器上进行查询：
a) 在我的第一个查询中，位置边界框是：(30,60) 到 (30.1,60.1)，它平均在不到一秒的时间内运行并返回正确的结果。
b) 在第二个查询中，我将位置边界框 (10,10) 修改为 (30.1,60.1)。此查询还返回与查询 (a) 中相同的结果，这是预期的，但平均每个查询大约需要 3-4 秒。

因为这两个查询都应该给我相同的结果，但一个比另一个运行得快得多。我也注意到时域查询中的类似行为，如果时间范围与插入的数据不匹配，性能会更差（慢 10 倍甚至更多）。以下是我的一些问题：
1）这是预期的行为吗？
2) 我知道解决方案之一是重新格式化查询以映射到插入到 Geomesa 中的实际数据空间和时间范围，这将需要我维护有关数据的其他元数据。但是，我认为可能会在 Geomesa 层设计更好的解决方案？

做，让我知道是否有某种设置等会影响这种行为。通过设置 Geomesa，我在多台其他本地机器和云 VMS 上看到了相同的行为。