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?

Yes, so I'm trying to understand why you added only 3 of the six such edges visible at Cottage Way and Fulton Avenue. :-)

This link doesn't seem to go to anything relevant anymore. I looked up this changeset because of your use of road_marking=solid_crossing_edge -- if you remember more about what you were intending with that, I'd be glad to hear about it.

Why did you mark a motorway_link (way/9038411 ) as bus=no in this changeset? According to the MBTA https://www.mbta.com/schedules/354/line?schedule_direction%5Bdirection_id%5D=0&schedule_direction%5Bvariant%5D=354-4-0 ) this is part of a bus route!

But, let me be clear -- I'm DELIGHTED to have other people working on MBTA bus routes! There's lots of work to do, and more hands are very welcome. If you are interested in doing more, I'd love to chat on the Discourse, or OSM US Slack, or just by email.

Please don't add ways to a route_master relation, as you did here. I'll fix it, but wanted to alert you. Thanks!