Opened 14 years ago

Closed 14 years ago

#670 closed defect (fixed)

ST_SharedPaths

Reported by: strk Owned by: strk
Priority: high Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc:

Description

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)

Change History (13)

comment:1 by strk, 14 years ago

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.

comment:2 by strk, 14 years ago

Type: defectenhancement
Version: 1.5.Xtrunk

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

comment:3 by robe, 14 years ago

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;

comment:4 by strk, 14 years ago

Priority: mediumhigh
Type: enhancementdefect

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

comment:5 by strk, 14 years ago

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.

comment:6 by strk, 14 years ago

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;

comment:7 by strk, 14 years ago

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 !

comment:8 by strk, 14 years ago

Even this succeeds:

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

comment:9 by strk, 14 years ago

Resolution: fixed
Status: newclosed

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

comment:10 by robe, 14 years ago

Resolution: fixed
Status: closedreopened

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;

comment:11 by strk, 14 years ago

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

comment:12 by robe, 14 years ago

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.

comment:13 by robe, 14 years ago

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.