
Fíam » Horror story with GeoDjango - nside
http://fi.am/entry/horror-story-with-geodjango/
======
jbronn
_sigh_. This guy is intellectually dishonest. I tried to provide give two
comments on his blog, both of which he _refused_ to publish because they point
out mistakes he made. So instead, I'll just publish it here:

(1) DEBUG=False is not a fault of GeoDjango. By default when DEBUG is set,
Django logs all queries put through the ORM. When you're using SQL statements
with geometry values (which can be large), it's easy to exhaust the memory.
I'll make this clear when I complete the docs prior for 1.0.

(2) You are using DWithin at your own peril. DWithin can use indexes cause
because its a wrapper around Distance. Since you read the PostGIS docs so
closely, then I'm sure you're aware that Distance returns the "cartesian
distance between two geometries." If you're using WGS84 lat/lon coordinates,
then you're also using a cartesian distance calculation method on coordinates
in angular units. In other words, your distance calculations are wrong --
getting it right requires extra computation time.

(3) I've experienced problems with FastCGI, but have had no confirmations of
this problem outside my laptop. My guess it's actually an underlying conflict
with the latest version of flup and the use of ctypes. If you had taken this
part of your post and placed it in a ticket it could be fixed; at the least a
workaround would be provided. [Update: this problem is actually not related to
ctypes/flup -- see Django ticket #9437]

Finally, at no point did you try and address your problems by (i) writing a
message to the django-users list, (ii) filing a ticket explaining your
problem, or (iii) visiting the #geodjango IRC channel and simply asking a
question. Open source software is not a one-way street. If you had spent as
much effort on this gripe post as participating in the community then your
bugs and/or questions would have been addressed.

