As Karen noted, I last merged on 10/26 to r6613 -- thus, the latest GeoDjango is more up-to-date than your latest checkout of trunk (r5988).
> If the trunk and GeoDjango AREN'T currently compatible, would it be > possible for us to add geometry columns AFTER a syncdb creates the > "standard" model tables? Would the automatic admin still work in such a > situation? For all intents and purposes, the GeoDjango branch is identical to the latest merge of the trunk -- the largest difference is the addition of django.contrib.gis module. The rest of the changes to the trunk are limited in scope and few in number, and are only present to support the GIS features. There should not be a problem using GeoDjango for non-GIS Django applications. If you tried to interface with PostGIS geometry values on a vanilla trunk, you would most likely run into many problems -- a major one being that you would have to write your own custom field anyway for the admin to recognize the column, let alone manipulate its value. One possible route would be to inherit from TextField, but you'd be manipulating HEXEWKB (returned by PostGIS by default) in the admin, which isn't particularly intuitive. Moreover, you would have to write custom sql methods for each of the spatial operations you required. Thus, I have a feeling that implementing your own fields, and associated hacks to accomplish geospatial functionality may turn out being more "unstable" than just using GeoDjango to begin with. 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 -~----------~----~----~----~------~----~------~--~---
