[Tile-serving] [osm2pgsql-dev/osm2pgsql] How to omit certain relation members with flex output? (Discussion #2204)

[Candid Dauth]

It took me a while to find the time to look into this again. I have now set up a basic Lua script and Mapnik project to achieve this in the way you have suggested. Right now it seems to me that this is not a feasible approach for most setups.

The problem is that when I import a way, I do not know yet whether it is a member of a route relation (or it will ever be in the future, when using replication). This means that I have to import all the ways (or at least all highways) of the planet with their geometries into my way table. This does not only consumes a huge amount of disk space and import time, but when using replication (which is the main reason why I want to use the Flex Output in the first place), the `planet_osm_ways` in combination with the flat nodes file already indirectly contain all the ways of the planet, so I have to store the whole data twice.

An alternative way to achieve this could be to not store the ways, but construct the route geometry in Mapnik by querying the relation members directly from the `planet_osm_ways` table. I don’t know if this would be even possible with an SQL query, but even if it is, it would most certainly mean that I cannot use a flat nodes file, but the nodes would need to be stored in Postgres. This would itself mean a large additional amount of disk space and a huge additional amount of import time, which again does not seem feasible on a small server.

The approach could be suitable on servers that host a complete map of the planet that displays most features, for example the OSM Carto style. Such a server would have the geometry of all highways in the world in its database anyways, and those could be reused for my public transportation map. However, most small projects do not have the resources to host such a complete map of the planet, so it would be good to have a way to achieve this on a small server as well.

It seems to me that the only good way to achieve this would be if osm2pgsql added an option to support filtering relation members based on their tags. From what I understand, osm2pgsql persists all relations and ways with all their members and tags, and all nodes with their coordinates, to allow reprocessing their geometries during replication. I suppose when a relation is reprocessed and the Lua script calls `:as_multipolygon()` or `:as_multilinestring()` on it, osm2pgsql will run an SQL query to fetch all members and then look up the coordinates of the contained nodes in the flat nodes file. I suspect that it should be possible during the query to retrieve or even already filter the members based on their tags, since they are available as well in the `planet_osm_rels` and `planet_osm_ways` tables. I understand that retrieving the tags would have a performance impact, so it should only happen if the user requests it.

I assume that fetching the member tags and then passing them back to the Lua script for further processing would impact performance too much. So I’m wondering whether it would be an option to pass something like a filter property to `:as_multilinestring()` and the other methods that would tell osm2pgsql to exclude certain members based on their tags. I imagine something like this:
```lua
    geom = object:as_multilinestring({
        exclude_members: { type = 'way', key = 'railway', value = 'platform' }
    })
```

The exact shape of the `exclude_members` property would need some thought in order to allow _and_, _or_ and _not_ logic. The tag filter would probably only work for member relations and ways, and not member nodes, but it could at least allow to exclude member nodes in general.

Do you think this is an approach that could be implemented in osm2pgsql?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/discussions/2204#discussioncomment-17494358
You are receiving this because you are subscribed to this thread.

Message ID: <osm2pgsql-dev/osm2pgsql/repo-discussions/2204/comments/17494358 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20260701/b18762ee/attachment.htm>