Thanks for the heads up. First, I am up-to-date on F-Droid at 43.0. Second, I knew better than to add crossing info through StreetComplete but I did so anyway, while pumping gas. Both StreetComplete and iD have presets that are making crossing info useless for accessibility routing. Such a shame. A driveway either needs a special tag "crossing=driveway" or shouldn't be tagged at all. I understand, there is a lot of pressure on both projects to continually add features/presets even if they aren't appropriate and in some cases, like this one, are destructive. I'll remove my tag and leave yours, out of respect. Though, I strongly recommend that you remove any crossing related tags you've put on driveways or create a useful (and new) tag to distinguish highway crossings from driveway crossings.

In this change set, the project URL, barrier=fence, and construction area were deleted. Was this intentional? I don't want to return them if you removed them for a reason.

Yes, I intentionally used degrees of rotation (or "Angles" as OSM wiki refers to it). Cardinal directions would have been equally applicable.

direction=*

I'm glad we understand each other.

Thank you for the slack link but slack is a side channel and not an official OSM communication channel. It is not one of the appropriate places to bring this issue up to the community. I do not have a slack account and I do not wish to create one nor is it appropriate for you to expect that I should.

Since it is clear that reverting these changesets myself is not an action that the community would condone and I have seen people whom bring very legitimate issues up to the DWG get threatened with a ban, I guess you get your way. I, like most of the OSM community, is powerless. Feel free to continue to dilute the database with pride. From what I can tell, you are in good company.

This very well may be my final days in the project. We will see.

Just so that we are clear. You are comfortable with defending your estimated error of 100 bad poi based on nothing but wishful thinking. I’ll remind you that you have already received 8 confirmed bad pois, which is awfully close to your lowest estimate of 10.

You both find this data important enough to import and are comfortable with shouldering the OSM community with correcting your erroneous data. I assume are not planning on informing the community that they now have 30,000 pois to check. You are not bothered by all by 30.000 pois that most likely have names that do not conform to OSM’s agreed upon naming scheme. Technically, that would bump up the number of erroneously imported pois to 100%.

You are begrudgingly willing to revert this valuable data but you refuse to revisit this import if it requires you to abide by the wishes of the greater OSM community and follow the import process.

You feel that because other OSM contributors imported erroneous data against the wishes of the OSM community that it makes further poor quality imports acceptable. You feel that because there have been times where the OSM community has willingly accepted a certen level of bad data from imports that this somehow means that you are grated the same green light for your import yet without needing an acknowledgment or agreement from the OSM community. You feel that repeating bad behavior and adding to poor quality data is preferable to presenting your import to the community.

I hope I captured what you are saying correctly.

I take you at your word that this was not employment related for any 3rd party. In that regard, I’d like to apologize to you. I do not wish to impugn your character or that of the company you work for. Not as a defense but simply as an explanation. I clearly inferred incorrectly a potential motivation which was from your statement, “on a data consumer for this scheme”. I better understand what you were saying. Again, my apologizes.

I wish you hadn’t named the company you work for and I employ you to not name your employer. They were both referenced to better frame my concerns. I did not name either because I have no reason to believe your actions are anything other than your own.

Please, revert this import and follow the Import Guidelines.
osm.wiki/Import/Guidelines

There are two stations in my area that have moved less than a mile away. They are now double mapped. I picked a random firestation and Node: Somerset Volunteer Fire Department (9365469104) appears to be a sign and t-shirt shop. Obviously, these issues are on-top of the Oswego, Chicago, and Spokane issues.

Also, copying the name field of the USGS database directly into OSM may have been a bad choice. It appears that some of those names do not exactly adhere to OSM's naming conventions. Following the Import process would have given the community an opportunity to help you make a much more useful and less error prone import. As of this moment, the wider community now has work they didn't ask for in cleaning up your import that is spread all over the US.

Thank you and happy mapping.

Please, please, please help me understand how your proposal is significantly different than the solidly rejected and much more flushed out Mapping disputed boundaries proposal? osm.wiki/Proposed_features/Mapping_disputed_boundaries

Please, please, please walk me to the place where inserting this scheme into OSM, for the benefit of your customers and your company, is fundamentally different than corporate takeover of tagging? Maybe I have this all wrong. I see that Lyft has also just pretended to honor the proposal but ended up just doing what they wanted. [key:rideshare proposal]. I am happy to do away the proposal process, if that is the will of the community.
Unlike access tags for rideshare, disputed boarders is a very sensitive and contentious issue both internally, to the OSM community, and globally. I need to believe that a sitting OSMF member and an employee of a sitting DWG member is not running roughshod over the desires of the community, functionally exploiting their position and connections. I am desperately looking for the angle here that places your actions solidly into the well-intentioned category instead of the many less positive descriptors it presently looks to be fitting in.

[For Changeset: 116027622 as well]
Could you provide the source for these changesets? I do not understand how you determined the values for Key:smoothness.
osm.wiki/Google The following two ways show cracks greater than 1.5cm making them "intermediate" or at most "good". They do not appear to be "excellent".
For ways: 458124851 and 932523728 you changed junction=circular to roundabout. 9 months ago, a local mapper [seen here Changeset: 103211874] explains why they changed those ways from "roundabout" to "circular". How did you remotely determine that mapper was incorrect?
For junction=circular, oneway=yes is implied. You can remove the redundant "oneway=yes" key and help fight tag bloat in the database.
junction=roundabout
I suspect there are more introduced errors in these two changesets. To be prudent and for the sake of the OSM's data accuracy, it might be safest to revert these (and any other similar) changesets and revisit them in a more cautious and conservative manner.