Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
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
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
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
Great, that's good to hear pcorti.
Original comment by dane.spr...@gmail.com
on 8 Jan 2009 at 9:20
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
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
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
Original issue reported on code.google.com by
tylerick...@gmail.com
on 22 Sep 2008 at 9:10