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. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
