search

vpistis / geodjango-basic-apps

Automatically exported from code.google.com/p/geodjango-basic-apps
0 stars 0 forks source link

Django returns error after modifying country boundary polygon #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
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 8 years ago 
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 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
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 8 years ago 
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 8 years ago 
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 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
Great, that's good to hear pcorti.

Original comment by dane.spr...@gmail.com on 8 Jan 2009 at 9:20

GoogleCodeExporter commented 8 years ago 
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 8 years ago 
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 8 years ago 
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