forward_offset/reverse_offset - "short must suffice"?

[systemed]

edge_based_node.hpp has these comments:

int forward_offset;  // prefix sum of the weight up the edge TODO: short must suffice
int reverse_offset;  // prefix sum of the weight from the edge TODO: short must suffice

Is there any likely downside of changing forward_offset and reverse_offset from int to short throughout? If so, what would be the best way of mitigating this? (I could do with a few extra bytes in PhantomNode et al...)

[TheMarex]

You would need to test this. This is bound by the longest duration a single compressed edge (that is the part of a way between two intersections). While in general this might be below 2^16 - 1 (= 65535 deci-seconds < 2h), I don't see how this can be true in general. Imagine long winded road on the coast of Chile. Especially problematic for the walk and bike profile.

If you want to give it a try add a check here forward_dist_prefix_sum[i] and reverse_dist_prefix_sum[i] if the are small enough.

[systemed]

Great, thanks. I'll put a check in there and see what's output. Yes, I can imagine there being some roads in the US midwest that might exceed 2h on a bike profile.

[systemed]

I ran it on Colorado with a slightly adapted version of the bike profile. There were indeed some edges (though not too many) with a length of >65535.

To prevent this I added a check to graph_compressor.cpp:

if (graph.GetEdgeData(forward_e1).distance + fwd_edge_data2.distance > 60000 || 
    graph.GetEdgeData(reverse_e1).distance + rev_edge_data2.distance > 60000 ) { continue; }

This prevented large edges being created. The impact on the data is minimal:

With limit:
[info] Node compression ratio: 0.138072
[info] Edge compression ratio: 0.174624
[info] Processed 3875569 edges

Without limit:
[info] Node compression ratio: 0.138025
[info] Edge compression ratio: 0.17458
[info] Processed 3875092 edges

i.e. only 0.1% more edges. So I think I have a solution. Thanks for the help!