TopoGeo_AddLinestring: return duplicated edge id, misses a created edge id

[amartin]

SELECT TopoGeo_AddLineString('prueba',indiv_geom, 0.8)
FROM (SELECT (ST_Dump(p_geom)).geom as indiv_geom
 FROM (SELECT ST_GeomFromText('MULTILINESTRING ((535695.149659 4352913.865809, 535688.723014 4352898.92539, 535723.74701 4352895.150892, 535753.102703 4352892.178469, 535795.04699 4352887.189505, 535796.627126 4352887.671191, 535833.621825 4352884.315548, 535876.015985 4352880.471036), (535835.196958 4352883.587799, 535876.015985 4352880.471036), (535721.65 4352723.95, 535856.49208 4352710.87767), (535716.757204 4352776.376076, 535709.98 4352820.5, 535707.36 4352839.32, 535706.76 4352849.87, 535702.8 4352855.33, 535692.11 4352866.25, 535687.41 4352875.78, 535687.44 4352887.6, 535688.11 4352897.4, 535688.497742 4352897.353794), (535721.65 4352723.95, 535718.85 4352752.09, 535717.5 4352771.54, 535716.757204 4352776.376076), (535856.49208 4352710.87767, 535871.413761 4352859.350046, 535858.408056 4352862.146972, 535849.178201 4352866.7619, 535839.8085 4352874.733138, 535835.613111 4352880.746528, 535835.196958 4352883.587799), (535688.497742 4352897.353794, 535688.721074 4352898.927358, 535695.149659 4352913.865809))',25830) AS p_geom) AS geom_squery) AS lines;

This query creates 8 different edges (as seen in edge_data table) but returns only 7 (one of them is allways repeated)

Eg: edge_id 2 appears twice in query results but edge 8 is actually created in the edge_data table

Query result:

"topogeo_addlinestring"
"2"
"3"
"4"
"5"
"6"
"7"
"2"
"9"

Might be related to ticket #1968

[strk]

Yes, this is the root cause of #1968. Keep up the good debugging !

[strk]

A tip: try reducing the number of segments. We'll eventually want to put this case into a regression test so the smaller it is, the better.

[amartin]

The behavior can be reproduced with only two components

SELECT TopoGeo_AddLineString('my_topo',indiv_geom, 0.8)
FROM (SELECT (ST_Dump(p_geom)).geom as indiv_geom
 FROM (SELECT ST_GeomFromText('MULTILINESTRING ((535695.149659 4352913.865809, 535688.723014 4352898.92539, 535723.74701 4352895.150892, 535753.102703 4352892.178469, 535795.04699 4352887.189505, 535796.627126 4352887.671191, 535833.621825 4352884.315548, 535876.015985 4352880.471036),  (535688.497742 4352897.353794, 535688.721074 4352898.927358, 535695.149659 4352913.865809))',25830) AS p_geom) AS geom_squery) AS lines;

Still getting duplicate edge_ids and a newly created edge_id is unreported

Query result:

"topogeo_addlinestring"
"50"
"52"
"50"

my_topo.edge_data table:

edge_id
50
51
52

[strk]

See if you can also reduce the number of vertices, and eventually also round some up (it'll be harder to round up as this is likely a robustness issue).

Also, it's better to have 2 separate queries to precisely control order (order does matter). Would also improve readability (and you can better inspect what's there after insertion of the first edge and better read the debugging line on second call).

[strk]

Taking a closer look at this I don't see any problem with the duplicated edge id, as that's due to a different component of the multilinestring. If you add the path to the SELECT you get:

SELECT path, TopoGeo_AddLineString('t',geom, 0.8)
FROM (SELECT (ST_Dump(p_geom)).*
 FROM (SELECT ST_GeomFromText('MULTILINESTRING ((535695.149659 4352913.865809, 535688.723014 4352898.92539, 535723.74701 4352895.150892, 535753.102703 4352892.178469, 535795.04699 4352887.189505, 535796.627126 4352887.671191, 535833.621825 4352884.315548, 535876.015985 4352880.471036),  (535688.497742 4352897.353794, 535688.721074 4352898.927358, 535695.149659 4352913.865809))',25830) AS p_geom) AS geom_squery) AS lines;

 path | topogeo_addlinestring 
------+-----------------------
 {1}  |                     5
 {1}  |                     4
 {2}  |                     6
 {2}  |                     4
(4 rows)

You can see there's no duplicate within the same invocation of topogeo_addLineString.There are two invocations, each returning 2 edges. One edge is the same. All is ok about that.

What would you expect amartin ?

[robe]

pusing to 2.1. so you can release

[robe]

make that 2.2.0. Don't want this holding up a 2.1.1 release

[strk]

lack of feedback, last time I looked at this it seemed all fine to me (see comment above). Feel free to reopen if you disagree.