#9686 closed (fixed)
GeoDjango should support the sqlite3 back end via SpatiaLite
Reported by: | mdh | Owned by: | jbronn |
---|---|---|---|
Component: | GIS | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
GeoDjango should support the sqlite3 back end via SpatiaLite. I've been working on this for a bit, and it mostly works, so I'm uploading my latest code so that other folks can take a look, comment, and help out.
In addition to this patch you will need these things:
- A reasonably modern version of SQLite3. Definitely at least version 3.3.7. I'm using version 3.6.4. Run “
sqlite3 --version
” to check yours. - At least version 2.5.0 of pysqlite2. Run “
python -c "from pysqlite2 import dbapi2 ; print dbapi2.version"
” to check yours. - Some version of SpatiaLite. I use 3.6.2. Run “
spatialite --version
” to check yours. - The latest patch from ticket #6064, to let GeoDjango initialize SpatiaLite when the connection is opened.
- The latest patch from ticket #9628, to let Django use your
pysqlite2
module instead of the built-insqlite3
module. - The latest patch from ticket #9633, to let the
SpatiaLiteAdaptor
class work. (We may be able to do away with this somehow.)
Right now, unless you're using a test database within the Django testing framework, you will need to initialize your geospatial database yourself. All the code to do it is there for the testing framework, though. This could be done entirely automagically, or it could be done with a special management command. I'm usually not a fan of magic, but in this case the whole point is to make it as trivial to get started with GeoDjango as it is to get started with the rest of Django, so I'm more open to a little bit of it.
Anyway! Let me know if you play with this!
Attachments (1)
Change History (9)
by , 16 years ago
Attachment: | 9686-spatialite-back-end-for-geodjango.diff added |
---|
comment:1 by , 16 years ago
Component: | Uncategorized → GIS |
---|
Okay, in order to overcome djangoproject.com
’s upload file size limitation and create a more readable patch, I ended up removing four data files from the patch. So, in addition to the patch itself, you will need to unpack this tarball into your Django repository in order for the geospatial database initialization and tests to work properly:
comment:2 by , 16 years ago
Needs documentation: | set |
---|---|
Patch needs improvement: | set |
I'm just going ahead and marking this preemptively, because lord knows this patch needs improvement.
comment:3 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:5 by , 16 years ago
milestone: | → 1.1 |
---|
comment:6 by , 16 years ago
(In [10197]) Refactored and cleaned up parts of the spatial database backend. Changes include:
- Laid foundations for SpatiaLite support in
GeoQuerySet
,GeoWhereNode
and the tests. - Added the
Collect
aggregate for PostGIS (still needs tests). - Oracle now goes to 11.
- The backend-specific
SpatialRefSys
andGeometryColumns
models are now attributes ofSpatialBackend
. - Renamed
GeometryField
attributes to be public that were private (e.g.,_srid
->srid
and_geom
->geom_type
). - Renamed
create_test_db
tocreate_test_spatial_db
. - Removed the legacy classes
GeoMixin
andGeoQ
. - Removed evil
\
from spatial backend fields. - Moved shapefile data from
tests/layermap
totests/data
.
A first attempt at supporting a SpatiaLite back end for GeoDjango