Fíam » Horror story with GeoDjango

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.