New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show realtime road segments duration in match. #2609

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@gardster
Contributor

gardster commented Jun 30, 2016

The match plugin has a "duration" field in output, but takes information for it from the road graph. It is a strange behavior when we have timestamps in the query.
This PR rewrites segments weights at the response rendering phase with new values computed from matched timestamps.

@danpat

This comment has been minimized.

Show comment
Hide comment
@danpat

danpat Jun 30, 2016

Member

Ah, nice idea. Yes, this makes sense if real timestamp data is available.

Can you add a test case for this?

Member

danpat commented Jun 30, 2016

Ah, nice idea. Yes, this makes sense if real timestamp data is available.

Can you add a test case for this?

@daniel-j-h

This comment has been minimized.

Show comment
Hide comment
@daniel-j-h

daniel-j-h Jun 30, 2016

Member

We often said to users "timestamps don't really have to be timestamps, increasing integers work fine, too" --- this will change it.

Member

daniel-j-h commented Jun 30, 2016

We often said to users "timestamps don't really have to be timestamps, increasing integers work fine, too" --- this will change it.

@TheMarex

This comment has been minimized.

Show comment
Hide comment
@TheMarex

TheMarex Jun 30, 2016

Member

Thanks for looking into this! 👍 Unfortunately I think there are some misconceptions here.

The match plugin has a "duration" field in output, but takes information for it from the road graph. It is a strange behavior when we have timestamps in the query.

This is not the function of the match plugin. The result should always reflect the state of the internal data. It does not interpolate trace data, it uses it as input to compute the most probable route given its current knowledge of the road network. It is basically like asking OSRM "Hey what do you think this route would look like".

If you need this behavior it is quite simple to implement this client side using some weighted scaling:

  • For each pair of input coordinates compute the time between them t_trace_segment.
  • For each step along the route take its duration t_step
  • Scale each of those durations by: t_step / t_leg * t_trace_segment

Thanks again for the effort. Hope this explanation helps.

EDIT: Fixed that calcualtion.

Member

TheMarex commented Jun 30, 2016

Thanks for looking into this! 👍 Unfortunately I think there are some misconceptions here.

The match plugin has a "duration" field in output, but takes information for it from the road graph. It is a strange behavior when we have timestamps in the query.

This is not the function of the match plugin. The result should always reflect the state of the internal data. It does not interpolate trace data, it uses it as input to compute the most probable route given its current knowledge of the road network. It is basically like asking OSRM "Hey what do you think this route would look like".

If you need this behavior it is quite simple to implement this client side using some weighted scaling:

  • For each pair of input coordinates compute the time between them t_trace_segment.
  • For each step along the route take its duration t_step
  • Scale each of those durations by: t_step / t_leg * t_trace_segment

Thanks again for the effort. Hope this explanation helps.

EDIT: Fixed that calcualtion.

@TheMarex TheMarex closed this Jun 30, 2016

@Komzpa

This comment has been minimized.

Show comment
Hide comment
@Komzpa

Komzpa Jul 1, 2016

Contributor

@TheMarex

"Hey what do you think this route would look like". - this is the function of "route" call.

There are both temporal and spatial components in the trace. What you offer is to ignore the temporal component of the path at all and just treat is as /route call - then:

  • why at all separate these two concepts?
  • why have timestamps at the input, if "any sequence will be fine"?

The result should always reflect the state of the internal data - that is unlikely. I'd say that result should always be dependant on inputs, and inputs are OSM graph (going to internal data, but we don't actually care - treat it as cache), speed profile, and trace with timestamps.

It is not expected in match call to get back timestamps that are not related at all to the timestamps fed into it.

Having weighted scaling doesn't resolve the issues of being stuck in traffic and moving disproportionally.

Contributor

Komzpa commented Jul 1, 2016

@TheMarex

"Hey what do you think this route would look like". - this is the function of "route" call.

There are both temporal and spatial components in the trace. What you offer is to ignore the temporal component of the path at all and just treat is as /route call - then:

  • why at all separate these two concepts?
  • why have timestamps at the input, if "any sequence will be fine"?

The result should always reflect the state of the internal data - that is unlikely. I'd say that result should always be dependant on inputs, and inputs are OSM graph (going to internal data, but we don't actually care - treat it as cache), speed profile, and trace with timestamps.

It is not expected in match call to get back timestamps that are not related at all to the timestamps fed into it.

Having weighted scaling doesn't resolve the issues of being stuck in traffic and moving disproportionally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment