st_removerepeatedpoints regression

[nicklas]

Actually I am not sure it is ST_RemoveRepeatedPoints that is the problem, but something has happened since PostGIS 2.4.

I have problems vatching what is actually happening.

I am running r16554

This query returns as expected a "MULTIPOLYGON EMPTY":

# select st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10);
   st_snaptogrid    
--------------------
 010600000000000000
(1 row)

And if I feed ST_RemoveRepeadedPoints with Multipolygon Empty I get, as expected a Multipolygon Empty back:

# select st_removerepeatedpoints('010600000000000000'::geometry);
 st_removerepeatedpoints 
-------------------------
 010600000000000000
(1 row)

But if I feed ST_RemoveRepeatedPoints with the result from query 1 directly it reads the geometry type from the right place:

# select st_removerepeatedpoints(st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10));
ERROR:  Unknown geometry type: 1983230296 - Invalid type

In Postgis 2.4.4 r16526 I get the expected Multipolygon empty back instead.

Also if I change to polygon instead of multipolygon it works as expected also in latest trunk version:

# select st_removerepeatedpoints(st_snaptogrid('polygon((1 1, 1 2, 2 2,1 1))'::geometry, 10));
 st_removerepeatedpoints 
-------------------------
 010300000000000000
(1 row)

[pramsey]

Hm, well I never see the error case in my tests on 2.4 svn tip. I *do* see an inconsistency in the handling of polygon in 2.4, which is that your test returns NULL for polygon but empty for multipolygon in 2.4. In trunk the correct things happen. I will do a little code read and see if maybe we're mishandling memory in the 2.4 repeated points empty handling, which might cause an intermittent failure?

[pramsey]

Code line looks fine and I cannot replicate.

[nicklas]

Well, did anyone try with trunk?

It was trunk that gives me the problem.

Something has changed since 2.4 where it worked as expected.

I will try to investigate but I don't really know where to start.

Can someone replicate this with latest trunk?

Now I tried r16611.

To get the error run:

select st_removerepeatedpoints(st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10));

[komzpa]

confirmed.

POSTGIS="2.5.0beta1dev r16609" [EXTENSION] PGSQL="100" GEOS="3.7.0dev-CAPI-1.11.0 0" SFCGAL="1.3.5" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.3, released 2017/11/20" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.2.1"

23:32:05 [gis] > select st_removerepeatedpoints(st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10));
ERROR:  XX000: Unknown geometry type: 91095928 - Invalid type
LOCATION:  pg_error, lwgeom_pg.c:128
Time: 0,658 ms

[pramsey]

So the problem seems to be with an empty input:

postgis25=# select st_removerepeatedpoints(st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10));
ERROR:  Unknown geometry type: 40 - Invalid type
postgis25=# select st_removerepeatedpoints('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry);
                                                                           st_removerepeatedpoints                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 01060000000100000001030000000100000004000000000000000000F03F000000000000F03F000000000000F03F000000000000004000000000000000400000000000000040000000000000F03F000000000000F03F
(1 row)

postgis25=# select st_astext(st_snaptogrid('multipolygon(((1 1, 1 2, 2 2,1 1)))'::geometry, 10));
     st_astext      
--------------------
 MULTIPOLYGON EMPTY
(1 row)

[nicklas]

Yes, but the confusing part is that there is no error when giving ST_RemoveRepeatedPoints the 'MULTIPOLYGON EMPTY' directly.

But if it gets the 'MULTIPOLYGON EMPTY' from ST_SnapToGrid something happens.

Shouldn't ST_RemoveRepeatedPoints get the exactly same input no matter where it comes from?

[pramsey]

In 16613:

Fix flags in case where a boxless geom comes in with a "has box" set of flags.
References #4077

[nicklas]

wow, great Paul !

I wouldn't have looked in that corner for a long time

All good now, thanks a lot!

[pramsey]

Thanks for the minimal reproduction case Hart to believe after all these years we still had a bug to exercise in the serializer.

[strk]

Wow, scary indeed for that bug to be able to survive all these years! Congrats for the catch !