More Pythonic mutations of geometry objects
|Reported by:||Aryeh Leib Taurog <vim@…>||Owned by:||jbronn|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Experimenting with geodjango, I found myself immediately wanting easier,
more Pythonic ways to manipulate the data in the GEOS geometry objects:
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.
- 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?
- 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.
- I've created a situation where
del geometryObj[:] # now works geometryObj = LinearString() # doesn't work
Is there some reason I shouldn't do that?
- Does it make sense to implement similar mutation methods for Point
objects or Polygon objects?
- 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.
- I implemented count() which is redundant with __len__() and, in this
case, num_points(). Overkill?
- 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?
- 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?
Change History (10)
comment:1 Changed 7 years ago by Aryeh Leib Taurog <vim@…>
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
comment:5 Changed 7 years ago by jbronn
- Owner changed from nobody to jbronn
- Status changed from new to assigned
- Triage Stage changed from Unreviewed to Accepted
comment:6 Changed 7 years ago by jbronn
- Resolution set to fixed
- Status changed from assigned to closed