Re: [OpenTripPlanner] Updating weights of the graph based on real-time (or predicted) traffic information

[Matt Conway]

To a first approximation, that is correct.

However, it does bring up a broader issue that I've been meaning to mention, and that is that car routing with variable speed breaks the constant on-street speed assumption used in the A* heuristic. That heuristic is intended to be optimistic, but with car routing, if the router found a 120 km/h way, it could potentially get "ahead" of the heuristic. This is an issue now, and would not be made any worse by your suggestion (that is, I accept full responsibility for it), but I thought I should mention it since it's in the same code.

Matt

On May 22, 2013 12:53 PM, "Jens Mittag" <jens....@gmail.com> wrote:

Dear all,

in one of my research projects we want to use dynamic (or adjustable) weights when searching through the graph. For instance, when a user travels by car, we want to use travel time values as reported through real-time traffic information by our local traffic authority. And in the future, we would like to use estimated travel times in our search.

From how I understand the OTP code, the RoutingContext::getSpeed(TraverseMode mode) is only used in PlainStreetEdge::doTraverse(State s0, RoutingRequest options, TraverseMode traverseMode), so it would be sufficient to do this call against an own "traffic status service" which provides a speed value that results in the current / or estimated travel time for the given edge... anything else should be transparent to OTP, is that correct?

Thanks for your help
 Jens

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Byrd]

This is not a show-stopper, though, just something that needs to be
taken into account. We already need to track per-mode maximum speeds:
https://github.com/openplans/OpenTripPlanner/issues/1068

So you'd just want to keep the max car speed entry in that table updated
as new data came in.

In response to the original question, yes -- if you apply speeds on an
edge-by-edge basis the routing should work fine.

-Andrew

On 05/23/2013 04:21 PM, Matt Conway wrote:
> To a first approximation, that is correct.
>
> However, it does bring up a broader issue that I've been meaning to
> mention, and that is that car routing with variable speed breaks the
> constant on-street speed assumption used in the A* heuristic. That
> heuristic is intended to be optimistic, but with car routing, if the
> router found a 120 km/h way, it could potentially get "ahead" of the
> heuristic. This is an issue now, and would not be made any worse by your
> suggestion (that is, I accept full responsibility for it), but I thought
> I should mention it since it's in the same code.
>
> Matt
>
> On May 22, 2013 12:53 PM, "Jens Mittag" <jens....@gmail.com

> <mailto:jens....@gmail.com>> wrote:
>
> Dear all,
>
> in one of my research projects we want to use dynamic (or
> adjustable) weights when searching through the graph. For instance,
> when a user travels by car, we want to use travel time values as
> reported through real-time traffic information by our local traffic
> authority. And in the future, we would like to use estimated travel
> times in our search.
>
> From how I understand the OTP code, the
> RoutingContext::getSpeed(TraverseMode mode) is only used in
> PlainStreetEdge::doTraverse(State s0, RoutingRequest options,
> TraverseMode traverseMode), so it would be sufficient to do this
> call against an own "traffic status service" which provides a speed
> value that results in the current / or estimated travel time for the
> given edge... anything else should be transparent to OTP, is that
> correct?
>
> Thanks for your help
> Jens
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenTripPlanner Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to opentripplanner...@googlegroups.com

> <mailto:opentripplanner-dev%2Bunsu...@googlegroups.com>.

[Jens Mittag]

Hi Matt,

thank you for your fast reply and clarification. I did not think about that. So what you say (to make things right), is that one needs to adapt the heuristic to these dynamics (i.e. different speeds on different streets) as well. I will have to look into the heuristic code how to do that... but in theory I don't think this should be a problem.

cheers

 Jens

[Mohamed T. AlRefaie]

Dear all:

Is injecting real-time road speed supported now on OTP to enhance the performance for finding a driving route? Following up on Jens's post made more than a year ago, what is the current status of this on 0.11.x or in later versions? 

@Jens have you committed your solution to the repo or is it publicly available?

Thanks a lot for your help,

Mohamed.

To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-dev+unsub...@googlegroups.com.

[Jorden Verwer]

Hello Mohamed,

There is no support for real-time car routing in 0.11.x. I don't know what Jens did, but I independently wrote an implementation of real-time car routing for The Netherlands that is highly specific to our data supplier, so it wouldn't be of much use to you (not to mention that it would take significant work to merge it into 0.11.x or master, work that wouldn't pay off for my employer at this time). I'm not sure what you mean by "enhance the performance", though. If you mean "get more accurate results", then yes, that's what this is supposed to do. If you mean "get results faster", you're probably looking for the wrong thing.

Regards,

Jorden

Op zondag 9 november 2014 22:29:32 UTC+1 schreef Mohamed T. AlRefaie:

[Mohamed Taher AlRefaie]

Hi Jorden:

Thank you for your reply. Yes, probably I should have said to 'enhance the quality of calculated journey' instead of 'enhance the performance' (Too generic). :)

Great to know that you have addressed this issue before. And about sharing your code, I totally understand this.

I would be really grateful if you give me a pseudo instructions on how to implement this. This will help me a lot to shorten the time spent in diving through the code of 0.11.x. You used this version, right? Also, if you have any pro tips to do this right, please share with us.

Once I get your instructions, I will have a deep look into the code, create a draft design and share/discuss it with all developers here so this could be adopted in the new version of OTP hopefully. Your contribution would be definitely rewarded.

Thanks,

Mohamed Taher Alrefaie.

--
You received this message because you are subscribed to a topic in the Google Groups "OpenTripPlanner Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opentripplanner-dev/hUOuu2McMss/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opentripplanner...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jorden Verwer]

Hello Mohamed,

Basically, you need to create a mapping from edges to speeds and a way to update its contents. Most of the code you'll need to change can be found in the (Plain)StreetEdge class. Watch out for potential race conditions. Most of the complexity will be probably be in interpreting the input data correctly.

My code wasn't based on any particular release, but the branch it's based on shares characterics with the 0.10, 0.11 and (upcoming) 1.0 releases. It's probably closest to 0.11 and furthest removed from 0.10, I'd say.

Regards,

Jorden

Op maandag 10 november 2014 13:09:55 UTC+1 schreef Mohamed T. AlRefaie:

To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-dev+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to a topic in the Google Groups "OpenTripPlanner Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/opentripplanner-dev/hUOuu2McMss/unsubscribe.

To unsubscribe from this group and all its topics, send an email to opentripplanner-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.