The eqasim framework features an integrated transport simulation environment. It is based on the agent-based transport simulation framework MATSim with added components for simulation of discrete choice models.
This PR adds the server package to eqasim. It can be started using the RunServer script and it provides an API to perform four different tasks, based on the MATSim network and the transit schedule of a scenario:
Road routing: Performs a shortest path routing on the road network
Transit routing: Performs a shortest path routing on the transit network
Both endpoints are designed such that they should yield the same results as agents would be routed in the simulation. However, certain settings can be overridden, such as the routing costs per transit mode for the SwissRailRaptor. The server then makes it possible to evaluate relatively quickly different parameters set-ups and thus calibrate the routing costs based on a travel survey.
Road isochrones: Given a starting location, provides all nodes (or a finer segmentation along the links) when are reachable with a maximum time threshold, also yielding the time to reach each point
Transit isochrones: Same as for the road network, but based on transit stops. Additionally, the maximum number of transfers can be configured.
All of this should have much more documentation to be useable. This will follow, for now the code has been heavily cleaned up and I publish it here so it stays up to date.
All endpoints optionally provide geometry information in WKT format as part of the API response. This makes it easy to directly visualize the results.
This PR adds the
serverpackage to eqasim. It can be started using theRunServerscript and it provides an API to perform four different tasks, based on the MATSim network and the transit schedule of a scenario:Both endpoints are designed such that they should yield the same results as agents would be routed in the simulation. However, certain settings can be overridden, such as the routing costs per transit mode for the SwissRailRaptor. The server then makes it possible to evaluate relatively quickly different parameters set-ups and thus calibrate the routing costs based on a travel survey.
All of this should have much more documentation to be useable. This will follow, for now the code has been heavily cleaned up and I publish it here so it stays up to date.
All endpoints optionally provide geometry information in WKT format as part of the API response. This makes it easy to directly visualize the results.