id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
9877	More Pythonic mutations of geometry objects	Aryeh Leib Taurog <vim@…>	jbronn	"
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?

"		closed	GIS	1.0		fixed			Accepted	1	0	0	0	0	0