Opened 16 years ago
Closed 9 years ago
#9295 closed New feature (wontfix)
Better error handling and/or error reporting when Proj.4 datum shifting files are not found
Reported by: | springmeyer | Owned by: | jbronn |
---|---|---|---|
Component: | GIS | Version: | 1.0 |
Severity: | Normal | Keywords: | proj4, datum shifing, geodjango-basic-apps, postgis, 900913, projections |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
A very common install problem for new users to GeoDjango is to use a package management system for installing proj which does not include the Proj.4 datum shifting files (A key question is do any packager of proj include these files?). Or a user does a source install of proj and misses the instructions here: http://geodjango.org/docs/install.html#proj-4 and fails to manually install the additional files.
The impact of the lacking files is often first seen for new users who download one of the apps that uses the OSMGeoAdmin from http://code.google.com/p/geodjango-basic-apps/. Without a use of GeoDjango like this that does transformations between Google Spherical Mercator projection (http://spatialreference.org/ref/user/google-projection/) and another projection in a different datum, this installation problem might not surface for many users.
OSMGeoAdmin uses GDAL to do reprojection of data into SRID 900913 for the Admin OpenLayers map and then uses the spatial database backend to reproject the data back to the native SRID after the save() method is called.
With a PostGIS backend the spatial data is sent to in the database without proper reprojection due to the missing files with no error warning of the missing files needed. The geometry therefore misses the validation check at the form level, such that and error is throw by a GEOS error check only after finding corrupt coordinates which is not super intuitive as to the original problem:
Error encountered checking Geometry returned from GEOS C function "GEOSGeomFromHEX_buf"
Attachments (1)
Change History (12)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Owner: | changed from | to
---|
comment:3 by , 16 years ago
Attached is a patch which will bring back GeoAdminSite
and override check_dependencies
so that GeoDjango may raise an informative exception -- this still needs to be implemented. Moreover, I think I've figured out a way around the registration problem by also overriding autodiscover
so that GeoDjango's site
instance may also have 'normal' Django site
registrations.
by , 16 years ago
Attachment: | geoadminsite.diff added |
---|
comment:4 by , 16 years ago
Cool jbronn.
As background, here's some context on the lack of inclusion of the files in the debian packages: http://postgis.refractions.net/pipermail/postgis-users/2008-December/022220.html
comment:6 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:7 by , 16 years ago
A reference for folks working around this error, here is a workaround for the lack of packaging of the datum files that maintains to use of debian packages:
Thanks rcoup!
# note the lack of a complete set of proj files... $ ls /usr/share/proj/ epsg esri.extra nad27 nad.lst proj_def.dat esri GL27 nad83 other.extra world # re build the proj pkg after manually download the data files.. apt-get install fakeroot build-essential debhelper cd ~/src apt-get source proj wget http://download.osgeo.org/proj/proj-datumgrid-1.4.tar.gz cd proj-4.6.0/nad/ tar xzf ../../proj-datumgrid-1.4.tar.gz cd ../ dpkg-buildpackage -rfakeroot -b cd ../ dpkg -i proj_4.6.0-2_i386.deb $ ls /usr/share/proj/ alaska epsg esri.extra GL27 MD nad83 ntf_r93.gsb null other.extra prvi stlrnc TN WO conus esri FL hawaii nad27 nad.lst ntv1_can.dat nzgd2kgrid0005.gsb proj_def.dat stgeorge stpaul WI world
comment:8 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:11 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm not sure this is still a problem nowadays, considering the lack of interest/activity in this ticket.
For the sake of google indexing, here's the whole error which I could prompt by moving the folder '/usr/local/share/proj' to a new spot on the filesystem such that postgis can no longer find it.
This error happens on page reload of a previously saved record in the admin. Again, this is not a GeoDjango problem but I do think GeoDjango could provide better error handling and reporting.