[OSM-dev] keeping thematic planet extract up to date

Igor Podolskiy igor.podolskiy at vwi-stuttgart.de
Tue Oct 18 19:31:36 BST 2011


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



More information about the dev mailing list