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 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