Thank you so much for reaching out! I'm always happy to help improve the state of public transit data on OSM.

I also have no strong opinions regarding whether the GTFS feed identifier should come before or after the relevant tag key. The reason for my choice of format is that it is what's <a href="osm.wiki/GTFS#Linking_to_a_GTFS_object" rel="nofollow noopener noreferrer" dir="auto">given in the GTFS wiki page</a>.

I understand that the wiki isn't a bible, but I figure anyone else searching for a reference on how to properly link GTFS data to OSM transit routes would do the same as me, and I'm wary of creating a competing standard.

Ah, please forgive me for over-explaining something you were already well acquainted with! Yes, the tag I used specifies the source for the route. So you're saying that other mappers only link GTFS data to stops with stop_id and stop_name? And they don't link anything to route or route_master relations? Because I have found routes in and around Seattle (King County Metro and Sound Transit networks) with the older style gtfs:feed=* and gtfs:route_id=*.

Ah, thank you for asking! This is covered in the GTFS page of the wiki, here:
osm.wiki/GTFS
Given your question, I don't know how much of this you're already familiar with, so I'll give as much information as I can.
Obviously, the "gtfs" portion of the key specifies that this refers to public transit GTFS data. The "shape_id" specifies that the value "shp-1-04" is the unique identifier for a shape file in the GTFS data corresponding to this specific variant of the route. And the final "US-WA-PT" is a unique code referring specifically to the GTFS data for the Pierce Transit network, found here
osm.wiki/List_of_GTFS_feeds#Washington
so that anyone who wants to link OSM and GTFS data for improved public transit routing knows where to obtain the data.
Please let me know if you have any other questions!

Ah, thank you for catching that. I'm not sure how I entered "bak=crossing", but I intended "barrier=kerb" instead. I have corrected this.

Ah, thank you so much for catching those! I rely on JOSM's auto complete, and I must have accidentally hit the shift key so that "d", which completes to "direction", became "D", which doesn't complete to anything. I'm not sure why the validator didn't catch the uncommon short keys when I uploaded, but I'm glad you were able to point out my errors so that I could correct them.

Ah, thank you so much for catching this! I had meant to enter "barrier=kerb" by relying on JOSM's autocomplete and simply typing "b [tab] k", but it seems to have autocompleted to the wrong value! I'll correct this immediately!

Looking at that location on https://www.geocoder.nyc/streetview.html, it looks like yes! As of August 8th of last year, there's nothing blocking the crosswalk, and the signals are functioning.

Actually, I'm only adding unmarked crosswalks where there are curb cutouts on opposite sides of the unmarked street, indicating that pedestrians are able to cross. If that is not the intent of the cutouts, then I can remove the crosswalks.

Ah, yes, I see! The light and shadow cast by the rail line above Broadway makes it difficult to tell at a glance on the street-level imagery, but zooming in closer I can see that many if not all of the crossings along Broadway are in fact concrete! It also seems like large portions of the roadway itself are concrete, but those are even more difficult to discern.

Ah, yes! Thank you for catching that mistake! I've just fixed it!

Ah! Thank you for catching that! There actually is no meaning, that's simply an error! I use JOSM's autocomplete a lot, and what I had meant was to type b (for "barrier"), tab, and k (for "kerb"), but I suppose I had made a typo previously and then JOSM later autocompleted the typo. I actually need to work out how to clear JOSM's autocomplete history for times like this, but in the mean time I'll correct this!

@MxxCon I don't know if I would say "a lot", at least in the area I've been mapping, but I should get in touch with the local NYC mapping community to make sure I follow best practices regarding existing sidewalk=* tags on roads.

@hdevine825 I've been using Kartaview and Mapillary since they're both easily usable from JOSM, but WOW! This is WAY better! Not only 360 photos, but based on the way the cursor "target" icon deforms around objects, I assume it uses some kind of photogrammetry processing? Thank you so much, this rules!

Hi, it's my pleasure really! It's honestly a bit shocking that there are so few sidewalks and crosswalks mapped in a city as big and pedestrianized as New York! If it benefits even one person trying to navigate their way through the streets, I'll be happy!

As for the tactile_paving tag, I believe that was either already on the node or I may have mistakenly copy-pasted it from another node! I don't live anywhere near NY and have to rely solely on aerial and street imagery, and so don't feel comfortable tagging surfaces beyond differentiating between concrete and asphalt.

I see! Perhaps then the example image on the wiki page should be updated, since it shows a large square crosswalk extending onto the sidewalk.
osm.wiki/w/images/thumb/5/50/Marked_crossing_example.png/512px-Marked_crossing_example.png

I see! This seems to have changed since the last time I checked the wiki! In the past, I had the understanding that crossing=marked was to be interpreted as describing only the road markings and giving no information about the signalling! In fact, I recall there being a proposal for unambiguous crossings making use of subkeys like crossing:signals. osm.wiki/Proposed_features/Unambiguous_crossings Though I see now that it's been abandoned! I'll correct my edits and keep this new practice in mind for the future!

Steven,

Thank you for the clarification! Though I should mention that the wastewater_plant wiki page seems to recommend using the landuse tag. Perhaps it should be amended?

Regards,
Itserpol

Thank you. I felt uneasy about that particular edit, and obviously in retrospect shouldn't have made it based solely on data from a website. I'll refrain from modifying existing NY address tags in the future without a physical survey.

Hi,
Actually, these tags are suggested here (osm.wiki/Proposed_features/crossing:signals#Upgrade_process_.2F_mechanical_edits) for replacing the existing subtag scheme. I may have used them a bit prematurely as it is only a proposed feature, but it seems more sensible since traffic_signals refers to signals controlling automotive traffic rather than crossing foot traffic. If this causes problems for existing tag interpretations I will change it, but would otherwise prefer to leave it as-is.

Shortly after uploading this changeset I found the following wiki article -
osm.wiki/United_States_roads_tagging/Routes#Florida

Preferring specific examples over generic ones, I added "Toll" back to the name and ref of FL 589 Toll route relation and associated ways. I also changed all relevant detailed destination tags to reflect this change.

I intend for my edits to conform to the best practices laid out in the following wiki articles:

key=destination - destination=*

Proposed features/Destination details - osm.wiki/Proposed_features/Destination_details

Tags should only follow after some identifiable signage and persist until a change in signage. Lane-dependent tags should also change or be left unset after a change in the number of lanes. However, there are a great many ways in this area and though I have thoroughly looked over my work I may have missed some errors.

I also removed directionals (i.e. north, south, east, west) from existing destination:ref tags and removed "Toll" from FL 589 ways and relation ref tags to coincide with the following:

osm.wiki/United_States_roads_tagging#State_Highways

The relevant ways are already tagged with toll=yes, and I added modifier=Toll to the FL 589 route relation.

As this is a large edit of a prominent highway junction complex, I searched for a Tampa area user group or mailing list before uploading this changeset, but was unable to find any. If you are part of such a group and believe that I've violated any local best practices, please let me know and I'll work with you to correct it.