[Tile-serving] [osm2pgsql-dev/osm2pgsql] Check intersection with preprocessed (area) dataset (Discussion #2264)

[Tobias]

For radverkehrsatlas.de we have a few usecases where we would like to add attributes to our ways/POI whenever they are within a pre defined / preprocessed area.

Use case:
- preprocess areas that represent residential areas and set a default speed limit to 50 if nothing more precise is present
- preprocess areas where biking is prohibited like cemeteries, industrial areas, allotments … and set a default bicycle-access if nothing more precise is present
- preprocess areas that represent residential areas and set a different assumed oneway-tag for bike path without explicit oneway (in cities oneway=yes, in rural areas oneway=no)

I wonder, if this could be something that comes to osm2pgsql in some generic form.
I could see us  running to osm2pgsql runs in sequence:
1. a osm2pgsql run to extract and sanitize the areas
2. a sql run to buffer and merge the areas as needed
3. another osm2pgsql run which then can look at those tables from 1+2

The check in run 3 could be different things
- "is point in area"
- "is way fully in area"
- "is way mostly in area, like 80%"
- "is way in area, regardless how much of the way"

Ideally, part of step 2 could also be done in osm2pgsql by re-using the tools that the generalization already has (AFAIK), like merging areas that are close into one shape, which the generalization does for woods and such, right? This could work nicely for cases where the areas are split into sections (which is why (2) would have to buffer and merge).


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

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