#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
pysqlite2module instead of the built-insqlite3module. - The latest patch from ticket #9633, to let the
SpatiaLiteAdaptorclass 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 , 17 years ago
| Attachment: | 9686-spatialite-back-end-for-geodjango.diff added |
|---|
comment:1 by , 17 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 , 17 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 , 17 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:4 by , 17 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:5 by , 17 years ago
| milestone: | → 1.1 |
|---|
comment:6 by , 17 years ago
(In [10197]) Refactored and cleaned up parts of the spatial database backend. Changes include:
- Laid foundations for SpatiaLite support in
GeoQuerySet,GeoWhereNodeand the tests. - Added the
Collectaggregate for PostGIS (still needs tests). - Oracle now goes to 11.
- The backend-specific
SpatialRefSysandGeometryColumnsmodels are now attributes ofSpatialBackend. - Renamed
GeometryFieldattributes to be public that were private (e.g.,_srid->sridand_geom->geom_type). - Renamed
create_test_dbtocreate_test_spatial_db. - Removed the legacy classes
GeoMixinandGeoQ. - Removed evil
\from spatial backend fields. - Moved shapefile data from
tests/layermaptotests/data.
A first attempt at supporting a SpatiaLite back end for GeoDjango