I forgot to mention this..
At Thu, 02 Feb 2017 21:11:16 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170202.26.49572782.horiguchi.kyot...@lab.ntt.co.jp>
> Hello, I digged this topic covered by a spiderweb..
>
> # PostGIS requires so many libraries installed :(
>
> FIY, for t
Hello, I digged this topic covered by a spiderweb..
# PostGIS requires so many libraries installed :(
FIY, for the given test case, the following query hits the bug.
| SELECT edge.geom AS geom
| FROM (SELECT * FROM knn_recheck_geom) AS edge
| ORDER BY '01010014AE47E17A141FC09AA170C0'
On Tue, Jan 3, 2017 at 12:36 AM, Regina Obe wrote:
>> cmp would return 0 if the estimated distance returned by the index AM were
>> greater than the actual distance.
>> The estimated distance can be less than the actual distance, but it isn't
>> allowed to be more. See gist_bbox_distance for an
>> If things are out of order, why isn't just going to was_exact = false
>> good enough?
>>
>> I'm not sure if the mistake is in our PostGIS code or something in
>> PostgreSQL recheck logic.
>> If I change the elog(ERROR ...) to a elog(NOTICE, the answers are
>> correct and sort order is right
On Fri, Dec 30, 2016 at 12:51 AM, Regina Obe wrote:
> I've been trying to troubleshoot the cause of this PostGIS recheck bug we
> have reported by two people so far. The last test was a nice simple
> repeatable one that triggered the issue:
>
> https://trac.osgeo.org/postgis/ticket/3418
>
> from
I've been trying to troubleshoot the cause of this PostGIS recheck bug we
have reported by two people so far. The last test was a nice simple
repeatable one that triggered the issue:
https://trac.osgeo.org/postgis/ticket/3418
from what I have seen this only affects cases where we are doing a di