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. Cheers, -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
