Geodjango - Spatialite spatial index is not updated when the table is modifed

[burton449geo@…]

With spatialite, when new rows are added to a spatial table or when the geometry of a feature is modified, the spatial index is not updated. The MBR is not adjusted to the new extent of the table.

The spatial index file have to be deleted by hand to force his recreation.

[Claude Paroz]

Could you please investigate and tell us why you think Django is at fault here?
I found the following sentence in Spatialite documentation: each time you perform an INSERT, UPDATE or DELETE affecting the main table, then SpatiaLite automatically take care to correctly reflect any change into the corresponding R*Tree.

[burton449geo@…]

I am not sure, but it seems GeoDjango is not using the intern spatial index capability of Spatialite because:

From this source: ​http://www.gaia-gis.it/spatialite-3.0.0-BETA/SpatialIndex-Update.pdf
"any SQLite R*Tree simply is a distinct table [actually: a Virtual Table]"

So, in Spatialite, R-Tree are stored in a virtual table inside the database. When using Spatialite with GeoDjango, GeoDjango (or something else) creates a new file in the directory of the database which is named like this: sql3.db.index. When deleted, this file is recreated again when the spatial table is queried. But once it's built, it seems it's not updated when the geometry of features inside the table is modified. See this post for an issue that prooves this: ​http://gis.stackexchange.com/questions/58349/mapnik-weird-tiles-rendering-when-used-with-spatialite

I am not a specialist of Spatialite, but this is what I have investigate so far. Please tell me, if I am wrong.

[anonymous]

Sorry about this ticket, the issue is not with GeoDjango. It is about Mapnik.