Hi, please use fewer nodes for your ways with irrigation=pivot. I have to come thru after you, and reduce them to a 30cm threshold. There is nothing in an agricultural area which is more precise than 30cm.

I'm delighted, BTW, that you are dedicated to fixing up golf courses, in all of OSM they are usually among the worst offenders, not just of overnoding, but also messy geometry, inconsistent tagging, sometimes inappropriate micromapping, and more.

I'm happy to coordinate, tho I guess I'm unclear on the issue. If a golf feature with 300 nodes and an overlap is on your list to get around to fixing, me going in there are reducing it to 100 nodes shouldn't make more work for you, right? Still just one feature on your todo list, and maybe zero if the error is easily found/fixed with the JOSM validator.

Should be fine. I'm working my way thru the state extracts and I'm already on Indiana, Iowa is next.

Culinary lol autocorrect. Colinear, of course.

Hi, yes happy to share the method. I use an osmium app called find_small_displacements which I run on geofabrik extracts, e.g. illinois-latest.pbf. It produces a sorted list of the OSM ways with the highest number of culinary or almost-colinear nodes. I pick just a few of the worst ways in a region, and usually they are not allowed, e.g. if a golf course pond was made with 300 nodes, then the other ponds in that course are usually bad too. Then I carefully select only the worst ways and carefully chose an appropriate threshold that will reduce overnoding, then usually run JOSM validation on the area after.

I appreciate your dedication to manually caring for these roads. In this case, the threshold was only _20cm_. That is just under 8 inches. No nodes were moved, and the interpolated way did not move by more than 8 inches. Even in cases of extreme micromapping, 8 inches should neither be visible nor require anyone to "go back thru them". Trust the geometric algorithm.

I'm glad to hear that the demarcation is not that old, tho the map features they may have used to digitize at that time may have been. In any case, it's a good idea before uploading imports to do a Simplify with a small value; in this case I used 30cm which is very small, in a typical satellite image it is less than one pixel. Cleaning nodes with a small threshhold does not move the feature in any significant way, and it has all the advantages of map data that is easier to maintain and serve.

Don't worry, it is only improved. Keep in mind that BLM (like USGS NHD, etc.) is just a set of points digitized (often in the 1970s) from paper maps, with all sorts of artifacts, inaccuracies and inefficiencies. These come into OSM often minimally edited, resulting in redundant ways, overnoding, and innacuracies preserved sometimes from decades ago. When cleaning these up, great care is taken to follow the actual bounds, where is it often easy to see where the original dataset's shortcomings, e.g. when a boundary should follow a river but was made from inaccurate river data long ago.

Yes. Reducing overnoding (of nearly colinear nodes) is valuable in many ways; it makes editing and maintenance easier, it speeds every aspect of serving maps. I'm happy to explain further.

I went back just now and did a few more fixes on that golf course, including where the path has tunnels. I didn't see any crossing ways to fix.

Hi b-jazz, yes I was only doing cleanup, and I do try to validate the features as I go, but there are many weird golf courses in the world which the JOSM validator can't catch. Thanks for your vigilance on golf messes :)

Unsure. Apparently the source of this feature is an import from "NCOnemap" so veracity would either have to go to that source or correct it.

I did not use GPX. As the tags say, source=Bing.