@leijurv commented on this pull request.
> + // endpoint equality, not ST_Intersects, to avoid deleting unrelated
+ // same-group lines that cross a component. A second pass over the changed
+ // region cleans up outputs of components that disappeared entirely (all
+ // their lines deleted), which leave no reached nodes behind; that pass is
+ // self-correcting because anything it removes either vanished or has a
+ // surviving line in the region and is regenerated below.
+ timer(m_timer_delete).start();
+ auto deleted = dbexec(R"(
+DELETE FROM {dest} d
+ USING _glm_nodes n
+ WHERE {group_join_dn}
+ AND ( (ST_X(ST_StartPoint(d."{geom_column}")) = n.x
+ AND ST_Y(ST_StartPoint(d."{geom_column}")) = n.y)
+ OR (ST_X(ST_EndPoint(d."{geom_column}")) = n.x
+ AND ST_Y(ST_EndPoint(d."{geom_column}")) = n.y) )
+)");
Yes because the recursive CTE scan, that we insert in Step 5, includes
fragments that are entirely outside the current tile.
Consider the following four ways, that will LineMerge from A,B,C,D to AB,C,D
```
| /
| C
| /
--A--•--B--•
| \
| D
| \
^ tile boundary
```
The line 335 delete will only delete the AB geometry. The line 325 delete is
what deletes C, D, which is necessary, because Step 5 will reinsert all AB,C,D.
And conversely, the reason why 335 is needed as well as 325, is much easier to
justify: when you delete a way that is entirely within this tile, line 335
deletes it from the linemerged table too.
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2482#discussion_r3364667804
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/pull/2482/review/[email protected]>_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
