I was just lacking any source data to support this because for many years peripheral roads did not get any street name signs. However, I have finally found some evidence like here: https://www.mapillary.com/app/?lat=40.947302581768&lng=-72.90196952632&z=17&focus=photo&mapStyle=OpenStreetMap&pKey=984944912157613&x=0.7928552283790877&y=0.5328145091126502&zoom=2 or
https://www.mapillary.com/app/?lat=40.943763987273&lng=-72.861849935993&z=17&focus=photo&mapStyle=OpenStreetMap&pKey=1685451221632248&x=0.7240181802281513&y=0.3927159762005113&zoom=1

Well, I guess than thank you for updating the names. Yet, one should be very careful when assuming and checking how far the naming goes.

We all make mistakes. However, because you have made so breaking many edits it would be too much of a burden to others to fix them. We usually expect these to be fixed by those responsible.

Also, regarding turn restrictions. I have seen that you have tried to add [relation 13683544](osm.org/relation/13683544/history) as a `no_u_turn` restriction at the Meadow Ponds gated community in order to prevent your app from routing a u-turn in a gated community. This goes back to mapping the situation on the ground, not what kind of behavior we want in any particular app. So, instead what you should have done was to map the ways in the gated community as `access=private` because this is the situation on the ground, not a u-turn restriction. Again, independent of the behavior of the app.

Please, DO NOT create loop ways in cul-de-sacs. Use `highway=turning_loop` instead if you want to be more specific about the type of the cul-de-sac.

You have also added `name` tags to ways that do not have a street name but only a route reference. See `name=Route 25`. Please revert these changes too.

Please revert your breaking `destination:*` tag changes of this changeset too.

In this changeset you have added `name` tags to roads that do not have a name (no street name sign) but only have a route reference, like the `NY 25A`. Again, there was nothing wrong with the OSM database. The issue you have is with your app. Contact your app’s developers and please revert your changes.

The same applies to this changeset. Please revert or fix according to guidelines your `destination` tag changes.

If the cul-de-sac has an “island” then please tag with `highway=turning_loop`.

The same applies here. Please revert you `destination` tag changes.

You have broken `destination:*` tag values. Please follow the guidelines laid out in the [OpenStreetMap Wiki](osm.wiki/Key:destination "Key:destination"). For example, you have garbled every type of destination information into one value. Furthermore, you have not payed attention to the syntax adopted by the community for specifying route references.
```
destination=CR-46;William Floyd Parkway SOUTH;To NY-25;I-495;NY-27;Brookhaven Lab;Shirley;Smith Point Park
```
Since you seem to have a problem with your navigation app, unfortunately you have taken the wrong course of action to mitigate your app’s problem.
Generally speaking, we do not map for a particular navigation app nor a particular map rendering of the OSM database. If you have an issue with your navigation app or a map rendering then please contact your app’s or map’s developers respectively. DO NOT *fix* the OSM database in order to get some desired behavior in your app or some desired map rendering. Thus, please revert your changes. Otherwise, I should be forced to refer this incident to the OSM database admins and ask them to revert your changesets.

Hamlets DO have admin centers in certain jurisdictions. DO NOT try to outsmart locals from your armchair. Be very careful when mapping admin structures in other countries, especially those you are not familiar with.

Please, DO NOT create no_u_turn restrictions with identical ways in from and to roles. This type of turn restriction relation DOES NOT add any value to the map. Please learn carefully and understand what turn restrictions are for in OSM before mapping these. Turn restriction relations in OSM map the FLOW OF TRAFFIC, not the legal situation on the road. What you are trying to map here is the legal situation on the road. If you want to map the legal situation on the road use the traffic_sign=US:R3-4 tag.

👍 Danke!

Kannst du bitte mal prüfen ob die Buslinie A614 nun weiterhin korrekt durch den Kreisverkehr in Eiserfeld verläuft? Es ist schwer aus dem allgemeinen Verlauf einzuschätzen wie der Kreisverkehr durchfahren wird. Danke!

