Opened 6 months ago

Closed 6 months ago

#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
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)

test.dump (4.8 KB) - added by autra 6 months ago.
test bdd dump

Download all attachments as: .zip

Change History (10)

Changed 6 months ago by autra

Attachment: test.dump added

test bdd dump

comment:1 Changed 6 months ago by autra

Cc: autra added

comment:2 Changed 6 months ago by pramsey

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 Changed 6 months ago by Algunenano

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 Changed 6 months ago by Algunenano

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 Changed 6 months ago by autra

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 Changed 6 months ago by Algunenano

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 Changed 6 months ago by robe

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 Changed 6 months ago by autra

@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:9 Changed 6 months ago by Algunenano

Resolution: worksforme
Status: newclosed

Thanks for the report.

Note: See TracTickets for help on using tickets.