telenav / osrm-backend Goto Github PK

Need at least two dockers:

• osrm-backend-dev docker image: include all dependency to compile and debug osrm-backend;
• osrm-backend docker image: include built binaries for run, e.g. compile mapdata, run osrm-routed, etc.

OSM data represent oneway using from node -> to node + oneway=yes
Professional data doesn't reverse this and using "to node-> from node" + oneway=-1 to represent oneway.

• Verify traffic update is successful for each iteration. There should be a heartbeat to indicate the result of live information injection.
• Evaluate performance during the switch of new customized data

Per our usage, osrm-traffic-updater have command line parameters to decide whether use all live traffic or blocking-only(flows with speed near 0 and blocking incidents) live traffic.

If only use blocking-only live traffic, then the calculated routes will not include ways can NOT be passed due to traffic.

List of issues while calling extraction with internal pbf

For next step, please go to: #6

Recently we use golang implements some tools for our osrm-backend intergration, mostly for live traffic integration.

For the golang project layout, we already have figured out it by #66.

But for where we put the golang codes, we should discuss it for long-term.

Currently our golang code almost only have live traffic integration related stuff, so we put them under folder osrm-backend/traffic_updater. But we possibly have more and more tools, proxy services or osrm API implements by golang, so we should to figure out a long-term solution for this.

I have several proposals:

1. make a subfolder osrm-backend/integration instead of current osrm-backend/traffic_updater, put all other osrm integration related golang codes inside it.
2. create another git repo named osrm-integration under Telenav, put all golang codes inside.

I'll prefer option 1 for now. May be we can go with option 2 in the future if the project is too bigger.

@CodeBear801 how's your opinion? any better idea or better name?
I'd like to implement it after #66.

DataFacadeBase, DataFacadeAlgorithm

Recently we met many issue that due to unstable traffic-proxy.
We should mock traffic-proxy in our test code, that we possible to run post progress without a real traffic-proxy.

DataFacadeProvider, ContinuousBlobAllocator, Storage

More information please go to here: #56

Refer to suggestion: Project-OSRM#5503 (comment), we're going to have a try with --mmap to shorten the initialization time by osrm-routed.

Currently container logs only write to console, but it's not good for log collection and monitoring system.

For overall architecture, please go to design doc
For background, please go to summary of #22 and here
For subtask of partial customize cells, go to #49
For subtask of optimize intermediate file of <way, nodeids> mapping table, go to #31

Statistics not only process time, but also data count/size.Now we already have got flows count: 16130303, time used: 12.398055 seconds, but still need more.
E.g.

• how many traffic flows in the generated flows map
• how many wayid-nodeids loaded
• how many traffic flows have been touched
  • how many forward
  • how many backward
  • how many related wayids
  • how many related nodeids
• how many fromnode,tonode,speed generated

• Implement OSRM traffic format conversion
• Implement update strategy to control traffic update

It will be helpful for trace/debug if we can easy to know which engine and which data of the running service. Hopefully OSRM already provide the -d flag by osrm-extract. We use PBF file name instead of timestamp of OSM since we also need it for internal PBF.

Current go version is 1.12.5, expect to 1.13.

We'll go with option 1 from the discussion: #77

make a subfolder osrm-backend/integration instead of current osrm-backend/traffic_updater, put all other osrm integration related golang codes inside it.

• OSRM customization -> Can we limit this part's time cost
• OSRM facade -> How to abstract common API
• OSRM cost model + lua
• OSRM routed initialization(memory map vs shared memory)

[optional]

• lane based routing
• Tegola -> Vector tile engine written by go
• Microservice -> gRPC, Istio, K8s, Zipkin, Skaffold, OpenCensus
• Cloud map matching

blocking incidents only.

We want to use ElasticSearch to collect OSRM's logs and Kibana for visualize result.

Tasks(more could coming later)

• Use docker compose to setup ELK stack
• Send OSRM's log to elastic search
• Build visualization dash board in Kibana

For current routed_startup,

• In the function of reorderFirstLast

    const auto flipped = [](auto fn) {
        return [fn](auto &&lhs, auto &&rhs) {
            return fn(std::forward<decltype(lhs)>(rhs), std::forward<decltype(rhs)>(lhs));
        };
    };

Q: why not

fn(std::forward<decltype(rhs)>(rhs), std::forward<decltype(lhs)>(lhs))

Is it due to the use of reverse_iterator?

• In my example of https://github.com/Telenav/open-source-spec/blob/master/osrm/doc/osrm_c%2B%2B_examples.md#stdforward, for the sample code here: cpp.sh/8kv3r, why can't I use this strategy

MatchParameters param2(true, true, std::move(waypoints),{});
// C++ could accept MatchParameters param2(true, true, std::move(waypoints)), which means nothing for std::forward<Args>(args_)..., but if using empty array_list{}, seems C++ could not deduce correct type, is that due to based on {} we could not deduce T in vector<T>?

