#9877: More Pythonic mutations of geometry objects
---------------------------------------------------+------------------------
Reporter: Aryeh Leib Taurog <v...@aryehleib.com> | Owner: nobody
Status: new | Milestone:
Component: GIS | Version: 1.0
Keywords: | Stage: Unreviewed
Has_patch: 1 |
---------------------------------------------------+------------------------
Experimenting with geodjango, I found myself immediately wanting easier,
more Pythonic ways to manipulate the data in the GEOS geometry objects:
{{{
#!python
geometryObj[i:j] = ((33.42,-70.89),(34.819,-67.61))
}}}
So I have extended the !LineString and !LinearRing classes'
{{{__getitem__}}} and
{{{__setitem__}}} methods to allow slicing, added a {{{__delitem__}}}
while I was at it, and threw in most
of the non-special, standard list methods as well.
I'd like to do this for the geometry collections next, but I'm posting
this here (is there a better place?) to solicit feedback on these mods
before I continue.
== Questions ==
1. Is there some really good reason ''not'' to do this that I'm missing,
or am
I just the first one who wanted it enough to sit down and do it?
2. Did I do this correctly? It seems to work. I tested the correctness
of
the mutations themselves, but haven't extensively tested the GEOS
methods on the mutated objects.
3. I've created a situation where
{{{
#!python
del geometryObj[:] # now works
geometryObj = LinearString([]) # doesn't work
}}}
Is there some reason I shouldn't do that?
4. Does it make sense to implement similar mutation methods for
{{{Point}}}
objects or {{{Polygon}}} objects?
5. I think it would be nice to make the {{{LinearRing}}} mutations fool-
proof.
Meaning since the first and last point must be the same, a
{{{LinearRing}}}
object with ''n'' points should really behave like a list of ''n - 1''
coordinates, all the while maintaining the last coordinate as a mirror of
the first so that the geometry won't be invalidated by the mutations.
Comments?
6. I implemented {{{count()}}} which is redundant with {{{__len__()}}}
and, in this
case, {{{num_points()}}}. Overkill?
7. Also I'm not sure if {{{index(x)}}} and {{{remove(x)}}} made sense in
this
context, but I could imagine cases where they might be useful and so I
erred on the side of implementing as much of the standard list interface
as
I thought reasonable. Comments?
8. The {{{sort()}}} and {{{reverse()}}} methods don't seem applicable
here. These are the
only standard list methods which I did ''not'' implement. However, I
think
that they might apply to the geometry collections. Comments?
--
Ticket URL: <http://code.djangoproject.com/ticket/9877>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
