[OSM-dev] osm2pgsql update

[Kai Krueger]

Frederik Ramm wrote
> 
> I found out that the culprit is in the multipolygon code, where after 
> finding out that an one-way outer ring is tagged the same as the 
> multipolgon relation itself, a "delete_way_from_output" is issued, 
> presumably to remove that already-generated ring. This leads to a 
> "DELETE from <table> where osm_id=<id>" which requires a table scan 
> because of lack of primary keys.
> 
> I have now disabled this for --slim --drop mode (the change will not 
> affect normal --slim mode), but have to investigate further - this will 
> likely create some extra areas for outer rings, but since it doesn't 
> have these indexes, non-slim mode should exhibit the same behaviour.
> 
> Is anyone aware of multipolygon handling not working right when not 
> using --slim? We might have to (re)introduce the primary key for osm_id 
> at least on the polygon table to allow this deletion of duplicate areas.
> 
I think this might be fine to do and in fact it might be superfluous in the
normal slim mode import as well, although it is needed during diff
processing.

During the way processing stage of the import, osm2pgsql only writes those
ways to the output tables that, according to the style file, are not
polygons. Those ways that are polygons are only written to the slim mode
tables and marked as pending to be dealt with during the "going over pending
ways" phase, precisely because they might have to be deleted again should
they be part of a multi-polygon. So the "DELETE from <table> where
osm_id=<id>" should always turn up blank during a fresh import. (if I am not
mistaken)

Kai




--
View this message in context: http://gis.638310.n2.nabble.com/osm2pgsql-update-tp7027563p7049376.html
Sent from the Developer Discussion mailing list archive at Nabble.com.