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.

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","0106000020E61000000100000001030000000100000005000000E7723106D6C11D40FC7B7F83F6E0454048471FF301911D40D4A6954220DD45406890F469158D1D40E0D38041D2DF45402806820019AA1D40B8E67283A1E24540E7723106D6C11D40FC7B7F83F6E04540","SRID=4326;MULTIPOLYGON(((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","0106000020E61000000100000001030000000100000005000000E1723106D6C11D40F67B7F83F6E045400118079E6D71B33ECA83538B69C1DC3EA9D92F07D96EB33E60792D09F5C4DC3E6B883775ED81B33E61183803A7C8DC3E8E9A31BF8991B33E0382A96A75C6DC3E","SRID=4326;MULTIPOLYGON(((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.

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"

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?

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.

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

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

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

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.

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!

Cool, kept this open for others in case they ran into it... but its fixed now, so closing.

also for me has worked updating proj from 4.6.0 to 4.6.1 (building it from source)

Great, that's good to hear pcorti.

If updating from proj 4.6.0 to 4.6.1 doesn't seem to fix it. What else can i try?

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)

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.