Hi all, I've added an is_ccw predicate to LinearRing for the upcoming Shapely 1.2.10. See https://github.com/sgillies/shapely/blob/master/shapely/algorithms/cga.py. The manual is also updated to show how to reverse the orientation of rings if they're not what you want.
Cheers, On Tue, Feb 15, 2011 at 12:53 PM, Sean Gillies <[email protected]> wrote: > Hi Marc, > > On Tue, Feb 15, 2011 at 2:35 AM, Marc <[email protected]> wrote: >> Hello, >> >> Some of you may have already seen this question on >> http://gis.stackexchange.com [1], sorry for this. I've been suggested to ask >> my question here, so here I am... >> >> I am translating an input that describes zones by mixing segments and >> arcs. Arcs are given by a center, 2 points (beginning/end of arc) and a >> direction (CW or CCW). In a first prototypes using GDAL, I inspected >> once how the points were sorted after the call to .buffer() and made the >> assumption that they will always be in the same direction. Then I moved >> my code to shapely, and it looks like the direction used is not the >> same, so I'm back to inspecting and hardcoding the internal direction. >> >> But my guess is that this is not the correct way of dealing with circle >> direction. Should I check after every calls to .buffer() the direction >> in which the points are ordered ? If so, is there a well known method to >> compute the direction ? >> >> I guess I could "easily" compute from 3 points the direction of the >> points. But maybe there is already something existing ? >> >> Since this question, I've had more problems, in particular regarding >> invalid geometries (see this other question[2]). Some of my polygons are >> self-intersected and I'm trying to correct these so that I can use >> shapely operations (intersect, union, etc). I've seen that in some case, >> using buffer with a very short radius fixes the problem. But in some >> case, the polygon ends up completely wrong. For example, the attached >> wkt has a single invalid polygon (it intersects near the start/end of >> the arc). Using buffer will create a flat polygon that is not really >> what I would expect. Is there any "common" way to correct such problem ? >> >> Thanks for any hint you can give :) I'm really fine with reading >> documentation & whatever, but I could not find anything regarding this. >> >> Marc >> >> PS: all the code is available here : https://github.com/dkm/airspace-checker >> >> [1]: original question: >> http://gis.stackexchange.com/questions/5862/how-to-deal-with-direction-cw-ccw-of-circles-in-particular-with-shapely >> >> [2]: >> http://gis.stackexchange.com/questions/5978/why-is-this-polygon-self-intersected-and-invalid > > Shapely accepts the coordinate ordering provided by users and also > whatever GEOS produces when making constructive operations. Support > for ordering geometries seems like a great feature to me. Would you be > willing to create a new issue at > https://github.com/sgillies/shapely/issues or send me a pull request? > > At the least, we could implement an is_clockwise (or is_ccw) predicate > for rings, based on a port of > > http://geos.refractions.net/ro/doxygen_docs/html/classgeos_1_1algorithm_1_1CGAlgorithms.html#e5 > > to Python, or addition of that algorithm to the GEOS C API. If a ring > didn't have the desired orientation, coordinates could be reversed by > slicing or with reverse(): > > ring.coords = list(reverse(ring.coords)) > > Note that coords of a Shapely object can't (currently) be modified in place. > > Invalidity: GEOS has some limited diagnostics that surface in Shapely > as I've described in > > http://gispython.org/shapely/docs/1.2/manual.html#diagnostics > > The answer could at least suggest where to zoom in with some other > tool to perform surgery on the geometry. > -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
