Comments (7)
This is definitely possible (and fairly easy) with the current system. In fact I've already implemented it.
Right now, there exists a map with a complex key of (Route, Trip, Station, StopTime)
. The keys are ordered lexicographically by each of the key parts successively. That is, all Stops on a Route are contiguous in memory, etc. Asking for all StopTimes in any timespan is just making two searches into the tree and iterating between them. In fact, visits_after
and visits_before
are just special cases of visits_between
where one of the bounding points is the first/last StopTime at a Station.
The question is: does this hierarchy make sense? Or should it be rearranged in a way that's more efficient for the queries that will be made? For example, having the Station
be the top-level key-part and the Route
be the last-level key-part would make queries for all arrivals at a Station (regardless of Route) much more efficient.
from timetable_cpp.
The two views in 1.0 that feed off of Timetable data will be station views, so inverting your map to have the top-level key be Station
would make sense to me.
Perhaps "the right thing" to do here is to have a map keyed by route-trip-station, and another by station-route-trip, and pick the more efficient for a given RPC call, but station-route-trip is the most useful to Proper for now.
from timetable_cpp.
And if you're cool with the visits_between
call I specified, that's perfect for me. I'll add it to the wiki and start using it in Proper.
from timetable_cpp.
I made two minor changes to the call I added to the wiki:
- Clarified that visits returned must have a departure time
t
such thatbegin_time
<=t
<end_time
. This is so that the client can get the next interval of visits by searching starting withend_time
. - Removed the limit
n
parameter. This makes doing interval-based "pagination" the way I specified above safer by guaranteeing that visits won't be missed.
from timetable_cpp.
All that makes sense to me.
Having two maps wouldn't be too bad, since each one can just store pointers (or rather, references). The only changes will be adding a new key class for the different order. Will try this out tonight.
from timetable_cpp.
Update on implementation: there's still only one map at this point, but it's key is (Station, StopTime, Route, Trip)
. This means that the default order of results for a query will be time-ordered, then route-ordered, and finally trip-ordered (though trip ordering is mostly negligible).
Update on performance: I'm currently working with Citybus' most recent archive, which has more than 250,000 StopTimes shared across 800 Stops and just under 9,000 Trips. The total memory usage with this single map is 213MB. My best guess at the implications of adding a second map will increase that memory usage to ~300MB. Processing time (parsing, interpolating stop times, and creating the map) before the system is available is ~4 seconds.
Overall, it's actually a lot better than I was anticipating based on the dataset, but could probably be improved farther with better usage of references and move-constructors, but that's a future concern.
from timetable_cpp.
This has been referenced in a few other issues as well (#3 in particular), but this RPC has both been added to the wiki and implemented in Timetable, so I'm going to close this issue as completed.
from timetable_cpp.
Related Issues (16)
- Iterate dates on `visits_*` calls
- Calls to visits_between don't honor the time range HOT 7
- Build on linux HOT 8
- RPC to get hours of service for a station/route HOT 5
- Improve `stop_time` indexing. HOT 1
- Date formatter bug in visits_after HOT 5
- Data versioning and idempotency HOT 2
- Optional csv fields HOT 1
- Rename `next/last_visits` to `visits_before/after`. HOT 1
- Handling agencies that don't have stop codes HOT 2
- Stop times > 23:59:59 unsearchable after midnight HOT 3
- Create visits RPCs for all routes at a station HOT 5
- Responses limited to 1024 characters
- Re-arrange RPC arguments to allow route agnosticism HOT 2
- Add route information to RPC responses HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from timetable_cpp.