OGR Failure on transform

1,639 views
Skip to first unread message

Ben Welsh

unread,
Jun 10, 2009, 10:32:26 PM6/10/09
to geod...@googlegroups.com
I have a view that spits out a simple polygon display after the polygon has been transformed to srid 900913. It has worked fine for a good period of time, but now is failing for only a select minority of the records in my geospatial model. The traceback looks something like this. Any idea what could be causing it? I suspect it isn't the GDAL_DATA directory error describe in the docs, since the view is working perfectly find for the majority of my records -- and had been working for these problematic records as little as a few hours ago.

Traceback (most recent call last):

 File "/usr/lib/python2.4/site-
packages/django/core/handlers/base.py", line 86, in get_response
   response = callback(request, *callback_args, **callback_kwargs)

 File "/home/djangouser/projects/mapping_la/views.py", line 117, in hood_detail
   object.polygon.transform(900913)

 File "/usr/lib/python2.4/site-packages/django/contrib/gis/geos/base.py", line 449, in transform
   g.transform(ct)

 File "/usr/lib/python2.4/site-packages/django/contrib/gis/gdal/geometries.py", line 353, in transform
   geom_transform_to(self._ptr, sr._ptr)

 File "/usr/lib/python2.4/site-packages/django/contrib/gis/gdal/prototypes/errcheck.py", line 107, in check_errcode
   check_err(result)

 File "/usr/lib/python2.4/site-packages/django/contrib/gis/gdal/error.py", line 39, in check_err
   raise e, msg

OGRException: OGR failure.

Malcolm Tredinnick

unread,
Jun 10, 2009, 10:42:45 PM6/10/09
to geod...@googlegroups.com
On Wed, 2009-06-10 at 19:32 -0700, Ben Welsh wrote:
> I have a view that spits out a simple polygon display after the
> polygon has been transformed to srid 900913. It has worked fine for a
> good period of time, but now is failing for only a select minority of
> the records in my geospatial model. The traceback looks something like
> this. Any idea what could be causing it? I suspect it isn't the
> GDAL_DATA directory error describe in the docs, since the view is
> working perfectly find for the majority of my records -- and had been
> working for these problematic records as little as a few hours ago.

I hate to ask the obvious question, but what might have changed on your
end in the past few hours? Server restart so it's now reading new code?
(if so, how old would the previous running code have been?) System
library upgrades (e.g. a "yum update" or apt update)? Computer programs
don't just get dusty and stop working, so something changed. Big
challenge is working out what that might be. Think hard about what might
be different now, as compared to the system as it stood at lunchtime
today.

Regards,
Malcolm


Dane Springmeyer

unread,
Jun 10, 2009, 10:49:56 PM6/10/09
to geod...@googlegroups.com
Hey Ben,

The first thing I would do is wrap that problem point like:

try:
object.polygon.transform(900913)
except Exception, E:
raise Exception('%s: geometry was: %s' % (E, objects.polygon.wkt))

Then send us along that error. Transforms into 900913 will bail for
malformed data or data that is outside the extent the projection can
handle (gt or lt 90 degrees for example).

Dane

Ben Welsh

unread,
Jun 10, 2009, 10:59:48 PM6/10/09
to geod...@googlegroups.com
Malcolm -- I'm totally tuned in to what you're saying, and I suspect it still might be the outcome. However, I've made no changes to the code today and already tried an apache restart. Though maybe I should clear out the cache and try a more thorough flush?

Dane -- thanks for the pointer. I've run what suggested and received the following, though I'm not sure what to make of it.

