Isochrone Plugin #2189 #2477
Isochrone Plugin #2189 #2477
Conversation
…nto develop Conflicts: features/bicycle/range.feature include/engine/api/isochrone_api.hpp include/engine/api/isochrone_parameters.hpp include/engine/plugins/isochrone.hpp src/engine/engine.cpp src/engine/plugins/isochrone.cpp
…s multiple definition error
|
I have a possible strategy that does not require loading the edge-based-graph into memory at all - while we can't explore the CH directly, we can re-create the parts of the edge-based-graph we need on-the-fly. The recent work I did on the debug tile plugin to add turn penalty data involved the re-derivation of the edge-based graph within the tile being queried. This is possible by fetching all data in a geographic area, then re-connecting the dots. See this code. The rough idea would be to come up with a reasonable "search tile" size (my gut says 5km x 5km would be good starting point). The rough algorithm would be:
Performance would be dictated by (a) the cost of the bbox RTree search to fetch tile data, and (b) the cost of re-constructing the local edge-based-graph from that tile. For the example ranges above by @roroettg , I suspect we could fetch all data in a single "tile". |
|
Ok, I just had a go at this to see what kind of performance we'd get. It was relatively easy to copy the logic from the tile plugin to create the edge-based-graph we need. 100 second radius A 400-second isochrone on the car profile is rendered in about 200ms, including the generation of 1.2MB of GeoJSON. Its not doing the tile loading, but it's loading a 0.2 degree x 0.2 degree box (about 10km x 10km in Münster). @roroettg For your use-case, how large were you planning on allowing the isochrones? If I push my code up, do you think you could adapt your concave hull to it? |
|
@danpat just in case, we need 30 minute car isochrones with RPS of 50k. It looks like to achieve that some caching is needed. |
|
@Komzpa RPS == Requests Per Second, or https://xkcd.com/645/ ? |
|
@Komzpa ^^ this is a 30 minute driving isochrone centered on the same point as the above examples. On my laptop (with an i7 CPU), it takes about 6.3 seconds, broken down into:
This approach is basically the worst case for isochrone generation - it employs no speedups at all. I'm of the opinion that even a limited isochrone feature would be good to have - the demo server can easily restrict the allowed isochrone size to something that won't eat up all our CPU, and folks that want to do bigger ones can set up their own servers. Additional memory use is 🙅 for the demo server, but I think limited isochrone sizes would be just fine. |
|
@danpat Nice Work. For our use-case isochrones with the size of up to two hours for a bicycle profile would be perfect. With my current approach the memory is most of the time the limit when the isochrones get too big. On a different branch I separated the isochrone-service from the current routed-service to avoid having two graphs at runtime. @danpat Yes, probably i can adapt my code. |
|
Yeah, the memory problem....I think we just need to make the limit configurable at runtime - if the average travel speed is slow, then 2 hrs may not actually be all that big of a maximum radius. I'll push my changes up to a separate branch here and you can take a look. |
|
Pushed to here: https://github.com/Project-OSRM/osrm-backend/tree/ch_isochrone_poc This doesn't implement the tiled approach, it simply fetches a bounding box of data using a maximum-possible-radius calculation (200km/h for cars). The nice thing about this is that it scales down quite well - small isochrones are quite fast. My code is simply returning the geometry of all edges inside the isochrone boundary - there's no data on points for age, and the data is not tree-like in anyway. That said, these geometry adaptations should be relatively straight forward. It could also probably get quite a bit faster with some work on cache locality. I spent a bit of time over the weekend reading up on one-to-many speedup approaches - I think there are some options for future work. For now, I'd just like to get a workable plugin in, and get folks using it, then we can get feedback on what needs to work better. One thing I'd be very interested in knowing: do folks care for exact isochrone trees, or are approximate bounding polygons more useful? |
|
@danpat |
|
Happy New year, is this still blocked by merge issues? is it even a priority to keep working on? |
|
@DrewRay as far as I know this isn't a priority for anyone, thus the lack of progress. If you've got time and are willing to work on it, please feel free :-) For my branch a couple of comments back, the thing I got stalled on was making a reasonably compact JSON-like serialization of the isochrone tree data. GeoJSON doesn't really work for this. |
On my side, each time I need isochrones it is for the hull, never for the tree. |
|
It would be nice to have the maxspeed as parameter. |
|
Agreed, I can use a hull to overlay and get the network again.
…On Mon, Jan 23, 2017, 4:49 AM Frédéric Rodrigo ***@***.***> wrote:
One thing I'd be very interested in knowing: do folks care for exact
isochrone trees, or are approximate bounding polygons more useful?
On my side, each time I need isochrones it is for the hull, never for the
tree.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2477 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AO99u0ibNDGjtI7JZd2ZjR3Udoi9TnS7ks5rVIXRgaJpZM4IomDA>
.
|
|
I test this branch and got two issues:
|
| public: | ||
| explicit IsochronePlugin(const std::string base); | ||
|
|
||
| Status HandleRequest(const std::shared_ptr<datafacade::BaseDataFacade> facade, |
There was a problem hiding this comment.
This can't compile datafacade::BaseDataFacade need to be const.
|
The
|
|
Is this proposal deprecated (to-be-closed) as superseded by #3652 or both are being developed as alternative approaches? |
|
Super-seeded by #3652 |
I hope I am doing this right.
As requested in #2189 this pullrequest contains the isochrone plugin I am working on.