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.

I generally agree, and sometimes i will delete a bad PGS feature to re-make it, but sometimes it's just as convenient to align it with JOSM's "improve way accuracy" tool.

Thank you very much! This greatly reduces the amount of work I have to in cleaning up OSM. I have done ~50 million nodes of import cleanup over 7 years, mostly NHD/Canvec in USA/Canada. It Vietnam could avoid excess in the first place, it will be very good.

Hi, I am unsure how you can avoid excessive nodes, because I don't know the process you are using to import. If the source you are importing from has this incredibly high node count, then you should run a "simplify" on the data before you upload it to OSM. If the source data is imagery, then it is inappropriate to derive data with higher precision than the source imagery. For example, if the maxar imagery being used has a resolution of 30cm, then the road data should not have node precision less than 30cm. Precision and accuracy are different things!

Hi Riyadi. Concerning the "source" tag on features, it is on the way to being deprecated; at the very least, it does not belong on new features. The source description belongs on the changeset, not every single feature that the changeset touches. In an environment such as OSM, there are a very large number of editors, and very few will respect or update the "source" tag on every element they touch; very quickly, the tag becomes inaccurate. I am not certain what you mean by "our" roads, but the roads of every country are the joint responsibility of all OSM editors, not any single group. If you want to do a search for which roads you have "input", the source tag is not the way to achieve that.

Hi Haris. While I appreciate your desire to "beautify" these roads, you are using far too many nodes. A road should have enough nodes to clearly define its location, no more. A good rule of thumb is to try reducing the line to a 20cm threshold; if nodes are removed, then they were excessive. Excessive nodes not only bloat the planet file, they also make the road much more difficult to maintain, because so many more nodes must be moved when the road is correctly. I will now have to clean up these excessive nodes you have made. At a quick glance, there are around 10,000 nodes that must be deleted in this (Thanh Chuong) are alone. Please stop!

Thanks, TheConductor. I defer to your local knowledge, although I did notice that the streambed in many places appears exceedingly narrow, so that even when water flows, it would not meet OSM's definition of a river, for those sections. In any case, I am just very happy that this river feature has someone looking out for it.