Re: Using GeoDjango features with current trunk?
On Nov 6, 9:17 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > ... > So anybody who's staying away from the GIS branch because of some > perception that it's less stable than trunk and they can do a better job > locally should re-evaluate. Trunk maintainers (well, at least one of > them) are paying attention to what's going on in the various branches > and looking for ways to make things easier in the background. It's solid > now and can only become less and less divergent over time. > Thanks, all. Thanks especially to Malcolm for assessing the stability. We are going to install and test using GeoDjango. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using GeoDjango features with current trunk?
On Mon, 2007-11-05 at 10:57 -0800, Justin Bronn wrote: > 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. Indeed. I spent a bit of time on Monday going through the differences between trunk and the GIS branch, looking at what ideas can be usefully merged back and how trunk can help out things like the GIS changes. Justin is to be commended for his reasonably unintrusive design changes. They look very restricted and unlikely to break anything. So anybody who's staying away from the GIS branch because of some perception that it's less stable than trunk and they can do a better job locally should re-evaluate. Trunk maintainers (well, at least one of them) are paying attention to what's going on in the various branches and looking for ways to make things easier in the background. It's solid now and can only become less and less divergent over time. Regards, Malcolm -- The hardness of butter is directly proportional to the softness of the bread. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using GeoDjango features with current trunk?
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 -~--~~~~--~~--~--~---
Re: Using GeoDjango features with current trunk?
I was in a similar situation a few months ago. The GeoDjango branch
api is really handy and I was hoping to use it on some models that
were sitting in a 0.96 release. We definitely couldn't go with the
unstable branch for our production environment so I ended up just
writing a few custom sql queries in my models to set the geometry
properties on textfields instead. One of my methods triggered by the
save method goes something like this:
def set_geom_properties(self):
"""
triggered by save method we set some geom properties
that we don't want to calculate everytime from postgis
"""
if self.polygon:
center = ''#get centroid of area
cursor = connection.cursor()
geom_q = """
select geometryfromtext('POLYGON((%s))',4269);
""" % (self.polygon)
cursor.execute(geom_q)
geom = cursor.fetchone()[0]
self.geom = geom
centroid_q = """
select x(centroid(transform(GeomFromEWKT('%s'),
4269))) as longitude, y(centroid(transform(GeomFromEWKT('%s'), 4269)))
as latitude
""" % (geom,geom)
cursor.execute(centroid_q)
lon, lat = cursor.fetchone()
self.centroid = "%f, %f" % (lat,lon)
When GeoDjango makes it into a stable release I will definitely use it
and just modify my code a little bit. Its also nice to know how to
setup your own geometry columns in postgis and do the queries.
-Matt
On 11/5/07, Hancock, David (DHANCOCK) <[EMAIL PROTECTED]> wrote:
>
>
> We're using the Django trunk (r5988), but are about to dive into adding some
> PostGIS geometry columns to a few of our models. It appears that GeoDjango
> is its own branch--has anyone got advice about whether we can use it with a
> more recent checkout than it branched from?
>
> The GeoDjango additions look quite easy to use, a plus for our organization
> that's just getting started with GIS.
>
> 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?
>
> Thanks in advance for any advice you've got. Django is becoming our tool of
> choice for data that needs to have an editing interface for internal use and
> be queryable from our other applications and website.
>
> Cheers!
> --
> David Hancock | [EMAIL PROTECTED]
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Using GeoDjango features with current trunk?
On 11/5/07, Karen Tracey <[EMAIL PROTECTED]> wrote: ... >You can check the branch log: > > http://code.djangoproject.com/log/django/branches/gis > > to see how current it is with respect to trunk. Look for the most recent > log message that starts "Merged revisions". In this case gis was updated > from trunk on Oct. 26 and contains all trunk changes through r6613. > All correct, thanks for the informative reply, Karen. One more note: the GeoDjango branch is off trunk because it's currently unstable in features and bugs. We'll be merging from trunk revs periodically, as well as committing bugfixes and new features to it. If you'll be using the branch, please be aware of which version you're running on and be careful updating both in terms of trunk rev on which it is based and features you depend on. The latest merge from trunk was done to include a security bugfix. Unless there is a similarly urgent reason, we'll try to pick a fairly stable trunk rev when we merge up. We'll be happy to support you in your use of the branch, of course, but understand that there are fewer people using the branch than trunk, so there are fewer people available to answer your questions. You should be prepared to be involved in troubleshooting the branch. Cheers, Jeremy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using GeoDjango features with current trunk?
On 11/5/07, Hancock, David (DHANCOCK) <[EMAIL PROTECTED]> wrote: > > We're using the Django trunk (r5988), but are about to dive into adding > some PostGIS geometry columns to a few of our models. It appears that > GeoDjango is its own branch--has anyone got advice about whether we can use > it with a more recent checkout than it branched from? > A branch is its own self-contained complete package, you use it by itself, not it along with some version of Django. The branch maintainer is responsible for periodically merging changes made to the trunk into the branch, so that the branch stays reasonably current with fixes and improvements made to the trunk. You can check the branch log: http://code.djangoproject.com/log/django/branches/gis to see how current it is with respect to trunk. Look for the most recent log message that starts "Merged revisions". In this case gis was updated from trunk on Oct. 26 and contains all trunk changes through r6613. Karen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
