I threw a very rough first pass at some info on the page, let me know if anything else would be useful and as always feel free to make further edits :)

MA publishes a "Eligible Circuits by EDC" spreadsheet fairly regularly which contains the circuit numbers and their general area that they run. I then either hunt through the satellite imagery for the exact location or I look around for news articles about construction that may be happening at them.

Names can usually be confirmed by the signs posted outside of the substations, those usually require some boots on the ground unless there's acceptable imagery in the area. Same deal for addresses which are usually on the sign as well as the reference number which is usually there following the substation name.

Voltages are called out on the circuit list usually, but when they aren't you can look at the feeder IDs to get the voltages. National Grid generally follows a consistent "####A##" format where the first set of digits is the substation ID, the letter represents the voltage, and the second set of digits is the feeder number. Those can often be spotted on the electric poles outside substations or on equipment within the substation (harder to see usually).

Additionally, construction work at substations has to be filed with the state and those dockets sometimes contain information which is useful. That's mostly useful for figuring out what the specs are on the equipment within a substation.

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: 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]: relation/11921114
[3]: 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.