Clockwiseness detection broken #970
Comments
Author: chriscf Still there in 0.10b. Not so much detection, with some ways the direction is changed and gets stuck that way. See way 26435355 - http://www.openstreetmap.org/edit?lat=51.46587&lon=-3.16336&zoom=17 - selecting this way and retagging it (e.g. changing the name) results in the way being reversed from clockwise to anticlockwise. |
Author: jonathan.dickinson[at]k2.com Maybe you could pull it out for now. I certainly wouldn't mind changing the direction of each line in the way. |
Author: osm[at]randomjunk.co.uk It fails when the lowest, rightmost point is the first (and last) point in the polygon. This is because the algorithm on geometryalgorithms.com is expecting a polygon where V[n]=V[0], and it cleverly ignores point V[n]. What we have in OSM is a polygon such that V[n-1]=V[0] (V[n] is array index out of bounds), and you don't ignore V[n-1]. This difference means that the onLeft function will pick a degenerate case if it's node 0 that's lowest. ie: it picks nodes n-1, 0, 1 to do the calculation, except that n-1 == 0 (it's the same node), which means it always returns 0 (on the line, but which gets interpreted as anticlockwise). The Fix
Quick note: it's actually impossible for k==this.path.length given how onLeft is called... but we don't know who called onLeft so I've left it. |
Author: osm[at]randomjunk.co.uk
Actually these are degenerate polygons anyway, and we're not promising to cope with those... it's just a special case of self-intersection. Might as well do the quick method. |
Author: Richard /me applauds Utterly brilliant. Thank you. |
Author: Richard Fixed in 0.10d. |
Reporter: richard
[Submitted to the original trac issue database at 10.34am, Wednesday, 11th June 2008]
http://www.openstreetmap.org/edit?lat=51.70607&lon=-1.31916&zoom=17
Way 24777545 (outer part of polygon)
Clicking to reverse it doesn't appear to change the direction.
The text was updated successfully, but these errors were encountered: