You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working with geographical extracts, i.e. the data from one country, there are situations where objects move from inside the extract to outside or the other way around. The .osc files in that case can, for instance, contain a "pseudo-deletion" of a node, because this node didn't actually get deleted, just moved, but from the perspective of the extract it is gone. Normally when a node is deleted and the node was in a way, the way will be changed, so it will also be in the .osc file, but in this case the .osc file doesn't contain the way, because it didn't actually change. But osm2pgsql assumes that ways containing a node that is deleted is in the .osc file etc.
All this boils down to: If you are using extracts and updating them, you will get "special" cases at the border of your extract area. This doesn't happen often but it does happen occasionally.
I believe osm2pgsql could handle this case correctly if we "force" an update of any parent way when a node gets added or deleted and the same for parent relations of nodes and ways. But this would add quite some overhead, because we always have to ask the database for all parent objects.
The text was updated successfully, but these errors were encountered:
When working with geographical extracts, i.e. the data from one country, there are situations where objects move from inside the extract to outside or the other way around. The
.osc
files in that case can, for instance, contain a "pseudo-deletion" of a node, because this node didn't actually get deleted, just moved, but from the perspective of the extract it is gone. Normally when a node is deleted and the node was in a way, the way will be changed, so it will also be in the.osc
file, but in this case the.osc
file doesn't contain the way, because it didn't actually change. But osm2pgsql assumes that ways containing a node that is deleted is in the.osc
file etc.All this boils down to: If you are using extracts and updating them, you will get "special" cases at the border of your extract area. This doesn't happen often but it does happen occasionally.
I believe osm2pgsql could handle this case correctly if we "force" an update of any parent way when a node gets added or deleted and the same for parent relations of nodes and ways. But this would add quite some overhead, because we always have to ask the database for all parent objects.
The text was updated successfully, but these errors were encountered: