If you build a geom with a bounding box that contains IDL (International Date Line) and run a point__within query on it, then the result is unpredictable and incorrect.
Does anyone know of a native GeoDjango solution to this? If not, would there be a lot of resistance against a patch that incorporates this functionality in GeoDjango? Val Sent from my mobile device. On 2013-03-17, at 12:39 AM, Omer Katz <[email protected]> wrote: > Well, I was wrong. It took me exactly 5 minutes to get the basics of > django-configurations right: https://gist.github.com/thedrow/5180120 > This gist loads settings from a class instead of a module and shows how to > load the settings from a module and override them by using a class. > All tests run correctly. > Are you guys still not convinced? > > > 2013/3/16 Omer Katz <[email protected]> >> Shai, >> The google groups editor is kinda annoying. I'll be using GMail from now on >> because it removes formatting on random basis (I don't really know why) >> >> Also, I can rewrite django-configuartion in a couple of hours using the >> changes in this patch. Heck, I'll even make a pull request out of it. >> >> Aymeric, >> I can revert this patch to be a refactoring if we decide that we don't see >> any value in the extensibility part of this patch. >> I hope we all agree that this patch does make the code much clearer and >> understandable. >> >> I'll get back to you guys when I'll have more progress. >> >> >> 2013/3/15 Aymeric Augustin <[email protected]> >>> On 15 mars 2013, at 09:22, Omer Katz <[email protected]> wrote: >>> >>> > Doesn't the fact that the patch makes the code clearer is a reason enough >>> > for a merge (providing that there will be tests attached to it and >>> > documentation)? >>> >>> >>> Hi Omer, >>> >>> This patch isn't only a refactoring; it adds a new feature. Otherwise you >>> wouldn't be talking about documentation. >>> >>> Each feature added to Django creates a burden: >>> - for users of Django, who must learn to use it; >>> - for the core team, who must maintain it for the foreseeable future. >>> >>> To be accepted, a new feature must: >>> (a) provide benefits that clearly outweigh these costs >>> (b) not get in the way of future improvements — as much as can be foreseen. >>> >>> Unfortunately (a) the benefits of your PR still aren't clear and (b) >>> judging by the discussion, your abstraction doesn't match very well the >>> needs of most users, and I suspect it could hinder further efforts to make >>> per-environment settings (the actual problem) easier to define. >>> >>> -- >>> Aymeric. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/django-developers?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
