Hi Martijn,
Thanks for you elaborate explanation. I see the problem with the ways
potentially lacking geometries.
Would the problem be much simpler if I constrain the data set to nodes only?
not in the general case unless you do some kind of processing on the
changes. If someone sets a gnis:id=* on a node which previously didn't
have it, it's an "update" from the planet point of view but a "create"
from yours. Similarly, if someone deletes the gnis:id tag (but not the
node itself), it's still an "update" for the planet but a "delete" for you.
Specifically with "osmosis --wpc" _and_ "nodes only", you might be able
to get away with it at least in the "update"/"create" case because the
current implementation basically does "update or create" for both
"update" and "create" actions, at the cost of querying the database for
every entity [1]. However, you will accumulate "stale" nodes in your
database over time because there is no "update/delete" translation. They
will have their gnis:id tag deleted but they'll still be there. No big
problem, but still a nuisance :)
Why are you using osm2pgsql for the database update step? Is that
because you require that schema or are there other reasons?
I more or less just render directly from that database, and osm2pgsql
works for me, there are no other reasons beyond that :) You could as
well do "osmosis --wpc" in that step, or use any other schema, or any
other data store for that matter - the problem we're talking about is
not schema specific.
Greetings from Stuttgart
Igor
[1]
https://github.com/openstreetmap/osmosis/blob/master/pgsnapshot/src/main/java/org/openstreetmap/osmosis/pgsnapshot/v0_6/impl/ChangeWriter.java#L153
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
