我目前在等时线和基础算法领域中工作。现在引起问题的不是等位线本身的计算,而是结果的可视化。
我的等时线算法的结果是点和边。实际上,我确实有一个可行的解决方案,但是对于3873个边缘和1529个节点而言,事情似乎要花很多时间(在装有2015 Core i7 CPU和相当快的SSD的Lenovo T440s笔记本电脑上大约需要2.0秒)。而不是几秒钟,我想要的更像是msec :-)。
也许有人可以帮助我减少构建可视化可到达区域的多边形所需的计算时间。
但是等一下……第一件事!
这是等边线的计算结果,
这些边线是我的可视化效果:
这些边线存储在PostGIS数据库表中,是简单的线串。
我要向用户显示的内容如下所示: 请注意图片最南端和最东端的断开区域。这些应绘制为单独的区域(因此此处不允许合并:-)
目前,我正在使用此查询:
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM (
SELECT ST_MakePolygon(ST_ExteriorRing(ST_GeometryN(segments, generate_series(1, ST_NumGeometries(segments))))) AS polygons FROM (
SELECT ST_Union(ST_Buffer("GEOMETRY", 20, 'quad_segs=2')) AS segments FROM my_edges AS a
) AS b
) AS c
我已经做了一些实验,并且阅读了很多文档,但是我找不到更好的解决方案。
在我眼中,最大的问题是ST_Union的用法(如docs中所述,此功能可能很慢)。有趣的是,用ST_Collect替换它似乎会减慢ST_Buffer的计算,因此以下所有查询甚至花费更长的时间,尽管它不会填充边缘之间的区域(它只会在线条周围创建缓冲区):
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM (
SELECT ST_Buffer(ST_Collect(ST_LineMerge("GEOMETRY")), 20, 'quad_segs=2') AS polygons FROM my_edges AS a
) AS b
这在我的系统上大约需要3.8秒(几乎是两倍的时间)。我从这个小小的基准测试中得出的第一个结论是,在使用MultiLineStrings时,ST_Buffer的速度出乎意料的慢(甚至比为每行创建缓冲区并合并缓冲区时的速度还要慢-在我看来这很奇怪)
我也尝试使用alpha形状(使用pgRouting的实现),但是由于没有要设置的alpha值(实际上,我现在真的不愿意将哪个值设置为这样的值),所以我只得到了一个大多边形(因此我会把南部和东部的区域作为单独的区域丢失,这不是我想要的)。
同样ST_Polygonize(这是我想到的第一件事)没有产生任何可用的结果,但是也许我在这里错过了一些东西...
有没有更好的方法来创建PostGIS中显示的区域?也许还通过使用Java代码(jts)或客户端javascript代码(jsts)?实际上,只要结果中显示的区域保持分离并且计算速度快得多,我可以忍受一些细节丢失。