Trips section : on selecting a trip, load a map preview. Show stops, and load the shape too if present.
Frontend
build a map div below the trips table.
like in sequence section, have a stops layer and a shape layer.
explore if its better to load the full keyed stops data like in sequence section or if its better to load lat-long per stop.
tabulator will fire a GET request on user selecting a trip. The map should be cleared then itself before waiting for callback, to avoid making user think previously loaded trip's map is there for this one too.
on receiving callback, trigger map potransit visualpulation function.
make stops markers, put timings in popup/label.
explore if a different kind of divIcon should be made to give stop_id and timing in the marker itself.
see the existing gtfs visualizer tools to see what they do.
Backend
trip_id and shape_id (if any) will be received.
from stop_times, load the entries for this trip.
from stops, left-merge lat-longs and stop_name.
from shapes, load entries for the shape_id if any.
send combined data as callback.
Timings reckoner
HEY, if timings are being loaded up anyways, and on the db side if things are being optimized (hush!), why bother making use load timings again in timings tab? Just populate it with what we get here only! (removing the left-merge parts.. hmm..
For something conceptually simple ('oh lets show the trip on a map also'), thinking it through, realizing practically how much work it can take!
Still, if we want to facilitate complex trips with varying sequences and shapes then this is a bridge we'll have to cross.
Trips section : on selecting a trip, load a map preview. Show stops, and load the shape too if present.
Frontend
Backend
Timings reckoner
For something conceptually simple ('oh lets show the trip on a map also'), thinking it through, realizing practically how much work it can take!
Still, if we want to facilitate complex trips with varying sequences and shapes then this is a bridge we'll have to cross.