Issue description:
Getting data from traffic server and run customization we got such result:

[info] Loaded /Users/xunliu/Desktop/data/us_here_nv/traffic.csv with 6727490values
[info] In total loaded 1 file(s) with a total of 6727236 unique value
[info] Used 4220514 speeds from LUA profile or input map
[info] Used 0 speeds from /Users/xunliu/Desktop/data/us_here_nv/traffic.csv
[info] Updating segment data took 195.301ms.
[info] In total loaded 0 file(s) with a total of 0 unique values
[info] Done reading edges in 2609.77ms.
...

Which means value from traffic.csv isn't match with OSRM.

Summary:
Issue is due to traffic component dropped original pbf's node id, so additional mapping need to be applied.
A quick solution is: traffic component pass mapping of <wayid, speedmapping>, but preprocessing pbf we generate mapping of <wayid, nodeids>, and by another program we will convert traffic result to <from_node_id, to_node_id, speed> which is expected by OSRM customization.
Current performance benchmark is: getting traffic data from traffic service takes about 20 seconds, then will need another 70 seconds to generate csv file for OSRM.

We continue integration with this version but start several other issue to optimize the performance.

Follow up issue:
#30
#31

If delta traffic only affects several cells, we can speed up the customize process by only process this affected cells.

• It's better to add a command line parameter to enable/not-enable this function.

Time: 0529109

Meeting memo

Why OSRM
#1. OSRM provide API for all backend service, such as direction, tile, map matching
#2. Experience to enhance streaming map

Targets
#1. OSRM + HERE Traffic + OSM. 6/30 POC server. Jay/ Yang Chen (around 6/30, 50%)

• OSRM + Traffic solution (05/17) Jay, Perry, Lichen, Junwei

#2. OSRM + HERE data + HERE traffic (Perry) 6/30
OSRM comoile NA HERE PBF
(todo: EU/CN, merge code to telenav-master)

• Validation OSRM + HERE + Traffic (Yang Chen)
• Tile based graph implementation (Xizhen + Mingzhou)
  Graph API/Map Matching (Xufeng)

#3. OSRM deoployment with docker + K8S. （Jay）

• Cantainer for NGX solution
• OSRM

#4. evaluation vs ngx

Reference:

• http://project-osrm.org/docs/v5.5.1/api/#general-options
• https://github.com/Telenav/open-source-spec

There's a great (but long) paper on this topic to be found here:
http://algo2.iti.kit.edu/documents/Dissertation_Kobitzsch_Moritz.pdf

(Chapter 5 gets into the meat of current approaches for alternative path finding).

I saw it from Project-OSRM#5581.
Let's read it to see whether it can improve our alternatives algorithm or help us to tune OSRM alternatives better.

Also, there're some parameters for OSRM alternatives may be helpful for us.

After get traffic for a whole region once, it's possible to get delta traffic data after that, then we possible to get very small traffic data set. It will be very useful if we can also support partial customize.

Import professional vender's pbf crashes during preprocessing. Need to fix this issue to set up OSRM server internally.

We need to generate <wayid, nodeids> mapping table to enable Telenav traffic for OSRM. More background could go to #22.
This table will be used to generate speed.csv each several minutes and be used for OSRM customization. The initial version takes about 70~80 seconds to iterate all the table and about 10GB's memory.
Our target is optimize time cost for dealing this file.

[Description]

• The communication between OSRM and traffic service
• How OSRM work in Telenav's cloud archicture

[Delivery]

• Flow chart to describe coordination with traffic service
• Create detail tasks for impl and integration

The docker image build and compile data process should be automation tools which easy to use.

Generating statistics and comparing with existing Telenav engine's output.

As we discussed in #63 (comment), the original idea comes from Refer to Project-OSRM#4449 (comment)

1. Make time-independent route requests potentially with the alternatives=n MLD parameter
2. Use the annotations feature for osm node ids, speed and weight on route segments for all routes
3. Make time-dependent query on the intersection of all segments, use weight for optimization

In our design, at the begginning, we can name it as Phase 1:

• In step 1, the calculation maybe based on pure time-independent data or data within blocking traffic(flows with speed near 0 and blocking incidents).
• In step 3, the time-dependent query mostly will start with calculate weight/duration with both live traffic and historical speed for each alternatived routes, then ranking them to pick up the best one or the best several as result.

We have to estimate whether the alternatives can returns good enough routes(the routes should not look similar but have significant differences).

Phase 2
In step 3, we may possible to construct a subgraph based on these alternatives since we can have all nodes,weights, then do Dijkstra on it to get better route. That's the better way mentioned in paper(https://arxiv.org/pdf/1606.06636.pdf) , and there're a lot of discussion in Project-OSRM#5503

• Why this task
• Design doc
• Profile result
• This task also implemented #50

I'll prefer to set goreturns or goimports as default code format tool in our vscode to automatically format our codes.

