I did the survey earlier today, indeed that way does not exist, so it's been removed in the following changeset: changeset/149243472

IraGersh, afaik there is no way to discriminate between traces as OSM doesn't have a way to filter or determine what traces belong to bicycle and pedestrian vs all others, and then those traces (like mine for example) may also go between bicycle and pedestrian and car at any "random" given moment, so it also wouldn't particularly be very easy to either. Mostly, you would be creating and uploading your own GPS/GPX traces for use while mapping, and/or viewing specific traces from others' uploads, it seemingly isn't really meant to be used in any other ways as far as OSM goes.

Hey Brandon, I've taken a look at it, the changeset looks alright with the exception of the way that you've mentioned, I'll go survey tomorrow if I remember and get there before it rains, otherwise sometime later on this week or early next; I've made the following changeset for the time being for it - changeset/149201453

Hey IraGersh, without going into edit mode using a specific GPS/GPX trace uploaded to OSM, you can select the "Public GPS Traces" option which can be found under (Map) Layers, and it should show up alongside others.

Take a look at the GPS/GPX traces associated with my account, which were used to draw these paths. Alternatively, visit and survey to see for yourself; everyone knows that there's active construction/changes here since summer 2023. There is even a highway ramp in the area created by another user associated with Lyft that is also not visible at all on satellite imagery, the one ramp that doesn't look like the other three.

Yeah, I'll adjust it in a few hours if it isn't already adjusted by then, originally I didn't notice that the width shrinks, especially with the number of lanes remaining the same and just overall being in a rush.

No, you and I both measured in the same way, just measured different parts/areas that apparently have a different width (I measured the West-most part over by Westchester Avenue's intersection with Middletown Road) - https://imgur.com/Y4GSRY4

Yeah, I read and understood that it was in meters, and used iD's measurement tool (several times, drawing a line from one curb to the next and deleting/cancelling that line, and then averaging/rounding the collected measurements); on average it was between 51-52 ft, and since the width is stored in meters I rounded the converted value to 16 (up from 15.5+).

I've removed a tag (highway=tertiary) and keeping this area unattached for now (changeset/128699681), do you know of a way to perform measurements in iD?

Yeah, the navigation/routing issues typically have to do with the proximity of ways to destinations, some of which are generally fixed with appropriate tagging to correct that (such as a private access tag for a driveway that goes behind a destination), but there are more general ones where a destination is on a corner where two roads intersect for example, or more complex but similar scenarios where a road is deferred for one or more reasons so it navigates/routes around and avoids (and sometimes acts kinda silly for) those deferred roads; routers typically don't actually associate an address with a street based upon their addr:street tags (because like you said some addresses are (having their entrances) on the "wrong" street rather than the street of their address), they basically just find a way to get there to the destination based upon their configuration/engine, and the relations can/may help by pretty much more explicitly associating an address with a street and implying that this is the definitive way of getting to said destination as expected, not anything else nearby (unless also associated).

For the most part I won't bother with adding associatedStreet relations directly specifically for areas or streets that have sidewalks mapped out independently, unless I have more of a reason to do so (like for navigation/routing), so I won't just be going around and adding a bunch of those relations around unless I either have to or it makes sense for me to, since besides those occasional hiccups from time to time, everything works perfectly fine exactly as they are and have been.

Yeah it doesn't really add anything special or valuable that wasn't already known, though according to the wiki could help navigation/routing (though there were no such problems on this road), I am primarily planning on doing this for more complex areas with navigation/routing issues or areas that have sidewalks mapped (to associate those with the street rather than name them "Street Name Sidewalk" like before.

Got it, thanks; I primarily only tagged this changeset comment with "Testing/Experimenting" to attract some attention because this is the very first time that I have ever done anything with relations, besides accidentally breaking a few in the past (and then fixing them), and wanted to be sure that everything was alright here with this one (no issues/mistakes or better/recommended methods). As far as I can tell at this point though, I did understand the wiki (for associatedStreet relations) correctly and did everything correctly here, so I can now comfortably work on these relations in other areas where it makes sense (like you suggested to me awhile back), knowing that I won't mess up or break anything.

Got it, will revise now (and then eventually remove once it's been removed), and likely won't map any others that I come across. changeset/117531053

They are 3 "outdoor dining" areas that various restaurants have been putting up, I didn't see the correct feature type or tags for that, but I'll add/mention that as a note shortly, unless I can find the right tags for it

Alright, noted; I'll defer making such edits for now but maybe refine some of the already made edits to also utilize the tags mentioned in the links, although there is a section in the first link stating "this method provides for nicely narrated directions from routing programs" which was actually the exact thought that had me begin adding name tags to various foot paths for pedestrian routing and whatnot in the first place.

Reverted in changeset/114776802, will move unofficial addresses to individual address tag if necessary.

I'll revert some time after the next hour mark if no further comments are made, but if anything please just move the unofficial addresses to an independent address tag instead is the only request that I have, since these places do put their street addresses as being "Westchester Square" (as do many others in this area) rather than "Lane Avenue" or their actual physical street addresses, and proprietary source Google Maps allows you to find these locations as the same place regardless of which address you put in, which is the goal here (and the previous changes before this one also allowed that same result really well).

See Uber Eats example (screenshot of application with address for Chipotle, "35 Westchester Square" and not "35 Lane Avenue" despite the road being "Lane Avenue" and the road "Westchester Square" not existing anywhere (afaik)) - https://i.imgur.com/0NxV7lC.png

Tag "layer=-1" gets added automatically by iD, but to explain, the cycle/foot paths are on ground/street level, however is under/within a structure. The entire structure is closed, and in many places within are tunnel-like. The other (untouched adjacent) ways are one level up above, on a bridge structure.

Proprietary source Google Maps lists all addresses (with the exception of East Tremont Avenue, which it locates as being nearby in the area) as being the same building; online, many if not all of the addresses in this area (called "Westchester Square") use "Westchester Square" as their street name rather than the name of the street that they are actually physically on, and this statement can be verified by looking around and doing your own research, taking a look at the Uber Eats app for example which would be a prime example of this. Adding on, many navigation and/or mapping applications simply display the last street tag (after the last semicolon) as the display name, so for a person who doesn't know that this area likes to put "Westchester Square" instead of "Lane Avenue" for example, having these additional tags present (such as "Lane Avenue / Westchester Square" as the last street tag) helps that person to still be able to find that location without causing any harm whatsoever, and allows them to not have to depend on any proprietary source to find a location; I thought this was what OSM was all about. If need be, I can add a separate address tag containing the additional street names since that was fine with you the last time I did that (this time all I did was merge that additional address tag with the building and rearranged the street tag order).

Correction - 3550 Conner Street, McDonald's

Side note/addition, the Lafayette Avenue roads are somewhat steep, with me estimating maybe like 20% or 20 degrees of an incline from Brush Avenue to Hutchinson River Parkway Service Road, and that is why the Brush Avenue side is not connected, as that goes into to the first level rather than the second/roof. There are also escalators and I believe also an elevator within the small portion of Target on the upper/roof level, and on the outside there are for sure stairs.