OpenStreetMap
How to draw correctly sized round circles in Potlatch 2.
Posted by z-dude on 12 February 2011 in English.1. First, let potlatch 2 draw an incorrectly sized circle for you.
Basically, I start at the top of a circle, and draw 8 points, 45 degrees apart.
Then I hit the circle icon. This will typically give you a circle a totally different size from what you roughly sketched out.
2. Move that wrong sized circle next to the circular object you're drawing.
3. Press the 'copy parallel' button. As you move the mouse, a circle copy of a different size will be made.
Just move the mouse till the copied circle is the right size.
4. Move the copied circle to the right spot. Click on a circle segment (not a node) and drag it to the correct position.
Here's my suggestion for fixing the circle tool.
First, it should calculate the centroid of the points in the polygon you used.
Add up the X' coordinates, and divide by the number of nodes. Add up the Y coordinates, and divide by the number of nodes. Unless you're drawing a circle on the 180th meridian, this should give you the correct center point.
Second, it should calculate the average radius. Calculate the distance from the centroid for each point in the polygon, and divide by the number of points. Voila, average radius.
Use a 'for loop' to create a new set of points at radius r and incrementing the angle.
Judging by the behaviour of the current circle tool, I'd guess it's trying to do a 'curve fit', but it's acting up for me.
Discussion
Comment from compdude on 12 February 2011 at 05:17
Yes, I've noticed that it's being kinda strange. The circle tool in Potlatch 1.4 works just fine, so I just use that whenever I want to draw a roundabout/ circle.
Anyway, that's a great technical description.
Comment from stevage on 12 February 2011 at 09:17
Nice writeup. Circle has never worked for me in P2, but others claim that it does. The centroid is already calculated for every closed way. The only issue in implementing what you suggest is potentially losing history of some of the nodes, since you're basically talking about discarding all the old nodes and creating new ones.
I do like your thinking though.
Comment from stevage on 12 February 2011 at 10:21
Had a closer look. Actually, circularise seems to work most of the time for me (at least in the development version). But I found some cases (mostly rectangles) where it is calculating the distance wrong, and probably the centre too (which would cause the distance miscalculation). With some of these, nudging the whole rectangle up or down a tiny amount would cause huge differences in the calculations - shifting the centre east or west of the original centre.
I think the best solution will be to move the centroid calculation from WayUI into Way (as already suggested in the code), and to use that in Circularise. Rather than having two different centroid calculations, at least one of which is clearly buggy.
Comment from stevage on 12 February 2011 at 10:57
Hmm, interesting, I just implemented the naive "average X and Y" algorithm the OP suggested and...it works great. Perfect results every time. I'll have to do some more testing to make sure I'm not missing anything, but it seems a lot simpler than the "mathematically correct" algorithm currently implemented, and without the bugs.
(Btw the WayUI algorithm is buggy in the same way as the Circularise one, but presumably the results just aren't as noticeable.)
Comment from z-dude on 12 February 2011 at 16:37
Well, from a testing point of view, I expect the centroid and 'average r' algorithm to have issues at boundary conditions.
This circle idea would have boundary condition issues at the 180 degree meridian, north pole, and south pole. (ie, exception handling for a circle with some point at +179.99 degrees west and 179.99 degrees east)
Mapwise, It also assumes a 'small circle' for a flat earth projection so drawing the arctic circle, or a 200 mile radius around a Island would result in an inaccurate projection onto the earth's curved surface.
Comment from stevage on 12 February 2011 at 17:18
Ok, I've added this in http://trac.openstreetmap.org/changeset/25276.
Comment from z-dude on 12 February 2011 at 17:36
@stevage. the bugginess you describe sounds a bit like floating point rounding errors (ie, different results when you move the polygon slightly)
Is the algorithm using float or double?
If float only has 6 or 7 significant digits...
49.2778222, -122.8891881 to 49.2778689, -122.8894348
would numerically look like 49.22782,-122.8891 to 49.22787,-122.8894
then subtracting point 1 to point2 would give .00005,.0003 which would give a very crude circle.
sorry to be a backseat driver, I don't have access to the code, so I'm making assumptions. The behaviour you described does sound a bit like a rounding issue though.
It would probably be better to fix the mathematically perfect algorithm than to switch to this 'flat earth' style algorithm.
Comment from z-dude on 12 February 2011 at 17:45
edit to add.. ok, just saw the code in the trac report. I was thinking back to my old software testing days, and looked up java floating point accuracy, and got http://mindprod.com/jgloss/floatingpoint.html which had me think that perhaps java was using float for 7 digit accuracy instead of double.
Sorry if I'm being a back seat driver.
Take care.
Comment from z-dude on 12 February 2011 at 18:13
another edit to add... I just went and tried some edits in the Mediterranean, and did not see circle fit issues, but going back to BC, I see the issues again.
I think that what I'm doing is getting my mind stuck on one train of thought about it being a rounding issue. Perhaps the people for whom the circle editing works are doing their edits near the prime meridian, and the Pacific coasters are the only ones complaining about circle issues because we have coordinates like -122.something
http://www.openstreetmap.org/?lat=49.2788690328598&lon=-122.888292074203&zoom=17
Comment from stevage on 13 February 2011 at 00:53
Hi Alex, no worries about being a 'back seat driver' - it's open source after all. You can see the code here: http://trac.openstreetmap.org/browser/applications/editors/potlatch2/net/systemeD/potlatch2/tools/Circularise.as
That mindprod.com link you post also suggests that the use of Math.pow to compute squares could be causing a problem.
One other thing to remember about this issue, though, is that the goal is usability: to compute a circle that reflects as closely as possible what the user wanted. So this very simplistic algorithm I've implemented has some deficiencies (eg, a way with lots of nodes at one place, and a single outlier, will produce a circle clustered around all the nodes) - but they're not necessarily bad for usability. So I think the needs of a centroid computation for Circularise are different from the needs of the WayUI centroid computation (which has to put the label for a way in the "middle" of it...)