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

[Jochen Topf]

I don't think having two osm2pgsql runs is the way to go for something like this. It would mean having two configurations that are tightly integrated but separate. And you can not do updates any more. As you mention the osm2pgsql generalization framework is probably better suited for this kind of work.

For the "default values" stuff you describe I'd just import any available maxspeed data etc. into a column which is left as NULL if there is no specific data. Then use the `run_sql()` function of the generalization framework to run some SQL that finds all rows with a NULL in that column and fill it from some other data in the database. That data can come from anything, including having run any of the generalizer functions. It gets a bit tricky of you want to use updates. If you are happy with changed or new ways to get the correct maxspeed (or whatever) it will just work. But if, say, an industrial area is added and you need to recompute the default value for the ways in that area, you need to reset the values of all those ways to NULL first. But this is something that could be done.

What osm2pgsql is lacking at the moment is some "make"-like dependency graph where you can say: If this thing changes you have to recompute that other thing. At some point it would be great to have something like this, but at the moment you have to carefully sequence the generalization steps, so that they do the right thing.

I am not sure about the buffer-and-merge thing you are describing, because you loose detail that way. That might or might not be what you want. But you could certainly use the output of a generalization step for that. Because that generalization happens in (possibly overlapping) tiles, you just have to make sure that doesn't mess up your processing somehow.

Creating those statistics should also be no problem. You have all the power of the database at your disposal. I'd use a similar approach as described above, always writing NULL into some column and then updating that. Or you can just create some tables that are not filled by osm2pgsql and fill them with statistic data. You can even use the [per-tile SQL](https://osm2pgsql.org/doc/manual.html#strategy-tile-sql) strategy of the generalizer to update stats inside a tile whenever something in there changes.

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

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