Django returns error after modifying country boundary polygon
Closed this issue · 15 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1. Start django using the builtin server
geographic_admin> python manage.py runserver
2. Load up any country's admin page
http://localhost:8000/admin/world/worldborders/138/
3. Move a vertex of the polygon
4. Click save.
5. Return to the country's admin page again
http://localhost:8000/admin/world/worldborders/138/
--------------------------------------------------------------------
What is the expected output? What do you see instead?
I would expect to see the admin page for the country, but instead I get a
Django error page...
Environment:
Request Method: GET
Request URL: http://optiplexe:8000/admin/world/worldborders/21/
Django Version: 1.0-final-SVN-9084
Python Version: 2.5.2
Installed Applications:
['django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.databrowse',
'django.contrib.gis',
'world']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware')
Traceback:
File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py" in
get_response
86. response = callback(request, *callback_args,
**callback_kwargs)
File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in root
158. return self.model_page(request, *url.split('/', 2))
File "/usr/lib/python2.5/site-packages/django/views/decorators/cache.py" in
_wrapped_view_func
44. response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in
model_page
177. return admin_obj(request, rest_of_url)
File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in
__call__
197. return self.change_view(request, unquote(url))
File "/usr/lib/python2.5/site-packages/django/db/transaction.py" in
_commit_on_success
238. res = func(*args, **kw)
File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in
change_view
598. form = ModelForm(instance=obj)
File "/usr/lib/python2.5/site-packages/django/forms/models.py" in __init__
201. object_data = model_to_dict(instance, opts.fields,
opts.exclude)
File "/usr/lib/python2.5/site-packages/django/forms/models.py" in model_to_dict
123. data[f.name] = f.value_from_object(instance)
File "/usr/lib/python2.5/site-packages/django/db/models/fields/__init__.py"
in value_from_object
332. return getattr(obj, self.attname)
File
"/usr/lib/python2.5/site-packages/django/contrib/gis/db/models/proxy.py" in
__get__
36. geom = self._klass(geom_value)
File "/usr/lib/python2.5/site-packages/django/contrib/gis/geos/base.py" in
__init__
66. g = from_hex(geo_input, len(geo_input))
File
"/usr/lib/python2.5/site-packages/django/contrib/gis/geos/prototypes/errcheck.py
"
in check_geom
32. raise GEOSException('Error encountered checking Geometry
returned from GEOS C function "%s".' % func.__name__)
Exception Type: GEOSException at /admin/world/worldborders/21/
Exception Value: Error encountered checking Geometry returned from GEOS C
function "GEOSGeomFromHEX_buf".
--------------------------------------------------------------------
What version of the product are you using? On what operating system?
Django Version: 1.0-final-SVN-9084
Python Version: 2.5.2
Ubuntu 8.04
--------------------------------------------------------------------
Please provide any additional information below.
I get this response on two separate servers.
Original issue reported on code.google.com by tylerick...@gmail.com on 22 Sep 2008 at 9:10
GoogleCodeExporter commented
Upon further investigation, the error can be triggered without moving any of the
vertices. It seems to be triggered when clicking the save button, even if no
changes
to the record were made.
Specifically, the geometry column seems to be altered upon saving. For
example, here
is a comparison of the Monaco geometry before and after clicking the save
button...
-------------- Query ------------------
SELECT id, "name", geometry, ST_AsEWKT(geometry) as geom_EWKT
FROM world_worldborders where name='Monaco'
-------------- Result Before Save------------------
"id","name","geometry","geom_ewkt"
630,"Monaco","0106000020E61000000100000001030000000100000005000000E7723106D6C11D
40FC7B7F83F6E0454048471FF301911D40D4A6954220DD45406890F469158D1D40E0D38041D2DF45
402806820019AA1D40B8E67283A1E24540E7723106D6C11D40FC7B7F83F6E04540","SRID=4326;M
ULTIPOLYGON(((7.43929300000011
43.7575230000002,7.39160900000008 43.7275470000001,7.38777700000001
43.7486040000001,7.41611100000004 43.7705540000001,7.43929300000011
43.7575230000002)))"
-------------- Result After Save--------------------
"id","name","geometry","geom_ewkt"
630,"Monaco","0106000020E61000000100000001030000000100000005000000E1723106D6C11D
40F67B7F83F6E045400118079E6D71B33ECA83538B69C1DC3EA9D92F07D96EB33E60792D09F5C4DC
3E6B883775ED81B33E61183803A7C8DC3E8E9A31BF8991B33E0382A96A75C6DC3E","SRID=4326;M
ULTIPOLYGON(((7.43929300000011
43.7575230000001,1.15889780981501e-06 6.85584943946409e-06,1.15829700741768e-06
6.85915087469813e-06,1.16273937044627e-06
6.8625923179741e-06,1.16637397409308e-06
6.86054924389822e-06)))"
As can be seen in the example, the coordinates of the multipolygon geometry have
changed, and it is no longer a closed set of points.
Original comment by tylerick...@gmail.com on 23 Sep 2008 at 2:12
GoogleCodeExporter commented
Here is some information on the PostGIS and GEOS libraries that I am using...
select postgis_full_version()
"POSTGIS="1.3.3" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007"
USE_STATS"
Original comment by tylerick...@gmail.com on 23 Sep 2008 at 2:14
GoogleCodeExporter commented
Hi Tyler,
Sorry that GEOS is acting up for you. My hunch is that this is a geos install
issue rather than a problem with
geodjango or the geographic_admin project.
I can't recreate the issue on mac os 10.5 with geos 3.1.0:
springmeyer:~ spring$ geos-config --version --libs --includes
3.1.0
-L/usr/local/lib -lgeos
/usr/local/include
Did you install geos on your two ubuntu systems with apt-get?
Perhaps jump into #geodjango irc tomorrow and post about the error.
If you built from source have you tried rebuilding geos recently?
Original comment by dane.spr...@gmail.com on 23 Sep 2008 at 6:32
- Changed state: Started
GoogleCodeExporter commented
Tyler,
As you can likely tell, it looks like what is happening is that geodjango is
not properly reprojecting the vectors when you hit save. (Strangley one
coordinate does seem to get reprojected correctly).
So, I realize not that it is not a simple as a GEOS problem, but rather the
coordinates get messed up and the GEOS error check is the first to get tripped
up with a true exception.
I still think the ultimate problem is something with your install, but it seems
clear that GeoDjango should try to catch this error sooner.
Context: The geographic_admin project uses OSMGeoAdmin to generate that
OpenLayers Admin map in epsg:900913, and geodjango reprojects the coordinates
stored in epsg:4326 into 900913 to display on the
map (which seems to be working). But when saved the on screen coordinates are
transformed back to 4326, which does not seem to be working.
If you switch the project code to use GeoModelAdmin instead(which creates an OL
map in epsg:4326) you should avoid this problem.
Original comment by dbs...@gmail.com on 23 Sep 2008 at 4:19
GoogleCodeExporter commented
Tyler,
So with a bit of help from the geodjango devs I think we've narrowed it down to a problem with your proj4
install.
It appears that gdal is used to reproject the vectors from 4326 to 900913 to display on the map. As long as
the shape looks good the first time viewed (as it sounds like it does for you),
this step is working fine.
The problem step is when the vectors are transformed back, and this step is done in database by postgis. It
seems likely that the proj data transform files are not being found by postgis.
So, you should try to reinstall
proj and postgis based on the instructions here:
http://geodjango.org/docs/install.html#building-from-
source
Original comment by dane.spr...@gmail.com on 23 Sep 2008 at 10:27
GoogleCodeExporter commented
Tyler,
So with a bit of help from the geodjango devs I think we've narrowed it down to a problem with your proj4
install.
It appears that gdal is used to reproject the vectors from 4326 to 900913 to display on the map. As long as
the shape looks good the first time viewed (as it sounds like it does for you),
this step is working fine.
The problem step is when the vectors are transformed back, and this step is done in database by postgis. It
seems likely that the proj data transform files are not being found by postgis.
So, you should try to reinstall
proj and postgis based on the instructions here:
http://geodjango.org/docs/install.html#building-from-
source
Original comment by dane.spr...@gmail.com on 23 Sep 2008 at 10:27
GoogleCodeExporter commented
Dane,
That seems reasonable, given that I built GEOS, PostGIS, and GDAL from source,
but
installed proj from the Ubuntu repository. Since the repository had proj
4.6.0, I
thought it met the requirements for geodjango.
I'll try building proj from source, and then report back on how that affects the
issue I am having.
- Tyler
Here is how I installed on the servers that are giving this error.
----------------------------------------------------------
cd ~/src
wget http://geos.refractions.net/downloads/geos-3.0.0.tar.bz2
tar xjf geos-3.0.0.tar.bz2
cd geos-3.0.0
./configure --prefix=/usr/local/geos/3.0.0
make
sudo make install
sudo aptitude install proj
Install PostGIS
cd ~/src
wget http://postgis.refractions.net/download/postgis-1.3.3.tar.gz
tar xzf postgis-1.3.3.tar.gz
cd postgis-1.3.3
PG_SHARE=`pg_config --sharedir`
./configure --prefix=/usr/local/postgis/1.3.3 --datadir=$PG_SHARE
make
sudo make install
cd ~/src
wget http://download.osgeo.org/gdal/gdal-1.5.2.tar.gz
tar xzf gdal-1.5.2.tar.gz
cd gdal-1.5.2
./configure --prefix=/usr/local/gdal/1.5.2
make
sudo make install
Original comment by tylerick...@gmail.com on 24 Sep 2008 at 2:31
GoogleCodeExporter commented
Right, okay. So the '$ sudo apt-get install proj' must not be sufficient to
correctly install the proj data shifting
files, noted in this footnote: http://geodjango.org/docs/install.html#id22
I did not anticipate this either since I forgot to add proj in the
UbuntuInstallation notes on the geodjango wiki.
I've updated that here:
http://code.djangoproject.com/wiki/GeoDjangoUbuntuInstall?action=diff&version=23
Maybe, after you rebuild you could add some further notes there.
Original comment by dane.spr...@gmail.com on 24 Sep 2008 at 2:55
- Changed state: Accepted
GoogleCodeExporter commented
Ok, everything seems to work now. Building proj from source (4.6.1) fixed my
problem.
Thanks for the link to the Ubuntu specific install, which I wasn't aware of. I
made
a few updates to the page.
Thanks for all your help!
Original comment by tylerick...@gmail.com on 24 Sep 2008 at 3:50
GoogleCodeExporter commented
Cool, kept this open for others in case they ran into it... but its fixed now,
so closing.
Original comment by dane.spr...@gmail.com on 12 Dec 2008 at 7:09
- Changed state: Verified
GoogleCodeExporter commented
also for me has worked updating proj from 4.6.0 to 4.6.1 (building it from
source)
Original comment by pco...@gmail.com on 8 Jan 2009 at 5:01
GoogleCodeExporter commented
Great, that's good to hear pcorti.
Original comment by dane.spr...@gmail.com on 8 Jan 2009 at 9:20
GoogleCodeExporter commented
If updating from proj 4.6.0 to 4.6.1 doesn't seem to fix it. What else can i
try?
Original comment by joost.ru...@gmail.com on 18 Feb 2009 at 8:09
GoogleCodeExporter commented
fyi: got it working after a fresh install of the slice i was using... (building
all
geo stuff from source, not using apt-get etc)
Original comment by joost.ru...@gmail.com on 18 Feb 2009 at 3:32
GoogleCodeExporter commented
I was almost killing myself because of that error, then I figured out my
Polygon was not closed. Reapeating the 1st point in the end solved it.
Original comment by sigil...@gmail.com on 10 Jul 2010 at 3:57