> This is precisely the kind of pointer I was looking for. I've read the > documentation about a PointField, but wasn't sure what the application > was or how it works with the rest. Here's a silly question: I can > mixin theseGeoDjangofield types with the base field types from > Django, right? So, my model could have DateTimeField, PointField, > CharField etc.? >
Most definitely. GeoDjango would honestly suck if you couldn't use Django's other fields in the same model. > This is in the docs, I'm sure, but is that GeoQ subclassed from the > "normal" Q object so that it has all the properties of Q combined with > GeoQ? > Yes, `GeoQ` is subclassed from `Q` -- basically it is overridden to use `GeoQuerySet` instead of `QuerySet` so that the OR'ing and AND'ing of conditionals will work with geometry fields. When queryset- refactor is merged to trunk, `GeoQ` will no longer be required (but will still be around for backward-compatibility). > Thanks so much for your response. This is great info for anyone > starting out. I certainly appreciate the specific pointers into the > docs as well. It really helps to have a subset of this stuff to start > to get familiar with. > Yes, I agree -- kudos to Nathaniel for providing a robust and informative response to your original inquiry. Best Regards, -Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
