[postgis-users] Getting TopologyExections when trying to node linestrings to create an overlay

[Rémi Cura]

Hey,
I executed your data,
the following command solve the problem (with very recent GEOS for me)
(POSTGIS="2.2.0dev r12846" GEOS="3.5.0dev-CAPI-1.9.0 r0" PROJ="Rel. 4.8.0,
6 March 2012" GDAL="GDAL 2.0.0dev, released 2014/04/16" LIBXML="2.8.0"
RASTER)

:

DROP TABLE IF EXISTS unique_polygon ;
CREATE TABLE unique_polygon AS
    SELECT geom_set_id,  row_number() over() as gid, ST_Translate(dmp.geom,
- 385614, - 4795454 ) AS geom
    FROM error_generating_polygons,unnest(polygons) as geomn,
st_dump(geomn) as dmp;
CREATE INDEX ON unique_polygon USING GIST(geom) ;

DRoP TABLE IF EXISTS unioned_poly ;
CREATE TABLE unioned_poly AS
SELECT ST_Union( ST_MakePolygon(ST_ExteriorRing(geom)) )
FROM unique_polygon
GROUP BY geom_set_id
(150 sec)


The change compared to your approach : convert input to table of simple
polygons, (no array, no multi).
Then  translate to improve precision in geos computing

Then the union.
I don't really understand what you are trying to do,
but ist_union seems dangerous and quit ineffective  for that .

Of course reducing the number of useless points before union make it 10
times faster .

DRoP TABLE IF EXISTS unioned_poly ;
CREATE TABLE unioned_poly AS
SELECT ST_Union(
        ST_Buffer(
            ST_MakePolygon(
                ST_ExteriorRing(
                    ST_SImplifyPreserveTopology(
                    geom
                    ,10
                    )
                )
            )
        ,1 )
        )
FROM unique_polygon
GROUP BY geom_set_id
(17 sec)

Cheers,
Rémi-C

2015-02-09 13:00 GMT+01:00 Rémi Cura <remi.cura at gmail.com>:

> Hey Sandro,
> this is a precision related issue,
> coordinates are way too big and should be translated.
> Cheers,
> Rémi-C
>
> 2015-02-09 12:25 GMT+01:00 Sandro Santilli <strk at keybit.net>:
>
>> On Tue, Feb 03, 2015 at 11:28:35AM -0500, BladeOfLight16 wrote:
>>
>> >
>> https://drive.google.com/file/d/0B_6I7kRgE8teVUpha2Q4ZlNDMWs/view?usp=sharing
>> .
>>
>> ...
>>
>> > DO $$
>> > DECLARE problem_row error_generating_polygons%ROWTYPE;
>> > BEGIN
>> >   FOR problem_row IN (SELECT * FROM error_generating_polygons) LOOP
>> >     BEGIN
>> >       PERFORM ST_Union(ST_Boundary(geom))
>> >       FROM UNNEST(problem_row.polygons) p (geom);
>> >       RAISE NOTICE 'geom_set_id % succeeded', problem_row.geom_set_id;
>> >     EXCEPTION
>> >       WHEN OTHERS THEN
>> >         RAISE NOTICE 'Error for geom_set_id % (Code %): %',
>> > problem_row.geom_set_id, SQLSTATE, SQLERRM;
>> >     END;
>> >   END LOOP;
>> > END
>> > $$;
>>
>> First of all I confirm it still happens with GEOS="3.5.0dev-CAPI-1.9.0
>> r4038".
>> Second, I took a look at a random set (geom_set_id=1) and I found it
>> pretty
>> big. That's to say you could probably further reduce the dataset for the
>> ticket. That set contains 109 polygons, I can get the error by attempting
>> to union the boundaries of the first 40 in that set, and I'm sure you can
>> further reduce the input.
>>
>> So my suggestion:
>>
>>  1) file the ticket
>>  2) attach the _smallest_ input that reproduces the problem
>>
>> About ST_IsValid: lines are always valid, so there's no need to test.
>> Most likely this is a robustness issue failing to deal with very close
>> but not equal lines.
>>
>> NOTE: I've tried my reduced input (~40) geoms against the topology builder
>> and it also resulted in errors, until I specified a tolerance of 1e-4.
>>
>> --strk;
>>
>>   ()   Free GIS & Flash consultant/developer
>>   /\   http://strk.keybit.net/services.html
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150209/8dd49ca6/attachment.html>