Reference:

• http://dominik.honnef.co/posts/2014/12/go-tools/
• https://medium.com/@alenkacz/gofmt-goimports-goreturns-why-do-we-need-three-formatters-a3518ee6cc90

Some resources:

• https://github.com/golang/go/wiki/Modules
• https://blog.golang.org/using-go-modules
• https://roberto.selbach.ca/intro-to-go-modules/

#1. Issue description
TBB Warning: Exact exception propagation is requested by application but the linked library is built without support for it
terminate called after throwing an instance of 'osrm::util::exception'
  what():  CSV file ../osrm-data/traffic.csv malformed on line 1:
 13396984,27077922,25.277778
include/updater/csv_file_parser.hpp:120include/updater/csv_file_parser.hpp:85
Aborted (core dumped)

#2. Issue description

TBB Warning: Exact exception propagation is requested by application but the linked library is built without support for it
terminate called after throwing an instance of 'osrm::util::exception'
  what():  CSV file ../osrm-data/traffic.csv malformed on line 6727408:
 33699965,33699966,

[Description]
Confirm the direction could work. Verify the result of customization and frequency of live traffic update based on small data provided by traffic team.

[Delivery]

• Traffic Input format
• Draft estimation for customize schedule
• Draft load estimation

[Description]
OSRM use "duration" for ferry/shuttle_train's travel time, which might be helpful if:

• Have reasonable coverage
• Valid value

Here is the description for duration:
https://wiki.openstreetmap.org/wiki/Key:duration

Here is the doc for OSRM logic:
https://github.com/Telenav/open-source-spec/blob/master/osrm/doc/weight_and_duration_calculation_in_osrm.md

By the draft design OSRM with Telenav Traffic Design (Draft), we hope to use timed blue/green deploy by Kubernetes to support live traffic update without any service breakup.
In the test there're several issues occurred:

1. The startup process(pull latest traffic and dump to traffic.csv file, osrm-customize, osrm-routed) totally need about more than 15 minutes for North America.
   • It's not critical but too much time to let the live traffic effective. We have to figure out better way to shorten it.
2. The blue/green deploy will terminate old container once new container running. But it needs about 15 minutes from the new container running to the new container service ready as above, the service will be unavailable in this 15 minutes.
   • It will be good if kubernetes have some settings to switch service to new container until new container service ready, e.g. something like heartbeat check. Not sure whether kubernetes have such setting, need to do some research.

Issue description

OSRM route quality depend on its cost model, we need to identify automatic and useful strategy to evaluate cost model.

Current tools

1. OSRM frontend
   OSRM frontend could calculate route for <orig, dest> pair
   
   OSRM frontend using different color to indicate different speed. With the debug mode of osrm-frontend, we also possible to see speeds for the whole map.
   E.g. http://internal-a0e2063e4e2a011e9b9e8061a2b4d53d-420131598.us-west-2.elb.amazonaws.com:9966/debug/#14.52/37.3929/-121.9950

2. OSRM route service do have some data in response. With parameter &annotations=true, you can see nodes, distance, duration, datasources, weight, speed in response.
   See details in https://github.com/Telenav/osrm-backend/blob/master-telenav/docs/http.md#route-service

3. Telenav internal tools
   We convert OSRM response to Telenav's response, so which could connect to our internal tools.

Summary

Collect ideas from discussion

OSRM use CRP to deal with live traffic, but historical speed is one of important features to support better route result. Live traffic make sense for the area near start point, but when expand road graph outside for 1 hour, historical speed play more and more important role.

Solutions

Option 1: Calculate sub-graph based on different time frame and then calculate final route based on sub graph

More Info
Project-OSRM#5503
Time dependent routing

Option 2: Adjust segment cost during route calculation

int GetSpeed(const EdgeId& id, const Time& t)

Option 3: Only use historical speed to pick up better route for optimization(weight/duration calculation)

Refer to Project-OSRM#4449 (comment)

• Make time-independent route requests potentially with the alternatives=n MLD parameter
• Use the annotations feature for osm node ids, speed and weight on route segments for all routes
• Make time-dependent query on the intersection of all segments, use weight for optimization

Issue description:Initialization failed with professional data. Following errors appeared in docker logs:

[warn] Missing/Broken File: /osrm-data/NA.osrm.datasource_names
[error] Required files are missing, cannot continue

Root cause
The file datasource_names hasn't been generated, the step of customization must be called if you want to route with MLD

There're some best practices for Go project layout from industry. The most important part of the Go project layout is how to organize Go packages.
I have summried them here: go-project-layout

In this task, I'd like to refactor our Go packages layout by:

• follow the /cmd top dir convention
• group packages by dependency

This task will after #51 since there'll be many Go code changes in that one.

There's even no vi/vim in the packaged docker image.
It's better to let our docker to easy to use and easy to debug for better efficiency since our team is not quite big for now.

[Delivery] Solutions and estimations