You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've viewed a couple maps based on the train API endpoint, and most have made since visually, however there have been a couple that have looked off. Example for train 3520:
When I investigated it, the JSON returned has the 9th Street station with these lat/longs: { "nextstop": "9th St", "Minutes Late": "0", "lat": "39.74213", "lon": "-75.53286" },
If you view that lat/long in Google or Bing maps, it corresponds to the most Southwest marker from the screenshot, which is the location nearby an Amtrak station. There also seems to be a station placed near Malvern as well, giving the odd path line. So it seems a few of these trains may have an incorrect lat/long for one or more stations, while the station name and order is correct.
A similar result happened when I mapped out the 5317 train, although in this instance the Lansdale station had a lat/long for the furthest Southwest marker.
The text was updated successfully, but these errors were encountered:
So I queried all train data over the last 7 days for nextstop = 9th St and got some interesting results for lat/lon:
As you can see, one of those is waaaaay off.
As for the others, according to https://en.wikipedia.org/wiki/Decimal_degrees, every 100th of a degree is about 1.1132 km (0.69 miles). So it makes sense that when a train is 1 or more minutes away from a station (in either direction), that we'll be off by 2 100ths (or more) of a degree.
That said, what's up with Wilmington showing up? Until I (hopefully) get a contact at SEPTA, I could speculate that it's a default value returned when either the API or the underlying system can't get the location of a train.
So how do we deal with this? I think we'll see more issues like this in the data, as you map it out. So let's get a list of all of these edge cases and document them here on this bug. From there, we can figure out what to do with the data.
One approach comes to mind: If it's a single digit to low double digits of wrong points, we could create a lookup table of 1) next stop, 2) the lat-lon of that station, and 3) the maximum value in degrees which we will accept which deviates from that value. If the threshold is exceeded, we ignore that datapoint and substitute another of our choosing. I'm sure there are other approaches as well.
That does sound like it could be a default value being subbed when an accurate location can't be found, among other possibilities.
In the meantime I'll be going through the different trains while testing out the map, and will note any oddities. The couple I've noticed so far have only involved in Lansdale/Doylestown line but I need to run through more.
I've viewed a couple maps based on the train API endpoint, and most have made since visually, however there have been a couple that have looked off. Example for train 3520:
When I investigated it, the JSON returned has the 9th Street station with these lat/longs:
{ "nextstop": "9th St", "Minutes Late": "0", "lat": "39.74213", "lon": "-75.53286" },
If you view that lat/long in Google or Bing maps, it corresponds to the most Southwest marker from the screenshot, which is the location nearby an Amtrak station. There also seems to be a station placed near Malvern as well, giving the odd path line. So it seems a few of these trains may have an incorrect lat/long for one or more stations, while the station name and order is correct.
A similar result happened when I mapped out the 5317 train, although in this instance the Lansdale station had a lat/long for the furthest Southwest marker.
The text was updated successfully, but these errors were encountered: