update the schedules page to use the `route_details` endpoint

[albertkun]

@anithegregorian please use this thread to report any questions or issues with the endpoint

[anithegregorian]

@albertkun I got the updates, thanks, and presuming the variations are directions?

6010003_DEC23 (for eg. Northbound)
6010001_DEC23 (then this would be Southbound)

Started refactoring and hit a bump, the new API endpoint is returning responses for only bus routes, and all the rail routes are returning Internal Server Error, is this endpoint stable to begin with:

https://api.metro.net/LACMTA_Rail/route_details/801?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

https://api.metro.net/LACMTA_Rail/route_details/802?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

https://api.metro.net/LACMTA_Rail/route_details/803?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

Tried with multiple combinations of day_type, time, and num_results.

[albertkun]

@anithegregorian thank you for the heads up!

| I got the updates, thanks, and presuming the variations are directions?
Actually the variations are deviations within the same direction. direction_id is still used to indicate direction!

regarding the second question, sorry, i forgot to mention that the problem is that the operators are no longer using 801 and such for the route_code, instead they are using Metro A-Line, Metro B-Line, etc. as the route_code:

https://api.metro.net/LACMTA_Rail/route_details/Metro%20A-Line?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

https://api.metro.net/LACMTA_Rail/route_details/Metro%20B-Line?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

https://api.metro.net/LACMTA_Rail/route_details/Metro%20C-Line?direction_id=0&day_type=Weekday&time=10%3A00%3A00&num_results=3

this should coincide with the route_overview table's route_code. in case you were hard coding it, here are the updated lines:

route_overview table

route_code	line_id
Metro A-Line	801
Metro B-Line	802
Metro C-Line	803
Metro D-Line	805
Metro E-Line	804
Metro K-Line	807

trust me, i did not want this change (it caused me a lot of headache), but i was told to use it. :(

feel free to ask if you have any other questions!

[albertkun]

@anithegregorian just to confirm, are you using the route_code in the route_overview table to populate this? that way route_code you dont have to update anything in the future?

[anithegregorian]

@albertkun it's route_code from the beginning, nothing is hardcoded, for now it's working after making changes, thanks

[anithegregorian]

@albertkun @matikin9

After refactoring and removing most of the cleanup code in JS: https://lametro.wpengine.com/riding/schedules/

You should be able to see a list of stops and a map of the entire route, it's missing point geometry for stops (markers).

Once I clean the code, and fix some bugs(map zoom and center, search etc.) and functionality, should be ready.

What about additional times? Do we need them?

Most importantly, the time query string is built from user's browser locale settings or systems locale settings.

[albertkun]

Gotcha! @anithegregorian One issue related to the time string built from user's browser locale settings or systems locale settings is that it is from 12hr format, so I am checking this at 4:28pm, but instead i am getting the time as 4:28am! Ideally, we should be able to add 12 when it is after 12pm! What do you think?

[anithegregorian]

I had a feeling it was not the right thing to do, shall make corrections for 24 hrs time stamp, but hope that's what it should be based on (a users locale settings).

What about additional times and the missing geometry for markers (points)? I was looping through the stops previously which returned a geometry with points to build them on the JS front-end.

Another way, that I can think of is to split the LineString and Points geometry with GeometryCollection, if it's possible, as an example below:

 {
   "TYPE": "GeometryCollection",
   "geometries": [{
     "TYPE": "Point",
     "coordinates": [100.0, 0.0]
   }, {
     "TYPE": "LineString",
     "coordinates": [
       [101.0, 0.0],
       [102.0, 1.0]
     ]
   }]
 }

[albertkun]

I had a feeling it was not the right thing to do, shall make corrections for 24 hrs time stamp, but hope that's what it should be based on (a users locale settings).

What about additional times and the missing geometry for markers (points)? I was looping through the stops previously which returned a geometry with points to build them on the JS front-end.

Another way, that I can think of is to split the LineString and Points geometry with GeometryCollection, if it's possible, as an example below:

 {
   "TYPE": "GeometryCollection",
   "geometries": [{
     "TYPE": "Point",
     "coordinates": [100.0, 0.0]
   }, {
     "TYPE": "LineString",
     "coordinates": [
       [101.0, 0.0],
       [102.0, 1.0]
     ]
   }]
 }

Maybe simple solution is to retrieve the GMT time for Los Angeles and use that time? Since at the moment the current schedules page is only useful for the current time in Los Angeles! Do you think that is possible?

Regarding the additional geometry and markers, I'm not 100% sure what we should do as that is more of a design decision, we will have to bring it up with the team! But you might be on the track using a Geometry collection. My suggestion for the time being is to ignore the additional stops, AHAHA 😅

[anithegregorian]

@albertkun so far so good, 24hr shouldn't be an issue now. Two things to go over, third is trivial:

1. You mean no more additional times by this?

My suggestion for the time being is to ignore the additional stops

2. The size of geometry, even for Metro K-Line (assuming it's the shortest route), there are 1.33k line string coordinates, approx API payload size of 3.99MB, and the tab process (in FF) around 266MB. Calling route_details API feels like a resource-heavy operation, esp. for longer and more complex geometries. If there is any chance of reducing it with algorithms (like quantize or simplify in TopoJSON), would make the whole experience a lot faster. Under negligible circumstances, I wouldn't draw your attention (sure there's plenty), as the entire experience is dependent on this API.

3. Markers and stops can wait until a design decision is made

That's it, rest is up and running on stage: https://lametro.wpengine.com/riding/schedules/

[albertkun]

@anithegregorian great work and thank you for the feedback!

Here are my comments:

1. I think this might be a design decision as well, because if there are additional stops in a later trip, I'm not sure what the best way to handle that is. You could probably use a JavaScript reduce function to collapse/merge the stops based on stop_names, but the problem is the order of completely different stops when encountering something like an owl service on the 610.
2. I agree with you that simplifying the payload for the geometry would be a great idea! So I'll go ahead and see what I can do to reduce that file size.
3. Agree about the markers and stops!

[albertkun]

ok, @anithegregorian i got it down to 12.05 kB! let me know if that helps!!