ST_SharedPaths

[strk]

A function to find and report paths shared between two linear geometries togheter with their direction (same or opposite).

The functionality is available in GEOS development version and exposed by C-API.

PostGIS side this should be a set-returning function returning records with the structure: (same boolean, geom geometry)

[strk]

But could also return a GEOMETRYCOLLECTION with first element being the "same" and the second element being the "opposite" dir shared MULTILINESTRINGS (which is what GEOS returns).

This second interface is simpler to implement/maintain and faster (as GEOS output is in the GEOMETRYCOLLECTION form already). Also, doesn't prevent you to obtain the previous proposed output by use of ST_Dump.

[strk]

As of r6236 this is ready, and tested. Needs to be documented in the manual. Uses the GEOMETRYCOLLECTION return.

[robe]

Sandro,

I put in some documentation for ST_SharedPaths and then passed it thru the grinder and managed to crash it. It broke on this query on my Windows 7 PostgreSQL 9.0 32 bit. Can you check and see if the below works on yours.

SELECT ST_SharedPaths(foo1.the_geom, foo2.the_geom) As result, ST_AsText(foo1.the_geom) As ref1_geom, ST_AsText(foo2.the_geom) As ref2_geom FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,10) As a) As i(i) CROSS JOIN generate_series(40,70, 15) j ORDER BY i,j )) As foo1 CROSS JOIN ((SELECT ST_Buffer(ST_SetSRID(ST_Point(i,j),4326), j*0.05) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,10) As a) As i(i) CROSS JOIN generate_series(40,70, 20) As j ORDER BY i, i*j, j)) As foo2 LIMIT 2;

[strk]

Yay, it crashes 8.4.3 on GNU/Linux 64 bit too. Good work !

[strk]

Kind of crazy, I created a table with the result of the subquery, getting 2 records with g1/g2 and could reproduce the crash using ST_SharedPaths against g1,g2 of first record.

Those geometries I've put in the regression test and can't reproduce the issue. I wonder if it's a corruption somewhere else.

Look at this:

strk=# select st_sharedpaths(g1::text::geometry,g2::text::geometry) from bug670 where id = 1;
ERROR:  GEOSIntersection: IllegalArgumentException: Geometry is not lineal
strk=# select st_sharedpaths(g1,g2) from bug670 where id = 1;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> 

Note that ::text givesn HEXEWKT, so there should be nothing lost. I suspect there's some corruption in internal structures _before_ SharedPaths is invoked.

[strk]

Note the table was created with this query:

strk=# create table bug670 as SELECT foo1.the_geom as g1, foo2.the_geom As g2
 FROM ((SELECT ST_SetSRID(ST_Point(i,j),4326) As the_geom FROM
 (SELECT a*1.11111111 FROM generate_series(-10,50,10) As a) As i(i) CROSS
 JOIN generate_series(40,70, 15) j ORDER BY i,j )) As foo1 CROSS JOIN
 ((SELECT ST_Buffer(ST_SetSRID(ST_Point(i,j),4326), j*0.05) As the_geom
 FROM (SELECT a*1.11111111 FROM generate_series(-10,50,10) As a) As i(i)
 CROSS JOIN generate_series(40,70, 20) As j ORDER BY i, i*j, j)) As foo2
 LIMIT 2;

[strk]

This succeeds too:

select st_sharedpaths(g1,g2::text) from bug670 where id = 1;

And this:

select st_sharedpaths(g2,g1) from bug670 where id = 1;

But this fails:

select st_sharedpaths(g1::text,g2) from bug670 where id = 1; -- crash !

[strk]

Even this succeeds:

select st_sharedpaths(g1,g1) from bug670 where id = 1;

[strk]

Oops. found and fixed in r6270. Sorry for the big noise.

[robe]

Strk,

This is better, but it's still crashing for me sometimes. In the battery of tests it always crashes, but if I run standalone it doesn't always.

If I run this test 1-3 times it usually crashes by the 2nd time.

SELECT ST_SharedPaths(g1,g2), ST_SharedPaths(g2,g1), ST_SharedPaths(g1,g1) 
FROM bug670;

[strk]

hrmf.. it runs valgrind clean for me now. You sure you rebuilt it ? With correct code in ?

while :; do psql -c "SELECT ST_SharedPaths(g1,g2), ST_SharedPaths(g2,g1), ST_SharedPaths(g1,g1) FROM bug670;"; done

has been gone for some time w/out a failure here

[robe]

I think so. Unless Paul's shp2pgsql changes are impacting my build in a negative way thought he dll says it gets built and I did delete my whole folder and redownloaded.

I'll try on another machine later. If it isn't rebuilding for some reason, that could explain the ST_Snap problem.

[robe]

Strk,

I'm going to assume you are right and close this out for now. All my problems are pointing squarely at Paul Its like my install script is just installing the .sql files and not the .dlls (its hard to tell since my script builds for 3 versions of postgresql so I'll have to walk thru it). I haven't confirmed yet (the dates look new but). The tell-tale signs of new script old dlls behavior seem to match up too nicely. That would explain the ST_Snap issue as well.