[Community] How to deal with circle direction (CW/CCW) and invalid geometries

[Marc]

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

[Sean Gillies]

Hi Marc,

Post by Marc
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
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 Gillies]

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,

Post by Sean Gillies
Hi Marc,

Post by Marc
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
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
?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.

[Marc]

Post by Sean Gillies
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.

Hi,

Thank you very much for this new feature !

Cheers,
Marc