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/[email protected]>_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
