[Tile-serving] [openstreetmap/osm2pgsql] Duplicate rows with --expire-tiles option (#766)
ravhed
notifications at github.com
Fri Jun 30 12:22:27 UTC 2017
I've seen this behavior as well and having the expire-tiles parameter set actually affects if rows in the database are deleted or not. See this method which deletes ways:
```c++
int output_pgsql_t::pgsql_delete_way_from_output(osmid_t osm_id)
{
/* Optimisation: we only need this is slim mode */
if( !m_options.slim )
return 0;
/* in droptemp mode we don't have indices and this takes ages. */
if (m_options.droptemp)
return 0;
m_tables[t_roads]->delete_row(osm_id);
if ( expire.from_db(m_tables[t_line].get(), osm_id) != 0)
m_tables[t_line]->delete_row(osm_id);
if ( expire.from_db(m_tables[t_poly].get(), osm_id) != 0)
m_tables[t_poly]->delete_row(osm_id);
return 0;
}
```
As you can see it will only delete the way if it is expired. When expire-tiles is not set it will always be deleted as from_db will return -1 in that case.
My guess is that the issue is related to the tile expiry functionality and specifically that it drops some tiles from the tile expiry tree that shouldn't be dropped. See #709.
As a workaround you can create triggers that make sure that the row is dropped. This will decrease the update performance somewhat.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/766#issuecomment-312253169
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20170630/93d1e49c/attachment.html>
More information about the Tile-serving
mailing list