OK, thanks! I was just surprised by the bounding box. :-)

What's the source for this? It has a rather surprisingly large bounding box (covering both New England, USA and Austria), and these don't seem like features than can be added without local knowledge.

Thanks for adding these!

Thanks for adding all these details to the Botanic Gardens! I've updated a few of them, due to changes in the 13(!) years since. :-)

I am trying to decide how to tag paired oneway signs, as you did in this edit. I've opened a discussion of this here: osm.wiki/Talk:MUTCD/R#Handling_paired_oneway_signs_(R6-1R_and_R6-1L)

I'd love your thoughts.

Thanks. I kept thinking maybe I'd reuse this for something, but could never figure out what would actually be meaningful. Deleting it is likely better, so I'm glad you went ahead and did it.

Makes sense to me, thanks! Someone (you?) should document this on the osm.wiki/MBTA page, so people don't switch it back out of confusion.

I think Keolis is correct for operator= -- but I'm not sure of the right source for that.

Hm, the missing ones are route_master relations, and the problem is it's unclear that they have a concept that joins both directions of a route like that.

Excellent, I can use that to add a few missing ones.

Where did you find the C&J "schedule API data"? I'm having trouble finding it.

This is so great to have the various other bus companies routes cleaned up -- thanks!

I'm so glad you are working on untangling the mess of the Silver Line routes. One note -- I've been including both `'network:guid' = 'US-MA-MBTA'` AND `'gtfs:feed' = 'US-MA-MBTA'`, which makes PTNA use `gtfs:feed`. Probably `network:guid` is redundant, so feel free to leave that out, but for consistency, we should probably at least keep including `gtfs:feed`.

Thanks for working on this! There's more needed to bring this up to the full PTv2 standard (like adding the route, not just the stops, and adding a route_master), but this is an improvement.

Thanks for fixing all these access= keys on bus (and train) stations! I'd seen that problem, but hadn't gotten around to addressing it.

Ah, interesting! I'm not sure I know where the "route_long_name" value you are referring to is. And PTNA can pick up whatever ref= value is desired, we just need to update osm.wiki/MBTA/Analysis/MBTA-Routes to match.

Why did you change the ref= to Fairmount Line rather than leaving it matching the gtfs:ref=CR-Fairmount ? I'm open to using that naming, but I'm not sure what the value is in having that inconsistency (and I changed it to match per a suggestion from someone who works at the MBTA, on their GTFS data).

Ah, this is much improved. Nice work!

Thanks for your interest in working on fixing up the MBTA data in OSM -- but please don't make such a big change without discussing it first! We settled on using the short form for the network (and mostly for operator) -- please revert this unexpected and disruptive change until we have time to handle it (e.g. updating PTNA config ( https://ptna.openstreetmap.de/en/config.php?network=US-MA-MBTA ) among other things. You can discuss it here: https://community.openstreetmap.org/t/automated-edit-proposal-fix-mbta-stop-position-nodes/101680/5

Also, looking at street view imagery, the street_cabinet you created in the middle of the intersection at Fulton and Arden Way seems wrong. It appears to just be a painted square, not a cabinet. Could you correct that?