Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strange lat/longs #21

Open
jwzabrenski opened this issue Apr 11, 2016 · 2 comments
Open

strange lat/longs #21

jwzabrenski opened this issue Apr 11, 2016 · 2 comments
Labels

Comments

@jwzabrenski
Copy link

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:
train_3520_path
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.

@dmuth dmuth added the bug label Apr 11, 2016
@dmuth
Copy link
Owner

dmuth commented Apr 11, 2016

So I queried all train data over the last 7 days for nextstop = 9th St and got some interesting results for lat/lon:

image

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.

@jwzabrenski
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants