Open albertkun opened 4 months ago
@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:
Tried with multiple combinations of day_type
, time
, and num_results
.
@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
:
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!
@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?
@albertkun it's route_code
from the beginning, nothing is hardcoded, for now it's working after making changes, thanks
@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.
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?
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]
]
}]
}
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
andPoints
geometry withGeometryCollection
, 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 😅
@albertkun so far so good, 24hr shouldn't be an issue now. Two things to go over, third is trivial:
You mean no more additional times by this?
My suggestion for the time being is to ignore the additional stops
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.
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/
@anithegregorian great work and thank you for the feedback!
Here are my comments:
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.ok, @anithegregorian i got it down to 12.05 kB! let me know if that helps!!
@anithegregorian please use this thread to report any questions or issues with the endpoint