[Tile-serving] [osm2pgsql-dev/osm2pgsql] Add grouped-linemerge generalization (PR #2482)

[leijurv]

leijurv left a comment (osm2pgsql-dev/osm2pgsql#2482)

> The mix of tile expiry and recursive query is interesting. I actually think that the solution is simpler because of your use of tile-based expiry instead of way-based. I did an implementation with way-based expiry for [waymarkedtrails](https://github.com/waymarkedtrails/osgende/blob/master/osgende/lines/segments.py) and only got it to work by tracking the IDs of the source ways for each merged way. That would make this implementation significantly more complex.

I admit I do not know how osm2pgsql works and clearly you know more than me

But this is my plan:

Right now we find deleted ways, updated ways, and created ways, by "rounding up" to a Z/X/Y tile. i.e. we get a "low resolution picture" of where edits have happened.

Instead, I'm imagining saving in the exact same way, at the exact same time, expiry data that is simply more precise: the exact `ST_X(ST_StartPoint(way)), ST_Y(ST_StartPoint(way))` and `ST_X(ST_EndPoint(way)), ST_Y(ST_EndPoint(way))` (including for deleted ways!). In my mind, the queries in this PR would be exactly(?) the same, only higher precision because they are a collection of exact points, rather than polygon geometries. Like `_glm_region` is a collection of `ST_Point` rather than a collection of tile bboxes. Possibly I am missing something?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2482#issuecomment-4634591346
You are receiving this because you are subscribed to this thread.

Message ID: <osm2pgsql-dev/osm2pgsql/pull/2482/c4634591346 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20260605/292d2a6c/attachment.htm>