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.

@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.

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.

you might be able to track down the deleted segment by clicking on a node that was in the deleted segment. When you added the u turn, you would have created a pair of nodes on the two connected ways and those two nodes should be on the two motorways still.

in potlatch 2, you can click on a node and get the history of the node, and find the changeset where that node was created... the find the deleted segment from that changeset, and who deleted the u-turn.

It might help to point out to them that the u-turns are actually there. I'm guessing it's someone who is using the keepright.ipax.at website to identify 'problem areas' and keepright flags service roads connected to motorways as a 'problem'.. so maybe someone was trying to 'fix' something reported by keepright. /just speculating.

Good content. I think the audio had a low pass filter on it though. If so, I'd suggest less low pass filter effect.

Only Outlaws use GPS's.

You'll find that it helps to do one type of error at a time and one neighbourhood at a time .. ie, do the 'close nodes' first in a neighbourhood, then do the 'intersections without nodes'.

I found the potlatch link in keepright to be handy.
http://keepright.ipax.at/report_map.php?zoom=12&lat=19.35403&lon=-99.29497&layers=B00T&ch=0,191,270&show_ign=1&show_tmpign=1

Fixing keepright issues is ok for armchair mapping on a rainy day. it helps to have imagery that makes it clear if there's an intersection or not. I think that the misconnected nodes are due to mappers getting tired, or mappers working with a potlatch client that lost it's connection to the server.

Looks nice.
Only Issue I see is a couple of unconnected intersections, but that's a common issue in OSM.

osm.wiki/Name

They list local names, regional names, official names, old names, national and international names.

in my area BC, I see leisure=nature_reserve
osm.org/?lat=49.35094&lon=-122.93087&zoom=15&layers=M

In Washington State, they use a multi-polygon relation to handle multiple park types.
osm.org/?lat=48.0968&lon=-123.8812&zoom=13&layers=M

In California, they seem to use the park:type=state_park to designate a state park.
osm.org/?lat=41.7404&lon=-124.11028&zoom=15&layers=M

.. or it could be a computer hardware bug. Maybe a bit got flipped in the render process and the computer rendered the road as if it were shifted 20 miles to the east.

I think the horizontal lines to the east of that location may have been caused by panning in potlatch 2. Instead of panning, someone clicked a section of road, and shifted it a lot without realizing it... then panned west to do their editing.

by panning, I mean, clicking on the map's background, shifting the map.

Relations are a difficult concept for some people. Creating a relation adds to the number of clicks a user has to make to edit something.

I think it's better to keep things simple.

What if your utility info is inaccurate? But people rely on it as fact?

http://envirolaw.com/burnaby-oil-spill/

If you add a pipeline to OSM, how accurate is the placement? Are you using accurate data in the first place? (ie data from 1957) What if natural ground movement moved the location of the pipeline? (all mountains move, even if it's a mm a year) What if the 'as built' did not match the as drawn engineering drawing?

I agree. It's frustrating. I had backed up my paths on the bikely website, and the backed up gpx traces weren't compatible with the OSM site (something about not having timestamps or something)
The link that came with gpx failures
osm.wiki/GPX_Import_Failures#Why_didn.27t_my_GPX_file_upload_properly.3F is a technical read.

Myself, I don't understand why OSM requires timestamps in gpx files, but then allows the user to strip that out later on when making it public.

spam

You'll probably find that their algorithm varies from year to year to accomodate new features like environmental drives, bikes, pedestrians.

I think the Basemap is involved in calculating long routes. When I had 'route calculation errors' from routing with a OSM map, I found the basemap mentioned when I google'd the 'route calculation error' issue.

I also had issues with bike routing when I had a 2.8 Gigabyte OSM map, and the routing issues (it routed me 200 kms extra through Pemberton instead of to the north side of Lions Bay) to my destination disappeared when I replaced that map and used a 226 megabyte map for my local area instead. So, I think the way the .IMG file is created can play a role in routing.

What I think will happen, is that Garmin will realize that their device sales in poorly mapped areas is increasing because there are now more detailed maps for places like Haiti, Bamako, the Phillipines, etc, and change their algorithm to support the existing state of the map.

Thanks for posting that. I just tried to get Bing working with josm, and it finally worked. It wasn't previously clear to use it because I previously heard about things like slippymap, and plugins, but the wiki helped instead. osm.wiki/Bing#Using_Bing_imagery now I have to figure out JOSM editing.

in potlatch 2, you draw start by drawing a line, tracing around the object, and closing the loop by clicking the start point.
You now have a closed loop element. (also known as a Closed Way osm.wiki/Element#Area_.28closed_way_.29 )

To tag the way as something, click a line segment, and it will highlight the whole loop. Then from your menu, you can pick things like 'land use' being a sports field, or Building to be a building or a school, etc.

When you highlight an area, and you drew it by tracing imagery, press the B key on the keyboard, and it will add a 'source = bing" tag .. this helps prove to the world that your building came from an open source, rather than copying a copyrighted map.

For manual creation of an image with your route overlaid.
An application called Mobile Atlas creator http://sourceforge.net/projects/trekbuddyatlasc/ will be able to create a map and output it as a kmz file, or a .png file with a calibration file (for oziexplorer)

For sharing your route on the net.
For websites, there's bikemap.net which will let you share your routes and the user can pick the OSM or Opencyclemap as the background that the route is printed over.
I like Opencyclemap as an overlay, as it lets you see topo lines of the ride. The downside is that the opencyclemap server is owned by one guy, and he needs help scaling things up to handle the traffic, or help paying for the overhead.