Opened 4 years ago

Closed 11 months ago

#17107 closed Bug (worksforme)

Geodjango Tutorial: SRID problem when loading data from shapefile to PostGIS

Reported by: pauline.emery@… Owned by: nobody
Component: GIS Version: 1.3
Severity: Normal Keywords: SRID
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by aaugustin)

I'm having a problem doing the section "LayerMapping" of the GeoDjango
official Tutorial [1].

After creating in the world directory. Leaving as specified:
"the transform keyword set to False because the data in the shapefile
does not need to be converted -- it's already in WGS84 (SRID=4326)"

I execute as indicate the following commands:

$ python shell
>>> from world import load

And obtain the following error:

Failed to save the feature (id: 0) into the model with the keyword arguments:
{'iso2': u'AG', 'pop2005': 83039, 'area': 44, 'region': 19, 'lon':
-61.783000000000001, 'iso3': u'ATG', 'subregion': 29, 'fips': u'AC',
'lat': 17.077999999999999, 'un': 28, 'mpoly': 'MULTIPOLYGON
(((-61.729171999999949 17.608608000000004,-61.731116999999983
17.54722200000009,-61.732779999999991 17.541111,-61.738891999999964
17.624996000000067,-61.729171999999949 17.608608000000004)))', 'name':
u'Antigua and Barbuda'}
[... stack trace]
IntegrityError: new row for relation "world_worldborder" violates
check constraint "enforce_srid_mpoly"

Postgres enforcing the check constraint for SRID=4326. I don't know to
say to Django to insert explicitely the SRID into the MULTIPOLYGON
command. Inserting the line by hand on Postgres work fine using
ST_Geomfromtext( 'MULTIPOLYGON(((...) (...)),4326).

The same problem occurs with other tutorials:
GeoDjango Database API with the Zipcode model [2]
GeographicAdminQuickStart [3]

I'm working with Python 2.6 / Django 1.3 with GeoDjango / GDAL 1.7.2
/ PostgreSQL 8.4.8 / PostGIS 1.5 / Pyscopg2 2.4

Thank you for your time and your help

Attachments (2) (270 bytes) - added by takinbo@… 4 years ago.
patch to fix the SRID problem when using PostGIS with Django (295 bytes) - added by takinbo 4 years ago.
An updated patch that works with r16826

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by takinbo@…

patch to fix the SRID problem when using PostGIS with Django

comment:1 Changed 4 years ago by takinbo@…

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I created a patch that specifies the SRID when creating features using Django and the PostGIS backend. This patch needs to be applied to the contrib/gis/db/backends/postgis/ file.

comment:2 Changed 4 years ago by pauline.emery@…

Thank you for the patch takingbo! It solved the SRID problem. I really appreciate the help! All the best!

comment:3 Changed 4 years ago by aaugustin

  • Description modified (diff)

Fixed formatting.

comment:4 Changed 4 years ago by aaugustin

  • Keywords problem removed
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

Patch no longer applies to trunk after r16826.

Changed 4 years ago by takinbo

An updated patch that works with r16826

comment:5 Changed 3 years ago by claudep

Strangely, I cannot reproduce the error. My config seems similar to the one of the OP: Python 2.6 - PostgreSQL 8.4.13 - PostGIS 1.5.1. I tested with Django 1.3/1.4/master.

comment:6 Changed 3 years ago by dracos

We had the same issue, which went away after GEOS was upgraded from 3.2.3 to latest 3.3, no other change to the system. The problem was caused because GEOS in this installation (though not this version, see below) returned the same non-SRID-containing output for WKB and EWKB (WKT and EWKT etc were fine, returning different output), and Django uses EWKB to create the SQL for insertion. The patch should not be necessary if GEOS was working as expected, because EWKB should include the SRID.

I then on another system installed 3.2.3 from source and could not reproduce this issue, so there was something different about the 3.2.3 installation on the first system; sadly I am unable to say what that was.

comment:7 Changed 11 months ago by timgraham

  • Resolution set to worksforme
  • Status changed from new to closed

Closing in light of inactivity and the fact that this seems to be fixed by updating GEOS.

Note: See TracTickets for help on using tickets.
Back to Top