Refactor EdgeBasedGraphFactory (again)

[TheMarex]

Currently the EBGF is responsible for:

1. Creating edge based nodes (input for StaticRTree)
2. Computing the edge based node weights used for loop detection (.enw file)
3. Computing the intersection classification (e.g. simplified bearing values + entry:yes/no) (.icd)
4. Computing the lane data (.tld)
5. Computing the actual turn instruction
6. Saving all the data associated with an edge-based-edge (.edges):
   • GeometryID
   • Street-Name
   • turn lane ID
   • turn instruction
   • entry flags
   • travel mode
7. Generating a lookup-table for osrm-contract so we can map single road segments back to edge expanded edges (.edge_segments)
8. Computing the actual dual-graph to the node-based-graph

This issue should capture ideas on how we can reduce this number of responsibilities as much as possible. The goal should be to reach the point where the responsibilities boil down to:

1. Computing the actual dual-graph to the node-based-graph

High priority is to remove any internal serialization of data. That means the EBGF does not serialize out itself:

• .edge_segments
• .edges

/cc @daniel-j-h @mokob @danpat

[TheMarex]

Some ideas:

1. Creating edge based nodes (input for StaticRTree)

This is actually completely independent of anything in that class. It only needs the node based graph and the compressed edge container. Should be possible to move outside with little pain.

1. Saving all the data associated with an edge-based-edge (.edges):
   • GeometryID
   • Street-Name

Could be completely removed if we establish the convention of looking these up by edge-based-node id.

• turn lane ID
• turn instruction
• entry flags

Depend on 3-5