Exception: OGR failure.: geometry was: MULTIPOLYGON (((-13167638.3660707846283913 4039080.0822134194895625, -13167627.2341217044740915 4038999.4444553088396788, -13167638.3660707846283913 4038932.2467598738148808, -13167638.3660707846283913 4038891.9283330305479467, -13167638.3660707846283913 4038690.3383406507782638, -13167649.4980198703706264 4038273.7303345650434494, -13167638.3660707846283913 4038072.1512882355600595, -13167660.6299689486622810 4037910.8906207508407533, -13167660.6299689486622810 4037789.9466189639642835, -13167671.7619180269539356 4037574.9382321410812438, -13167671.7619180269539356 4037386.9436007272452116, -13167671.7619180269539356 4037131.6306293429806828, -13167750.2421590369194746 4037131.0931343892589211, -13167749.6855615843087435 4036983.8204727005213499, -13167749.6855615843087435 4036849.4492678265087306, -13167894.4008996132761240 4036849.4492678265087306, -13167894.5122191067785025 4036715.3483860222622752, -13167894.4008996132761240 4036580.7116142734885216, -13167894.4008996132761240 4036459.7817389895208180, -13167894.4008996132761240 4036325.4167168540880084, -13167894.8461775742471218 4036216.0447591221891344, -13167894.4008996132761240 4035855.1516217053867877, -13168039.1162376478314400 4035855.1516217053867877, -13168072.5120848789811134 4035855.1516217053867877, -13168161.5676775202155113 4035855.1516217053867877, -13168284.0191173870116472 4035908.8952213404700160, -13168406.4705572593957186 4035908.8952213367447257, -13168517.7900480553507805 4035908.8952213367447257, -13168640.2414879258722067 4035908.8952213404700160, -13168751.5609787199646235 4035908.8952213367447257, -13168862.8804695140570402 4035908.8952213367447257, -13168974.1999603006988764 4035908.8952213404700160, -13169097.0966781452298164 4035908.4921434046700597, -13169196.8389418926090002 4035908.8952213404700160, -13169330.4223308451473713 4035908.8952213404700160, -13169441.7418216448277235 4035908.8952213367447257, -13169553.0613124314695597 4035908.8952213367447257, -13169686.6447013840079308 4035908.8952213367447257, -13169809.0961412619799376 4035895.4592976579442620, -13169931.5475811269134283 4035908.8952213367447257, -13170120.7907154783606529 4035908.8952213404700160, -13170221.0895766858011484 4035908.8952213404700160, -13170343.5410165525972843 4035908.8952213367447257, -13170454.8605073504149914 4035895.4592976579442620, -13170588.4438963029533625 4035882.0233898274600506, -13170710.8953361790627241 4035868.5874978392384946, -13170762.5475799031555653 4035869.6623686212114990, -13170824.8864947445690632 4035867.5126271732151508, -13170866.7426232881844044 4035868.5874978420324624, -13170944.6662668399512768 4035882.0233898274600506, -13171044.8538085501641035 4035908.8952213367447257, -13171156.1732993479818106 4035949.2030874714255333, -13171278.6247392222285271 4035989.5110962577164173, -13171401.0761790890246630 4036043.2553298422135413, -13171523.5276189595460892 4036096.9998170374892652, -13171657.1110079213976860 4036164.0464203185401857, -13171556.9234662018716335 4036392.4646647535264492, -13171389.9442300107330084 4036755.2559984386898577, -13171245.2288919799029827 4037118.0588895250111818, -13171167.3052484262734652 4037118.0588895250111818, -13171089.3816048745065928 4037118.0588895250111818, -13170966.9301649965345860 4037118.0588895250111818, -13170811.0828778855502605 4037118.0588895250111818, -13170702.7690133471041918 4037117.6557687758468091, -13170664.5864280071109533 4037178.7959103784523904, -13170666.3675398547202349 4037333.0586496680043638, -13170666.3675398547202349 4037601.8140584705397487, -13170677.4994889330118895 4037830.2611434794962406, -13170688.6314380113035440 4038085.5897802961990237, -13170699.7633870895951986 4038367.8017775928601623, -13170610.7077944558113813 4038448.4350617029704154, -13170621.8397435378283262 4038582.8251376515254378, -13170632.9716926217079163 4038623.1424697893671691, -13170621.8397435378283262 4038824.7312722629867494, -13170621.8397435378283262 4039053.2028972427360713, -13170510.0749747753143311 4039056.8316012239083648, -13170376.9368637986481190 4039053.2028972427360713, -13170254.4854239169508219 4039066.6425474006682634, -13170132.0339840501546860 4039066.6425474006682634, -13169998.4505950994789600 4039066.6425474006682634, -13169875.9991552252322435 4039066.6425474006682634, -13169786.9435625914484262 4039066.6425474006682634, -13169731.2838171925395727 4039066.6425474006682634, -13169697.8879699483513832 4039066.6425474006682634, -13169608.8323773257434368 4039066.6425474006682634, -13169508.6448356080800295 4039066.6425474006682634, -13169452.9850902091711760 4039066.6425474006682634, -13169375.0614466574043036 4039066.6425474006682634, -13169330.5336503423750401 4039066.6425474006682634, -13169252.2760483026504517 4039069.4648759393021464, -13169163.5544141493737698 4039066.6425474006682634, -13169052.1236038599163294 4039066.6425474006682634, -13168919.5420903321355581 4039072.0184119022451341, -13168840.6165713518857956 4039066.6425474006682634, -13168773.8248768765479326 4039066.6425474006682634, -13168718.1651314832270145 4039066.6425474006682634, -13168640.5754463989287615 4039070.6744455322623253, -13168595.7136916108429432 4039066.6425474006682634, -13168495.5261498950421810 4039080.0822134194895625, -13168450.9983535818755627 4039080.0822134194895625, -13168361.9427609462291002 4039080.0822134194895625, -13168328.3242747224867344 4039073.2279817597009242, -13168183.8315756786614656 4039080.0822134194895625, -13168050.2481867186725140 4039080.0822134194895625, -13167938.9286959301680326 4039066.6425474006682634, -13167905.5328486878424883 4039080.0822134194895625, -13167771.9494597353041172 4039080.0822134194895625, -13167638.366070

Matt Bartolome

unread,
Jun 10, 2009, 11:14:28 PM6/10/09
to geod...@googlegroups.com
You could try to load the original polygon with fromstr() and see what
happens. Maybe the orginal polygon is corrupted somehow.

>>> from django.contrib.gis.geos import fromstr
>>> multipolygon = fromstr('the wkt from the polygon in question', srid=your_srid)

Looks like your wkt is cut off at the bottom.

Dane Springmeyer

unread,
Jun 10, 2009, 11:23:27 PM6/10/09
to geod...@googlegroups.com
Right,

Matt's thinking the same thing as I am.

But, I forgot that the geometry gets transformed in place, and ideally
we'd like to see the geometry pre-transform:

So try this:

try:
clone = object.polygon.clone()
object.polygon.transform(900913)
except Exception, E:
raise Exception('%s: geometry was: "%s", and is now: "%s" ' %
(E, clone.wkt,objects.polygon.wkt))

As an aside, it would be nice to know what postgis thinks about the
validity of the data:

What does this give:

Site.objects.extra(where=['NOT ST_IsValid(polygon)'])


Dane

Ben Welsh

unread,
Jun 10, 2009, 11:27:36 PM6/10/09
to geod...@googlegroups.com
Reverse order.

>>> GeoModel.objects.extra(where=['NOT ST_IsValid(polygon)'])
[]

Here's the clone try/except traceback

Exception: OGR failure.: geometry was: "MULTIPOLYGON (((-13167638.3660707846283913 4039080.0822134194895625, -13167627.2341217044740915 4038999.4444553088396788, -13167638.3660707846283913 4038932.2467598738148808, -13167638.3660707846283913 4038891.9283330305479467, -13167638.3660707846283913 4038690.3383406507782638, -13167649.4980198703706264 4038273.7303345650434494, -13167638.3660707846283913 4038072.1512882355600595, -13167660.6299689486622810 4037910.8906207508407533, -13167660.6299689486622810 4037789.9466189639642835, -13167671.7619180269539356 4037574.9382321410812438, -13167671.7619180269539356 4037386.9436007272452116, -13167671.7619180269539356 4037131.6306293429806828, -13167750.2421590369194746 4037131.0931343892589211, -13167749.6855615843087435 4036983.8204727005213499, -13167749.6855615843087435 4036849.4492678265087306, -13167894.4008996132761240 4036849.4492678265087306, -13167894.5122191067785025 4036715.3483860222622752, -13167894.4008996132761240 4036580.7116142734885216, -13167894.4008996132761240 4036459.7817389895208180, -13167894.4008996132761240 4036325.4167168540880084, -13167894.8461775742471218 4036216.0447591221891344, -13167894.4008996132761240 4035855.1516217053867877, -13168039.1162376478314400 4035855.1516217053867877, -13168072.5120848789811134 4035855.1516217053867877, -13168161.5676775202155113 4035855.1516217053867877, -13168284.0191173870116472 4035908.8952213404700160, -13168406.4705572593957186 4035908.8952213367447257, -13168517.7900480553507805 4035908.8952213367447257, -13168640.2414879258722067 4035908.8952213404700160, -13168751.5609787199646235 4035908.8952213367447257, -13168862.8804695140570402 4035908.8952213367447257, -13168974.1999603006988764 4035908.8952213404700160, -13169097.0966781452298164 4035908.4921434046700597, -13169196.8389418926090002 4035908.8952213404700160, -13169330.4223308451473713 4035908.8952213404700160, -13169441.7418216448277235 4035908.8952213367447257, -13169553.0613124314695597 4035908.8952213367447257, -13169686.6447013840079308 4035908.8952213367447257, -13169809.0961412619799376 4035895.4592976579442620, -13169931.5475811269134283 4035908.8952213367447257, -13170120.7907154783606529 4035908.8952213404700160, -13170221.0895766858011484 4035908.8952213404700160, -13170343.5410165525972843 4035908.8952213367447257, -13170454.8605073504149914 4035895.4592976579442620, -13170588.4438963029533625 4035882.0233898274600506, -13170710.8953361790627241 4035868.5874978392384946, -13170762.5475799031555653 4035869.6623686212114990, -13170824.8864947445690632 4035867.5126271732151508, -13170866.7426232881844044 4035868.5874978420324624, -13170944.6662668399512768 4035882.0233898274600506, -13171044.8538085501641035 4035908.8952213367447257, -13171156.1732993479818106 4035949.2030874714255333, -13171278.6247392222285271 4035989.5110962577164173, -13171401.0761790890246630 4036043.2553298422135413, -13171523.5276189595460892 4036096.9998170374892652, -13171657.1110079213976860 4036164.0464203185401857, -13171556.9234662018716335 4036392.4646647535264492, -13171389.9442300107330084 4036755.2559984386898577, -13171245.2288919799029827 4037118.0588895250111818, -13171167.3052484262734652 4037118.0588895250111818, -13171089.3816048745065928 4037118.0588895250111818, -13170966.9301649965345860 4037118.0588895250111818, -13170811.0828778855502605 4037118.0588895250111818, -13170702.7690133471041918 4037117.6557687758468091, -13170664.5864280071109533 4037178.7959103784523904, -13170666.3675398547202349 4037333.0586496680043638, -13170666.3675398547202349 4037601.8140584705397487, -13170677.4994889330118895 4037830.2611434794962406, -13170688.6314380113035440 4038085.5897802961990237, -13170699.7633870895951986 4038367.8017775928601623, -13170610.7077944558113813 4038448.4350617029704154, -13170621.8397435378283262 4038582.8251376515254378, -13170632.9716926217079163 4038623.1424697893671691, -13170621.8397435378283262 4038824.7312722629867494, -13170621.8397435378283262 4039053.2028972427360713, -13170510.0749747753143311 4039056.8316012239083648, -13170376.9368637986481190 4039053.2028972427360713, -13170254.4854239169508219 4039066.6425474006682634, -13170132.0339840501546860 4039066.6425474006682634, -13169998.4505950994789600 4039066.6425474006682634, -13169875.9991552252322435 4039066.6425474006682634, -13169786.9435625914484262 4039066.6425474006682634, -13169731.2838171925395727 4039066.6425474006682634, -13169697.8879699483513832 4039066.6425474006682634, -13169608.8323773257434368 4039066.6425474006682634, -13169508.6448356080800295 4039066.6425474006682634, -13169452.9850902091711760 4039066.6425474006682634, -13169375.0614466574043036 4039066.6425474006682634, -13169330.5336503423750401 4039066.6425474006682634, -13169252.2760483026504517 4039069.4648759393021464, -13169163.5544141493737698 4039066.6425474006682634, -13169052.1236038599163294 4039066.6425474006682634, -13168919.5420903321355581 4039072.0184119022451341, -13168840.6165713518857956 4039066.6425474006682634, -13168773.8248768765479326 4039066.6425474006682634, -13168718.1651314832270145 4039066.6425474006682634, -13168640.5754463989287615 4039070.6744455322623253, -13168595.7136916108429432 4039066.6425474006682634, -13168495.5261498950421810 4039080.0822134194895625, -13168450.9983535818755627 4039080.0822134194895625, -13168361.9427609462291002 4039080.0822134194895625, -13168328.3242747224867344 4039073.2279817597009242, -13168183.8315756786614656 4039080.0822134194895625, -13168050.2481867186725140 4039080.0822134194895625, -13167938.9286959301680326 4039066.6425474006682634, -13167905.5328486878424883 4039080.0822134194895625, -13167771.9494597353041172 4039080.0822134194895625, -13167638.3660707846283913 4039080.0822134194895625)))", and is now: "MULTIPOLYGON (((-13167638.3660707846283913 4039080.0822134194895625, -13167627.2341217044740915 4038999.4444553088396788, -13167638.3660707846283913 4038932.2467598738148808, -13167638.3660707846283913 4038891.9283330305479467, -13167638.3660707846283913 4038690.3383406507782638, -13167649.4980198703706264 4038273.7303345650434494, -13167638.3660707846283913 4038072.1512882355600595, -13167660.6299689486622810 4037910.8906207508407533, -13167660.6299689486622810 4037789.9466189639642835, -13167671.7619180269539356 4037574.9382321410812438, -13167671.7619180269539356 4037386.9436007272452116, -13167671.7619180269539356 4037131.6306293429806828, -13167750.2421590369194746 4037131.0931343892589211, -13167749.6855615843087435 4036983.8204727005213499, -13167749.6855615843087435 4036849.4492678265087306, -13167894.4008996132761240 4036849.4492678265087306, -13167894.5122191067785025 4036715.3483860222622752, -13167894.4008996132761240 4036580.7116142734885216, -13167894.4008996132761240 4036459.7817389895208180, -13167894.4008996132761240 4036325.4167168540880084, -13167894.8461775742471218 4036216.0447591221891344, -13167894.4008996132761240 4035855.1516217053867877, -13168039.1162376478314400 4035855.1516217053867877, -13168072.5120848789811134 4035855.1516217053867877, -13168161.5676775202155113 4035855.1516217053867877, -13168284.0191173870116472 4035908.8952213404700160, -13168406.4705572593957186 4035908.8952213367447257, -13168517.7900480553507805 4035908.8952213367447257, -13168640.2414879258722067 4035908.8952213404700160, -13168751.5609787199646235 4035908.8952213367447257, -13168862.8804695140570402 4035908.8952213367447257, -13168974.1999603006988764 4035908.8952213404700160, -13169097.0966781452298164 4035908.4921434046700597, -13169196.8389418926090002 4035908.8952213404700160, -13169330.4223308451473713 4035908.8952213404700160, -13169441.7418216448277235 4035908.8952213367447257, -13169553.0613124314695597 4035908.8952213367447257, -13169686.6447013840079308 4035908.8952213367447257, -13169809.0961412619799376 4035895.4592976579442620, -13169931.5475811269134283 4035908.8952213367447257, -13170120.7907154783606529 4035908.8952213404700160, -13170221.0895766858011484 4035908.8952213404700160, -13170343.5410165525972843 4035908.8952213367447257, -13170454.8605073504149914 4035895.4592976579442620, -13170588.4438963029533625 4035882.0233898274600506, -13170710.8953361790627241 4035868.5874978392384946, -13170762.5475799031555653 4035869.6623686212114990, -13170824.8864947445690632 4035867.5126271732151508, -13170866.7426232881844044 4035868.5874978420324624, -13170944.6662668399512768 4035882.0233898274600506, -13171044.8538085501641035 4035908.8952213367447257, -13171156.1732993479818106 4035949.2030874714255333, -13171278.6247392222285271 4035989.5110962577164173, -13171401.0761790890246630 4036043.2553298422135413, -13171523.5276189595460892 4036096.9998170374892652, -13171657.1110079213976860 4036164.0464203185401857, -13171556.9234662018716335 4036392.4646647535264492, -13171389.9442300107330084 4036755.2559984386898577, -13171245.2288919799029827 4037118.0588895250111818, -13171167.3052484262734652 4037118.0588895250111818, -13171089.3816048745065928 4037118.0588895250111818, -13170966.9301649965345860 4037118.0588895250111818, -13170811.0828778855502605 4037118.0588895250111818, -13170702.7690133471041918 4037117.6557687758468091, -13170664.5864280071109533 4037178.7959103784523904, -13170666.3675398547202349 4037333.0586496680043638, -13170666.3675398547202349 4037601.8140584705397487, -13170677.4994889330118895 4037830.2611434794962406, -13170688.6314380113035440 4038085.5897802961990237, -13170699.7633870895951986 4038367.8017775928601623, -13170610.7077944558113813 4038448.4350617029704154, -13170621.8397435378283262 4038582.8251376515254378, -13170632.9716926217079163 4038623.1424697893671691, -13170621.8397435378283262 4038824.7312722629867494, -13170621.8397435378283262 4039053.2028972427360713, -13170510.0749747753143311 4039056.8316012239083648, -13170376.9368637986481190 4039053.2028972427360713, -13170254.4854239169508219 4039066.6425474006682634, -13170132.0339840501546860 4039066.6425474006682634, -13169998.4505950994789600 4039066.6425474006682634, -13169875.9991552252322435 4039066.6425474006682634, -13169786.9435625914484262 4039066.6425474006682634, -13169731.2838171925395727 4039066.6425474006682634, -13169697.8879699483513832 4039066.6425474006682634, -13169608.8323773257434368 4039066.6425474006682634, -13169508.6448356080800295 4039066.6425474006682634, -13169452.9850902091711760 4039066.6425474006682634, -13169375.0614466574043036 4039066.6425474006682634, -13169330.5336503423750401 4039066.6425474006682634, -13169252.2760483026504517 4039069.4648759393021464, -13169163.5544141493737698 4039066.6425474006682634, -13169052.1236038599163294 4039066.6425474006682634, -13168919.5420903321355581 4039072.0184119022451341, -13168840.6165713518857956 4039066.6425474006682634, -13168773.8248768765479326 4039066.6425474006682634, -13168718.1651314832270145 4039066.6425474006682634, -13168640.5754463989287615 4039070.6744455322623253, -13168595.7136916108429432 4039066.6425474006682634, -13168495.5261498950421810 4039080.0822134194895625, -13168450.9983535818755627 4039080.0822134194895625, -13168361.9427609462291002 4039080.0822134194895625, -13168328.3242747224867344 4039073.2279817597009242, -13168183.8315756786614656 4039080.0822134194895625, -13168050.2481867186725140 4039080.0822134194895625, -13167938.9286959301680326 4039066.6425474006682634, -13167905.5328486878424883 4039080.0822134194895625, -13167771.9494597353041172 4039080.0822134194895625, -13167638.3660707846283913 4039080.0822134194895625)))"

Dane Springmeyer

unread,
Jun 10, 2009, 11:34:40 PM6/10/09
to geod...@googlegroups.com
Ah, nice.

So your geometries are valid... but if my code worked correctly (truly cloned the original geometry) it appears that your source data is already in 900913. If that is the case you surely cannot transform 900913 into 900913.

What is your geometry field 'srid' ?

Dane

Ben Welsh

unread,
Jun 10, 2009, 11:41:28 PM6/10/09
to geod...@googlegroups.com
The models.py snippet is:

polygon = models.MultiPolygonField(srid=4269)

Hmm. While this was all going on, I continued to backtrack and found that the polygon map widget in my admin was appearing blank in the four bad records -- unusual considering it had been filled earlier in the day. And also a little weird since that, we now see wrongly projected, data was appearing in the shell.

So what I did was take Matt's advice and reload just those bad records with fresh wkt from the development database, and found that the problem disappeared.

So, I guess, somehow the polygons got screwed today. And I'm really not sure how. I only have one trusted user in there, unless they're handing it out, and I'm not sure how they'd accomplish such a screw up through the admin. Hmm. I'll have to interrogate them a little tomorrow. But otherwise, I'm stumped, but at least temporarily happy the problem is fixed.

Thank you so much for the quick response, listers. The GeoDjango community continues to be a daily inspiration to me. And a reason to be excited to work in my weird profession at a time when there are a lot other reasons to be down.

Justin Bronn

unread,
Jun 10, 2009, 11:51:42 PM6/10/09
to geod...@googlegroups.com
Ben Welsh wrote:
> So, I guess, somehow the polygons got screwed today. And I'm really not
> sure how. I only have one trusted user in there, unless they're handing
> it out, and I'm not sure how they'd accomplish such a screw up through
> the admin. Hmm. I'll have to interrogate them a little tomorrow. But
> otherwise, I'm stumped, but at least temporarily happy the problem is fixed.

How did you install PROJ.4? See the footnote in the installation docs:

http://geodjango.org/docs/install.html#proj4

If you don't have the datum-shifting files installed (at `configure`
time) it can mess up geometries edited in the admin as you describe.

-Justin

Ben Welsh

unread,
Jun 16, 2009, 2:47:00 PM6/16/09
to geod...@googlegroups.com
Justin --

Thanks for the guidance. Taking your advice, I tried to backtrack my steps installing the dependencies. In my .bash_history I found the following order of operations. It looks like I followed the instructions properly, but I'm not sure. Would it matter which order I compiled it in comparison to the other dependencies?

# cat ~/.bash_history

...snip...

wget http://download.osgeo.org/proj/proj-4.6.1.tar.gz
wget http://download.osgeo.org/proj/proj-datumgrid-1.4.tar.gz
tar xzf proj-4.6.1.tar.gz
clear
cd proj-4.6.1/nad
tar xzf ../../proj-datumgrid-1.4.tar.gz
ls
cd ..
./configure
make
sudo make install

...snip...

And then, inspecting the source,

# ls /usr/local/src/proj-4.6.1/nad
FL.lla       README        epsg         nad83               pj_out27.dist      stpaul.lla   world
GL27         README.NADUS  esri         ntf_r93.gsb         pj_out83.dist      td_out.dist
IGNF         TN.lla        esri.extra   ntv1_can.dat        proj_def.dat       test27
MD.lla       WI.lla        hawaii.lla   ntv2_out.dist       proj_outIGNF.dist  test83
Makefile     WO.lla        makefile.vc  null.lla            prvi.lla           testIGNF
Makefile.am  alaska.lla    nad.lst      nzgd2kgrid0005.gsb  stgeorge.lla       testntv2
Makefile.in  conus.lla     nad27        other.extra         stlrnc.lla         testvarious

Ben Welsh

unread,
Jul 15, 2009, 7:09:48 PM7/15/09
to geodjango
This a problem I set aside for the moment because I didn't require the
fix, but I'm hoping to address it again now.

Again, the errors only arose after I installed GeoDjango on a new
machine, which now serves as a dedicated database server.

Because of that background, I suspect the culprit is probably -- as
Justin suggests -- in that installation process somewhere. However, as
I pasted above, I think I did compile PROJ.4. along with GEOS.

I just ran my geos tests again and seemed to pass, though I'm not sure
if it's even verified here. I've pasted that below. Could it be a
problem with GDAL or something else in the installation process?

If anyone has any ideas, I'd greatly appreciate to hear them. And if
there's any more information I could provide, feel free to prod me.

Thanks,

Ben.

>>> from django.contrib.gis.gdal import HAS_GDAL
>>> print HAS_GDAL
False
>>> from django.contrib.gis.tests import test_gdal
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/django/contrib/gis/tests/
test_gdal.py", line 8, in ?
from django.contrib.gis.tests import \
File "/usr/lib/python2.4/site-packages/django/contrib/gis/tests/
test_gdal_driver.py", line 2, in ?
from django.contrib.gis.gdal import Driver, OGRException
ImportError: cannot import name Driver
>>> from django.contrib.gis.tests import test_geos
>>>
>>> test_geos.run()
Testing WKT output. ... ok
Testing HEX output. ... ok
Testing KML output. ... ok
Testing the Error handlers. ...
BEGIN - expecting GEOS_ERROR; safe to ignore.

GEOS_ERROR: ParseException: Expected number but encountered ','
GEOS_ERROR: ParseException: Unknown WKB type 255

END - expecting GEOS_ERROR; safe to ignore.

GEOS_ERROR: ParseException: Unexpected EOF parsing WKB
ok
Testing WKB output. ... ok
Testing creation from HEX. ... ok
Testing creation from WKB. ... ok
Testing EWKT. ... ok
Testing GeoJSON input/output (via GDAL). ... ok
Testing equivalence. ... ok
Testing Point objects. ... ok
Testing MultiPoint objects. ... ok
Testing LineString objects. ... ok
Testing MultiLineString objects. ... ok
Testing LinearRing objects. ... ok
Testing Polygon objects. ... ok
Testing MultiPolygon objects. ...
BEGIN - expecting GEOS_NOTICE; safe to ignore.

GEOS_NOTICE: Duplicate Rings at or near point 60 300

END - expecting GEOS_NOTICE; safe to ignore.

ok
Testing Geometry __del__() on rings and polygons. ... ok
Testing Coordinate Sequence objects. ... ok
Testing relate() and relate_pattern(). ... ok
Testing intersects() and intersection(). ... ok
Testing union(). ... ok
Testing difference(). ... ok
Testing sym_difference(). ... ok
Testing buffer(). ... ok
Testing the SRID property and keyword. ... ok
Testing the mutability of Polygons and Geometry Collections. ... ok
Testing three-dimensional geometries. ... ok
Testing the distance() function. ... ok
Testing the length property. ... ok
Testing empty geometries and collections. ... ok
Testing `ogr` and `srs` properties. ... ok
Testing use with the Python `copy` module. ... ok
Testing `transform` method. ... ok
Testing `extent` method. ... ok
Testing pickling and unpickling support. ... ok

----------------------------------------------------------------------
Ran 36 tests in 0.456s



On Jun 16, 11:47 am, Ben Welsh <ben.we...@gmail.com> wrote:
> Justin --
>
> Thanks for the guidance. Taking your advice, I tried to backtrack my steps
> installing the dependencies. In my .bash_history I found the following order
> of operations. It looks like I followed the instructions properly, but I'm
> not sure. Would it matter which order I compiled it in comparison to the
> other dependencies?
>
> # cat ~/.bash_history
>
> ...snip...
>
> wgethttp://download.osgeo.org/proj/proj-4.6.1.tar.gz
> wgethttp://download.osgeo.org/proj/proj-datumgrid-1.4.tar.gz

Ben Welsh

unread,
Jul 15, 2009, 8:42:00 PM7/15/09
to geodjango
You know what. I think I might have figured it out and, who would have guessed, I think the idiot user might have been the problem.

I found a dangling admin.pyc file hanging around on the server that is the ghost of a similar, identically name, set of instructions to ones I wrote for a new app.

I had long-since removed the admin.py file that came with it, but perhaps the pyc was still firing and registrations on the new admin crossed the wires with the old pyc file.

I'm not sure that's it, but removing that pyc file and restarting apache seems to have aced the problem.

If that was indeed it, sorry to have wasted everyone's time.

Ben.
Reply all
Reply to author
Forward
0 new messages