#4462 closed defect (worksforme)
st_asmvtgeom fails with IllegalArgumentException: RobustDeterminant encountered non-finite numbers
| Reported by: | autra | Owned by: | pramsey |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.5.3 |
| Component: | postgis | Version: | 2.5.x -- EOL |
| Keywords: | Cc: | autra |
Description
description
Using st_asmvtgeom in a query, I sometimes have the following error:
NOTICE: LWGEOM_GEOS_nodeLines(): IllegalArgumentException: RobustDeterminant encountered non-finite numbers ERROR: IllegalArgumentException: RobustDeterminant encountered non-finite numbers
Steps
- restore the attached dump in a database with postgis extension
- use the following query
select st_asmvtgeom(geom, st_setsrid(st_makebox2d(st_point(1645442.8949999844, 8184994.56999849), st_point (1647681.2699999844,8187432.94499849)), 3949)) as mvtgeom from copy3;
expected
The query resumes without errors
actual
The query fails with the following error:
NOTICE: 00000: LWGEOM_GEOS_nodeLines(): IllegalArgumentException: RobustDeterminant encountered non-finite numbers LOCATION: pg_notice, lwgeom_pg.c:184 ERROR: XX000: IllegalArgumentException: RobustDeterminant encountered non-finite numbers LOCATION: pg_error, lwgeom_pg.c:162
Additional informations
The following queries does succeed:
With a larger extent:
select st_asmvtgeom(geom, st_setsrid(st_makebox2d(st_point(1545442.8949999844, 8084994.56999849), st_point (1747681.2699999844,8287432.94499849)), 3949)) as mvtgeom from copy3;
When I intersect before using st_asmvtgeom:
select
st_asmvtgeom(
st_intersection(
geom,
st_setsrid(st_makebox2d(st_point(1645442.8949999844, 8184994.56999849), st_point(1647681.2699999844,8187432.94499849)), 3949)
),
st_setsrid(st_makebox2d(st_point(1645442.8949999844, 8184994.56999849), st_point(1647681.2699999844,8187432.94499849)), 3949)) as mvtgeom
from copy3;
Context
# select version(); PostgreSQL 10.9 (Ubuntu 10.9-0ubuntu0.18.10.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 8.3.0-6ubuntu1~18.10.1) 8.3.0, 64-bit # select postgis_version(); 2.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
I also reproduce with postgis 2.4
thanks!
Attachments (1)
Change History (11)
by , 5 years ago
comment:1 by , 5 years ago
| Cc: | added |
|---|
comment:2 by , 5 years ago
If you can move up to a more modern GEOS it's possible you'll find better results… PostGIS 3 includes a different clipper entirely that probably side-steps this. I don't think we can/will do anything with the current GEOS and older PostGIS.
comment:3 by , 5 years ago
I've tested the first query in 3.0 and it works fine, both with and without wagyu (the new clipping library).
Without wagyu:
POLYGON((536 4352,466 4352,486 4287,551 4170,551 4103,515 4077,479 4068,405 4084,368 4126,366 4352,300 4352,312 4310,313 4159,305 4025,334 3891,353 3832,408 3740,648 3524,667 3499,824 3358,842 3324,861 3249,899 3165,991 3107,1119 3074,1210 3075,1229 3092,1237 3126,1228 3159,1136 3201,1090 3251,1071 3309,979 3409,905 3493,867 3652,848 3710,764 3819,718 3902,708 4003,643 4128,632 4229,614 4254,540 4346,536 4352),(497 4043,552 4010,617 3943,654 3877,682 3810,729 3735,775 3676,794 3634,822 3517,841 3467,832 3450,759 3466,722 3500,657 3600,528 3725,472 3816,407 3900,388 3958,415 4017,451 4043,497 4043))
With wagyu:
POLYGON((466 4352,486 4287,551 4170,551 4103,515 4077,479 4068,405 4084,368 4126,366 4352,300 4352,312 4310,313 4159,305 4025,334 3891,353 3832,408 3740,648 3524,667 3499,824 3358,842 3324,861 3249,899 3165,991 3107,1119 3074,1210 3075,1229 3092,1237 3126,1228 3159,1136 3201,1090 3251,1071 3309,979 3409,905 3493,867 3652,848 3710,764 3819,718 3902,708 4003,643 4128,632 4229,614 4254,540 4346,536 4352,466 4352),(8 32 3450,759 3466,722 3500,657 3600,528 3725,472 3816,407 3900,388 3958,415 4017,451 4043,497 4043,552 4010,617 3943,654 3877,682 3810,729 3735,775 3676,794 3634,822 3517,841 3467,832 3450))
In both cases I'm using GEOS trunk:
# Select postgis_full_version();
postgis_full_version
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------
POSTGIS="3.0.0alpha4dev r17604" [EXTENSION] PGSQL="110" GEOS="3.8.0dev-CAPI-1.11.0 " PROJ="6.1.0" LIBXML="2.9.9" LIBJSON="0.13.1" LIBPROTOBUF="1.3.1" WAGYU="0.4.3 (Internal)"
I've also downgraded GEOS to 3.7.2 and it also works fine (Postgis 3.0 still):
mvt_test=# Select postgis_full_version();
postgis_full_version
-------------------------------------------------------------------------------------------------------------------------------------------
-----------------
POSTGIS="3.0.0alpha4dev r17604" [EXTENSION] PGSQL="110" GEOS="3.7.2-CAPI-1.11.2 b55d2125" PROJ="6.1.0" LIBXML="2.9.9" LIBJSON="0.13.1" LIB
PROTOBUF="1.3.1"
(1 row)
mvt_test=# select ST_AsText(st_asmvtgeom(geom, st_setsrid(st_makebox2d(st_point(1645442.8949999844, 8184994.56999849), st_point
(1647681.2699999844,8187432.94499849)), 3949))) as mvtgeom from copy3;
mvtgeom
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------
POLYGON((536 4352,466 4352,486 4287,551 4170,551 4103,515 4077,479 4068,405 4084,368 4126,366 4352,300 4352,312 4310,313 4159,305 4025,334
3891,353 3832,408 3740,648 3524,667 3499,824 3358,842 3324,861 3249,899 3165,991 3107,1119 3074,1210 3075,1229 3092,1237 3126,1228 3159,11
36 3201,1090 3251,1071 3309,979 3409,905 3493,867 3652,848 3710,764 3819,718 3902,708 4003,643 4128,632 4229,614 4254,540 4346,536 4352),(4
97 4043,552 4010,617 3943,654 3877,682 3810,729 3735,775 3676,794 3634,822 3517,841 3467,832 3450,759 3466,722 3500,657 3600,528 3725,472 3
816,407 3900,388 3958,415 4017,451 4043,497 4043))
(1 row)
Can you please confirm the exact version of postgis and GEOS that you are running?
The latest release of Postgis is 2.5.2 which should have the same MVTs as 3.0.0 without wagyu, so I'm inclined to agree with Paul and blame this on an outdated GEOS.
comment:4 by , 5 years ago
A small correction: 3.0 without wagyu should be the same as 2.5.3 (not released yet), which includes #4348 where I reworked how the validation was done with GEOS (slower but more stable).
comment:5 by , 5 years ago
I updated my geos version to 3.7.2:
=> select postgis_full_version();
postgis_full_version
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
POSTGIS="2.4.4 r16526" PGSQL="100" GEOS="3.7.2dev-CAPI-1.11.2 b55d2125" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.3.2, released 2018/09/21" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.3.1" RASTER
(1 row)
but still have this issue 
=> select st_asmvtgeom(geom, st_setsrid(st_makebox2d(st_point(1645442.8949999844, 8184994.56999849), st_point (1647681.2699999844,8187432.94499849)), 3949)) as mvtgeom from copy3; NOTICE: 00000: LWGEOM_GEOS_nodeLines(): IllegalArgumentException: RobustDeterminant encountered non-finite numbers LOCATION: pg_notice, lwgeom_pg.c:184 ERROR: XX000: IllegalArgumentException: RobustDeterminant encountered non-finite numbers LOCATION: pg_error, lwgeom_pg.c:162
@Algunenano do I need to do something after compiling and installing the new geos to use it? It's odd I still reproduce with 3.7.2 and you don't…
comment:6 by , 5 years ago
do I need to do something after compiling and installing the new geos to use it?
No, if you've replaced the system libraries (/usr/lib/libgeos_c.so, /usr/lib/libgeos.so in my system) just open a new connection to the database.
It's odd I still reproduce with 3.7.2 and you don't…
From your call to postgis_full_version I see 2 things: GEOS seems to be loaded correctly with the 3.7.2, but you are using Postgis 2.4.4. MVTs have seen a lot of bug fixes and improvements, so I'd recommend you to update to 2.4.7 (no upgrade necessary) and retest.
I've made some tests with the DBs I have on hand:
- PG 11 - Postgis trunk(Wagyu) - GEOS 3.7.1 - Works fine
- PG 10 - Postgis trunk(Wagyu) - GEOS 3.7.1 - Works fine
- PG 11 - Postgis trunk(Wagyu) - GEOS trunk - Works fine
- PG 11 - Postgis trunk(GEOS) - GEOS trunk - Works fine
- PG 11 - Postgis trunk(GEOS) - GEOS 3.7.2 - Works fine
- PG 11 - Postgis 2.5.2 - GEOS trunk - Works fine
- PG 11 - Postgis 2.5.2 - GEOS 3.7.2 - Works fine
I currently don't have any database with 2.4.
comment:7 by , 5 years ago
autra — I just noticed your output says 3.7.2dev (and not 3.7.2) so you are running with a pre-released version of geos 3.7.2 it seems which might not have needed fixes. Try redownloading GEOS (make sure you are working from released 3.7.2 - http://download.osgeo.org/geos/geos-3.7.2.tar.bz2
comment:8 by , 5 years ago
@robe thank you. Meanwhile I tested on a debian buster, and my problem was fixed (so with geos 3.7.1 and postgis 2.5). Is it only possible that the fix is in 3.7.1, 3.7.2 without being in 3.7.2-dev? I don't know your branch workflow, so you will know better than I do 
Also, I know I messed up something in the way I installed geos at first (that's why I tried with a fresh os), so I don't know about the validity of my test that showed 3.7.2-dev. Please take it witfh a grain of salt.
From my perspective, we can close this issue (not sure of the resolution status though: wontfix or worksforme?), as updating solved it.
Thanks for you help pramsey, robe and Algunenano
comment:10 by , 5 years ago
I'm allowing an additional comment for anyone passing by: to fix this, you must either update libgeos or postgis (to v3). However, if you are on debian buster, beware that you only have postgis-3 package for postgresql 12. BUT also beware that the gdal version buster ships with is currently not compatible with postgresql12 (we need https://github.com/OSGeo/gdal/commit/963618e77de4eee5e7321f5f5ca7abc2b7287fa2 and the 2.4 version in buster doesn't have that)!
So if you also need gdal, your only choice as of now is to use pgdg repository and install postgresql-11-postgis-3 from there.
It's a pity that the only broken tuple of versions are precisely the one that ships in buster… I'm not sure what would be the less costly solution for this though.
test bdd dump