Allow Multiline 'Routes'

[Pete-Y-CS]

Our pipeline mappers have identified a couple of use cases effectively for multiline routes.

The first is simply where you have a network with lots of routes which are not really considered routes but simply links in a network. If these can represented as a single multi-line (which geojson supports) it might be a more natural way to represent the data.

Above is an example of a network which doesn't really have natural routes just many links in a network.

Similarly, it could be a way to represent alternative paths to along a route. This I think is quite nicely covered simply by drawing a new line and tagging it as 'an alternative route', but multiline might give us a nice way to approach this. Haven't fleshed out the idea in my head.

[dabreegster]

The first example looks like a normal LCWIP to me; it just happens to contain lots of smaller routes. Why not use the current method and make sure we have a way to tag new vs existing? There are some cases with "spurs" that would have to be two separate routes, but seems fine:

For the alternative route idea, if we have one set of properties describing multiple linestrings, we lose the ability to talk about each linestring and describe which one is the main, the alt, any differing costs/timelines, etc.

Some questions / thoughts:

• Similar to the question about when something should be one schema or many schemas, we need to think about what properties we're trying to share between linestrings. Is the tension that for alternative routes, mappers have to fill something out multiple times? What if the budget/cost of an alternative does differ -- isn't it better to clearly represent that?
• Whatever we're trying to solve by grouping linestrings together, can we do that by making a new schema and moving them into there?
• MultiLineString raises some UX questions about selection if parts of the routes overlap. Do we have examples where this would happen that we could think through?
• The complexity of the split route tool increases with MultiLineString; you need to make decisions about how the newly split off single LineString piece gets represented.
• The route snapper UI and implementation makes a number of assumptions that MultiLineString would break, and I would be strongly opposed to adding complexity there without clear understanding of the goals and thinking through the UX first

[Pete-Y-CS]

Hmm your point about sharing too much scheme data is definitely a good point.

By the second question do you mean scheme?

In general though, message received, will make sure to flesh out requirements further to see if it's useful enough to try and overcome these questions.

[dabreegster]

By the second question do you mean scheme?

Yes, I guess I'm asking why we're trying to group different pieces of geometry together. What kind of semantic relationship are we trying to express? It's a very similar question to whether an LCWIP should be one big scheme, or whether it should be split into multiple schemes that happen to cover the same area. The answer is based on the geometry all sharing the same budget / timescale / details.