Open Pete-Y-CS opened 9 months ago
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:
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.
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.
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.
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.