Question

具体而言，我得到了一个我不理解的结果。我的理解可能完全错误，但我不这么认为。所以我希望有人会说'是的，那是一个已知问题＆＃34;或者＆＃34;不，它工作正确，这就是为什么你的理解是错误的＆＃34;。

这是我的例子。

首先，我有以下lat / longs几何。

LINESTRING（-1.32007599 51.06707497，-1.31192207 51.09430508，-1.30926132 51.10206677，-1.30376816 51.11133597，-1.29261017 51.12981493，-1.27510071 51.15906713，-1.27057314 51.16440941，-1.26606703 51.16897072，-1.26235485 51.17439257，-1.26089573 51.17875111，-1.26044512 51.1833917， - 1.25793457 51.19727033，-1.25669003 51.20141159，-1.25347137 51.20630532，-1.24845028 51.21110444，-1.23325825 51.22457158，-1.2274003 51.22821321，-1.22038364 51.23103494，-1.20326042 51.23596583，-1.1776185 51.24346193，-1.16356373 51.24968088，-1.13167763 51.26363353，-1.12247229 51.2659966，-1.11629248 51.26682901 ，-1.10906124 51.26728549，-1.09052181 51.26823871，-1.08522177 51.26885628，-1.07013702 51.27070895，-1.03683472 51.27350122，-1.00917578 51.27572955，-0.98243952 51.2779175，-0.9509182 51.28095094，-0.9267354 51.28305811，-0.90499878 51.28511151，-0.86051702 51.2883055，-0.83661318 51.29023789 - 0.7534647 51.29708113，-0.74908733 51.29795323，-0.7400322 51.2988924，-0.71535587 51.30125366，-0.68475723 51.29863749，-0.65746307 5 1.30220618，-0.63246489 51.30380261，-0.60542822 51.30645873，-0.58150291 51.3103219，-0.57603121 51.31150225，-0.57062387 51.31317883，-0.54195642 51.32475227，-0.4855442 51.34771616，-0.4553318 51.36283147）

这是一个名为＆＃34; geom＆＃34;的列。在我的表中，称为＆＃34; fibre_lines＆＃34;。当我运行以下查询时，

select st_length(geography(geom), false) as full_length,
  st_length(geography(st_line_substring(geom, 0, 1)), false) as full_length_2,
  st_length(geography(st_line_substring(geom, 0, 0.5)), false) as first_half,
  st_length(geography(st_line_substring(geom, 0.5, 1)), false) as second_half
from fibre_lines
where id = 10;

我得到以下结果......

76399.4939375278 76399.4939375278 41008.9667229201 35390.5272197668

前两个对我有意义，它们只是我的线的长度，假设一个球形的地球。第一种是使用明显的函数，而第二种是使用st_line_substring来获取整行的长度。这两个值是一致的。

但最后两个让我感到困惑。我问的是前半部分的长度，然后我要求下半部分的长度。我的期望是这些相等或几乎相等。相反，上半场比下半场长约6公里。

如果您在地图上绘制几何图形，您将看到该线的前三分之一处于相当的北/南方向，其余三分之二处于东/西方向。我不会想到在球形地球上要求长度会有所作为，但我很高兴被告知我错了（只要它也解释了为什么我＆＃39;我错了。）

作为参考，我使用的PostGIS是 1.5.8。如果这是一个错误，可以升级到更新的版本，但不是微不足道的，所以我更愿意只如果有必要，那就这样做。

有人有想法吗？

Answer 1

虽然阿鲁纳斯的评论没有直接回答我的问题，但它确实引导我进行了一些我认为可以确定问题的研究。我在这里发布它的部分内容是为了让它在我自己的脑海中直接表达，部分原因是其他人想知道。

关键是PostGIS在“几何”和“地理”之间的区别。几何体是2D平面几何体，通常为UTM，并与球体投影到平面上使用（该投影是可配置的）。另一方面，地理位置专门用于存储纬度/经度信息，用于在球体或椭球体上工作。所以我遇到的基本问题是双重的：

从我原来的帖子中可能不明显的是我使用几何对象来存储纬度/经度信息而不是UTM。我大部分时间都将它转换为地理位置，以便我得到正确的答案，但如果我实际将其存储为地理对象，则会更正确。这将消除我的代码中的一些演员阵容的需要，并允许PostGIS告诉我我什么时候做错了。
虽然ST_Length可以使用几何或地理，但ST_Line_Substring仅适用于几何。因此，当我问它的中间点时，我要求它为平面几何的中间点。这将为我提供纬度坐标的正确答案，但对于经度，它将有一个误差项（对于大多数投影而言）我越远离赤道。

我已经研究过较新版本的PostGIS，他们似乎没有ST_Line_Substring或任何类似的东西会给我50％的地理位置，所以我必须通过“硬”的方式做到使用ST_Length给我所有的段长度，然后将它们相加并进行插值所需的数学运算。

Answer 2

抱歉，我无法添加评论，因此将其作为答案。

我遇到了同样的问题，并通过将latm几何转换为utm几何转换为st_line_substring函数调用来解决。 I作为具有适当长度的子几何。当然，之后我必须将它们转换回lat-lon。

有没有人知道postGIS中st_line_substring的潜在问题？

2 个答案: