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