Yes I am local to MA.

AFAIK this was discussed briefly on the OSM US Slack. I unfortunately don't have a link to the discussion (can't access Slack currently).

That most likely should have been highway=platform given that this is a bus platform.

Sounds good, thank you! I'll definitely keep an eye out for it in future edits.

Here is the changeset for adding the foot paths within the concourse: osm.org/changeset/144032180#map=19/42.36610/-71.06205

I double checked to make sure that all of the entrances to the concourse are connected and that there is a clear path between the Green and Orange line.

Hi and thank you for the heads up! I understand how annoying the impact of this must have been - I'll admit I use the MBTA daily but didn't realize they used OpenTripPlanner internally - so I definitely want to get it resolved.

I'm going to take a shot at getting the platform doors and other doors of the concourse connected by footpath ways. This is the pattern used at other stations around the world to handle routing and also the pattern used to connect our very own Boston Logan Airport.

The changeset should be up shortly. Let me know if that doesn't end up resolving the OpenTripPlanner issues.

You're technically correct in that Keolis Commuter Services is the operator of the train (and all MBTA CR routes [1]), under contract from the MBTA. The MBTA owns (most of) the trackage, all of the equipment, handles fares, and owns (most of) the stations.

This is different from cases like the Hartford Line [2], which is operated by both CTrail (under contract) and Amtrak with their own personnel and equipment. Or the Metra Union Pacific North Line [3], where the equipment is owned by Metra but everything else (including dispatching, tracks, etc.) is owned and operated by Union Pacific.

I'd argue that the MBTA CR routes operate closer to the Metra UP lines in spirit.

[1]: https://en.wikipedia.org/wiki/MBTA_Commuter_Rail
[2]: osm.org/relation/11921114
[3]: osm.org/relation/3117572

Unfortunately they don't have a concept of that. Their routes references are a combination of the major stop references that the route hits (`PM` + `SS` = `PMSS`, or `PM` + `SS` + `LG` = `PMSSLG` for the last route of the night). They don't have overall routes that combine directions.

I considered the destination code originally for the route master refs (so `SS`, `LG`, and `NY`) but that would result in the route masters having a different ref than the individual routes. And then it's not clear where the triples would go, since it doesn't really align with how C&J does it.

Oh yeah, because it's not well-advertised because it's used primarily for ticketing.

https://webstore.ridecj.com/ticketing/dyn/schedules.asp?ds=4666&as=1656&dd=09/20/2023

GET request (can be opened in the browser) with a JSON response.

`ds`: Departure station
`as`: Arrival station
`dd`: Departure date (mm/dd/yyyy)

Station codes are as follows:

* `4666`: Andover, MA
* `955`: Dover, NH
* `951`: Logan Airport (Boston, MA)
* `1656`: NYC, NY
* `949`: Portsmouth, NH
* `4665`: Seabrook, NH
* `950`: South Station (Boston, MA)

They do not publish a GTFS feed anymore (they used to, but are "upgrading their real-time bus tracking system") so I'm not convinced any of this will line up with a future GTFS feed, but it definitely matches their internal references.

Good catch! I added the `gtfs:feed` tag the routes that I've recently added (if I missed any I'll correct them tomorrow after the refresh).

Slowly but surely, we'll get there. I wanted to make this change first so that I wouldn't forget that these already exist (in addition to the single other 71 route). I'm planning on adding the rest of the info shortly.

For future context, I had originally made this change because the sample trips associated with the commuter rail uses the `route_long_name` as the reference instead of the `route_id` that we would normally expect. That appears to be definitely wrong so I've reverted it in another changeset.

I'm actually about to revert it after noticing that PTNA didn't pick it up.