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.