Lots of 207 errors for failing to route

[srajkovic]

I'm getting a lot of 207 errors when trying to route various coordinates in the US, routing over the latest North America pbf from GeoFabrik.

I noticed some older issues, like #688 dealt with running out of /tmp space, which is possible since the partition that tmp is on doesn't have much space. I was under the impression that that threw an exception during preparation now though, and my prepare completed without error. There were no errors in stxxl.errlog.

I was wondering if there was a way for me to check if my prepare actually worked, and also if there was any benchmark as to the amount of space needed in the tmp folder. I know theres a checksum printed when you load routed, so is there a "truth" checksum I could compare that to?

Edit: I'm going to run again with /tmp on a big mostly empty drive, and post the results here.

Extracting:

[info] Input file: north-america-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 32
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.3.1 (release)
[STXXL-MSG] 1 disks are allocated, total space: 40000 MiB
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info] motorcar
[info] motor_vehicle
[info] vehicle
[info] Parsing in progress..
[info] Parsing finished after 865.321 seconds
[extractor] Sorting used nodes ... ok, after 23.612s
[extractor] Erasing duplicate nodes ... ok, after 17.286s
[extractor] Sorting all nodes ... ok, after 390.327s
[extractor] Sorting used ways ... ok, after 6.312s
[extractor] Sorting restrictions. by from... ok, after 0.037s
[extractor] Fixing restriction starts ... ok, after 3.853s
[extractor] Sorting restrictions. by to ... ok, after 0.043s
[extractor] Fixing restriction ends ... ok, after 4.429s
[info] usable restrictions: 27675
[extractor] Confirming/Writing used nodes ... ok, after 176.051s
[extractor] setting number of nodes ... ok
[extractor] Sorting edges by start ... ok, after 322.631s
[extractor] Setting start coords ... ok, after 308.004s
[extractor] Sorting edges by target ... ok, after 313.37s
[extractor] Setting target coords ... ok, after 331.621s
[extractor] setting number of edges ... ok
[extractor] writing street name index ... ok, after 0.427s
[info] Processed 167452079 nodes and 175073054 edges
[info] extraction finished after 2763.74s

Preparing:

[info] Input file: north-america-latest.osrm
[info] Restrictions file: north-america-latest.osrm.restrictions
[info] Profile: profile.lua
[info] Threads: 32
[info] Importing n = 167452079 nodes
[info] and 175073054 edges
[info] Graph loaded ok and has 175019818 edges
[info] 27675 restrictions, 7885 bollard nodes, 195261 traffic lights
[info] Generating edge-expanded graph representation
[info] merged 0 edges out of 350034588
[info] Removing graph geometry while preserving topology
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] removed 141736179 nodes
[info] Geometry successfully removed:
compressed edges: 39235300
compressed geometries: 322531420
longest chain length: 8674
cmpr ratio: 0.121648
avg chain length: 8.22044
[info] new nodes: 25715899, edges 66562230
[info] Node compression ratio: 0.153572
[info] Edge compression ratio: 0.190159
[info] Identifying components of the road network
[info] identified: 141874092 many components
[info] generating edge-expanded nodes
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 175017292 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 175017292 edge based nodes
[info] Node-based graph contains 64363002 edges
[info] Edge-expanded graph ...
[info] contains 129741821 edges
[info] skips 28632 turns, defined by 27611 restrictions
[info] skips 56039648 U turns
[info] skips 7327 turns over barriers
[info] Timing statistics for edge-expanded graph:
[info] Geometry compression: 193.795s
[info] Renumbering edges: 0.975s
[info] Generating nodes: 77.319s
[info] Generating edges: 112.715s
[info] building r-tree ...
[info] constructing r-tree of 175017292 edge elements build on-top of 167452079 coordinates
[info] finished r-tree construction in 11.225 seconds
[info] using hardware based CRC32 computation
[info] CRC32: 4182758782
[info] writing node map ...
[info] initializing contractor
merged 207082 edges out of 259483642
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 64363002 nodes .... 10% . 20% . 30% . 40% . 50% . 60% . [flush 42078724 nodes] 70% . 80% . 90% . 100%
[info] Contraction took 1553.56 sec
[info] Getting edges of minimized graph
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Serializing compacted graph of 359127881 edges
[info] Building node array
[info] Building edge array
[info] Preprocessing : 2387.08 seconds
[info] Expansion : 232896 nodes/sec and 89517.5 edges/sec
[info] Contraction: 41429.3 nodes/sec and 231164 edges/sec
[info] finished preprocessing

[DennisOSRM]

Use the latest revision from develop branch. It does not use /tmp anymore. Also, if you add -DBUILD_TOOLS=1 to the cmake call, it will build a tool called check-hsgr. That will let you check the main file.

[srajkovic]

I'll try the tools first, and report back.

[DennisOSRM]

Any updates here?

[srajkovic]

Yeah, still getting them. I'm gonna compile a list of the queries that cause them.

On Sat, Aug 9, 2014 at 6:47 AM, Dennis Luxen [email protected]
wrote:

Any updates here?

Reply to this email directly or view it on GitHub:
#1143 (comment)

[DennisOSRM]

Please check whether you get different results from the demo instance. If the results are different then most probably the data is broken

[srajkovic]

I checked one of them once, and got the same error. check-hsgr also returns that the data is fine.

Stefan Rajkovic
(603) 660-4352 | [email protected]
LinkedIn: https://www.linkedin.com/stefanrajkovic l Twitter: https://twitter.com/stefan_rajkovic

On 9. Aug, 2014, at 12:21, Dennis Luxen [email protected] wrote:

Please check whether you get different results from the demo instance. If the results are different then most probably the data is broken

—
Reply to this email directly or view it on GitHub #1143 (comment).

[snc]

I have a similar problem, here a simple route that also fails with latest development-build:
https://router.project-osrm.org/viaroute?z=0&loc=48.868661,2.301173&loc=48.828556,2.741766

[TheMarex]

@snc the two roads are not part of the same connected component. "Accès Parking George V, Paris"
is a one-way road without an exit.
To migrate such issues and improve the routing quality of OSRM consider contributing with to-fix which detects such errors in the road network.

[snc]

Ah OK thanks, I just wondered because the routino router worked for the same waypoints using the same osm.pbf data. I think this router makes something different when importing this data.

[TheMarex]

@srajkovic Any updates?

[srajkovic]

Sorry, I've gone back to school and haven't been working with OSRM lately. 

—
Sent from Mailbox

On Mon, Oct 6, 2014 at 7:15 PM, Patrick Niklaus [email protected]
wrote:

@srajkovic Any updates?

Reply to this email directly or view it on GitHub:
#1143 (comment)

[DennisOSRM]

Flagging as a duplicate of #930