Or, look at “SW Moody & Gibbs” (https://www.mapillary.com/map/im/9G0D4nrLEYzlb2yQM2_LAw) which is served by bus routes 35 and 36, and the Portland Streetcar NS line.

>> The phone is a public phone, not a private phone.
>
> Not sure why you think so because it's not. In fact, I didn't see a phone inside
> at all. It must be hidden somewhere behind the counter.
Perhaps it is.
>> The same applies to “7 days open” on the sign. As an observer you are allowed
> to make assumptions, regardless whether you are on site or sourcing data from
> imagery.
>
> Making reasonable assumptions, like "the phone number on the sign is probably
> correct" is fine, although you should even be wary of doing this in areas that
> you are not familiar with (anyone native to Oregon would know that a 7-digit
> number is not valid).
I am and I was aware that the phone number is probably not valid. Nevertheless, it is what the sign says. Besides, exceptions may still exist even after renumbering has been completed. As a mapper for OSM, my responsibility for verifying the validity of most data basically ends with reading what a sign says or what you can seen in an image. If I can verify data more thoroughly or to further ends then fine, I can map more accurately. So, it is what it is.

Assuming that “open 7 days" means 24/7 is a poor assumption.

That’s your opinion but I think it is still a reasonable assumption if you happen to know that most convenience stores in the US (and around the world) are open 24/7. Technically, if read through the eyes of a lawyer then sure, “open 7 days” does not necessarily include 24/7.

>> Bus stops are fully accessible when people on wheelchairs can get to the bus
>> stop without obstacles, that is just roll through. The same applies to boarding
>> and disembarking a bus. The bus stop does not seem to have been outfitted with a
>> ramp or any other device to enable wheelchair users to roll on board.
>
> Where did you get this idea from? The wiki says "Use this tag to mark a feature
> in the United States as compliant with the Americans with Disabilities Act
> (ADA)." To the best of my knowledge, the ADA doesn't require the stop to have a
> ramp to the bus.
Right, because ADA is not concerned with any particular pieces of infrastructure (at least not directly) but with organizations, businesses, and state authorities. So, you have to make a distinction between a transportation entity (or agency, network, etc), that is the bus fleet operator, who serves any particular bus stop and a bus stop as a physical piece of infrastructure. ADA does not require putting compliance stickers neither on bus stops (or buildings) nor on businesses or organizations. Simply put, an entity is ADA complaint as long as nobody complains or an oversight authority does not step in. But, this is not exactly how OSM works. OSM does put compliance stickers on physical objects in its database, by mapping with three different `wheelchair` values. Labeling with any particular value depends on the properties of the object. For example on buildings, `wheelchair=limited` usually means nothing more than that the entrance has a step which potentially can be overcome by most wheelchair users on their own. You can be more specific, map the entrance separately and tag it with `wheelchair=limited` and map the building with `wheelchair=yes` where building amenities might be accessible but not its entrance. On bus stops however, `wheelchair=limited` means that you can get to the bus stop but once you are there, you cannot expect to find a ramp or a raised curb there and you are at the mercy of the bus (and driver) to pick you up (or that there is some sort of obstacle to access the bus stop but otherwise getting on and off the bus is smooth). Basically, it means that you are gambling unless you are sure that the route is served by an accessible bus.

> People in wheelchairs can get to the bus stop because the curb
> is lowered on both sides. If there is no ramp, the bus is not wheelchair
> accessible, but the stop still is.

This is only half of the story to a bus stop. As you said yourself, the bus stop itself may be wheelchair accessible but the bus may not (or vice versa). And, as a wheelchair user when you look at a bus stop you are not only interested in getting to the bus stop but also in getting on and off the bus. This is why in OSM terms `wheelchair=*` is more about practical accessibility, not so much about a legal or technical standard. Again, OSM sources its data from observable reality like signs or missing ramps, not from legal standards.

> I've never even heard of having such a ramp at the bus stop rather than on the
> bus. I can't imagine any practical way to make that work, since the bus would
> have to stop in a very precise place for the ramp to extend inside. If you know
> of anywhere that this exists, I'd like to hear about it. It certainly doesn't
> exist in Portland.
Just because you have never heard, seen, or cannot imagine something does not mean that it does not exist. Generally speaking, this a bad premise to operate on.
Look at “South Lowell & Bond”: https://www.mapillary.com/map/im/QqYwsTwqdVVZd9IWiefGMw
Although this stop is primarily served by street cars (a `tram` in OSM terms), it is fitted with a raised curb. So, it can also be served by buses without a ramp. This stop has a modern raised curb but there are also older style raised curbs in Portland, like at “West Burnside & Burnside Bridge”.
See here: https://www.mapillary.com/map/im/E0iJuaxW1-NCTh-1-Eyl_w
There are many more similar examples in Portland (and around the world).

> First, private phones inside of buildings should not be mapped, and certainly not with a node randomly dropped inside of the building.

I did not add the phone, so I did not drop it randomly. All I did was augment it with additional tags. The phone is a public phone, not a private phone. OpenStreetMap accepts and appreciates indoor mapping.

Since OpenStreetMap generally operates on the “posted” or “signed” rule of thumb and the market did not have a `phone` tag it was safe to assume that the phone number as it appears on the sign is the market’s phone number, regardless of any fact that it may or may not be in use anymore. It is completely admissible to collect data to the best of your knowledge. Should anybody survey the area and collect any updated data then they are free to update the market’s phone number, including a `note` that the market’s sign is misleading or outdated.
The same applies to “7 days open” on the sign. As an observer you are allowed to make assumptions, regardless whether you are on site or sourcing data from imagery. What OpenStreetMap just “expects” of you to do in terms of quality of data, is to collect data to the best of your knowledge and ability, and to annotate the source of your data.

> Please don't map based on assumptions.
I will most certainly continue doing that because this has been OpenStreetMap’s mode of operation ever since. OpenStreetMap is not a court of law where facts have to be proven beyond reasonable doubt. OpenStreetMap collects DATA based on an observer’s best effort interpretation of artifacts (like signs) and natural phenomena, while data sources are cited to be able to verify (not prove) an interpretation later. Moreover, OpenSteetMap is a consensus driven project where certain habits and rules of best practice have crystallized. And so far, I fail to see where I might have deviated from the consensus or rules of best practice.

Bus stops are fully accessible when people on wheelchairs can get to the bus stop without obstacles, that is just roll through. The same applies to boarding and disembarking a bus. The bus stop does not seem to have been outfitted with a ramp or any other device to enable wheelchair users to roll on board. Whether a bus stop is exclusively served by bus vehicles which may or may not be boarded by “just rolling on board” is a property of the bus, or a fleet of buses, not the bus stop.

> A bus stop is the area around a sign on the sidewalk.
Well, according to the new public transit mapping scheme “the area around a sign” is actually a `platform`. In the legacy scheme the boundary of a bus stop is rather blurred and not clearly defined. In most cases this includes the sign (if any), the platform, any shelter, bench, ticket vending machine etc. So, you could also map all these things separately and interpret the bus stop sign (or the platform) as `highway=bus_stop` only. There is nothing wrong with adding `shelter` or `covered` tags in the legacy scheme. `shelter` and `covered` are here often used and interpreted interchangeably (or synonymously).

If you have surveyed the area recently then you may update the OpenStreetMap database anytime you want.

To be more specific, I have added the Mapillary image keys.

@SomeoneElse Please excuse the fact that this conversation has gone off topic. However, I do not know of any more adequate place. If you know a better place to continue the conversation about this topic then please share a link or reference of some kind. Thank you.

> content (collectively, 'Contents') to the geo-database of the OpenStreetMap project (the 'Project')

Please note that granting copyright applies explicitly only to “the geo-database of the OpenStreetMap project”. Thus, please explain what covers changeset comments.