On Wed, 13 Mar 2019 at 22:42, Jo <winfi...@gmail.com> wrote: > I think we should move to subrelations for bus routes at some point. > Actually doing it is somewhat tricky. We'd definitely need editor support > to show that a route which consists of subroutes is continuous or not. >
Not a big problem. Not compared with sorting the route I just had to sort (again). Dunno if I messed up last time I sorted it or what, but it's a major pain. Maybe I need a different JOSM plugin, but I already find JOSM confusing enough. One problem I found with JOSM was zooming to a way in the relation when that way appears more than once. I did that a lot so I could check the next way in the route was even in the table or had to be added. But if a way appears more than once in a route (as several do in the one I was working on) then JOSM moves to the first occurrence of it in the table of ways, rather than the one I just selected. If I could use a superroute then I would choose the subroutes so that no way appears twice in a subroute. That's a problem with circulars that non-circulars don't have (most of the time a non-circular has two variants A->B and B->A and although most of the ways are common to both they're separate relations). A truly circular wouldn't have that problem either, but this one has loops and repeats and side-branches that aren't loops. > The biggest point of contention seems to be whether the stops should go > into the subroute relations as well. I'd say no. Keep the stop sequences > for a particular variation in itinerary together in a route relation per > variation. And only use the subroutes to collect continuous sequences of > ways. > > At the same time, some people would think it's more logical to have a > sequence of ways, then a stop, then the next sequence, a stop, and so on. > For that too, it would be nice to have editor support that shows that the > way before and the way after actually connects, or not. > That's the other problem I have. A stop which isn't a stop the first time the bus passes along a way but is a stop the second time. Although the ordering of stops does mean it's possible to figure out if you inspect the relation closely, it's not obvious. Allowing stops to intersperse the ways would make it slightly easier to figure out. But using a superroute makes it very clear: it's not a stop on segment 1 but it is a stop on segment 2. So I'd definitely want stops on the subroutes not the superroute. I think it makes more sense that way anyway. It keeps the stops with the associated ways. If we go the way of subroutes for PT routes, I/we can probably coerce a > GSoC student to create support for it in PT_Assistant over the summer. > All the tools I need to make life a LOT easier by splitting the route into subroutes are there. Breaking the route up manually is relatively simple (takes several steps and some time, but very little thought), and after that it just gets far, far easier to deal with short segments than one big, looping, wandering route. If I choose the subroutes wisely I can even let JOSM sort them for me (it gets very confused with this route where several ways are traversed more than once). There are only three things stopping me doing that right now: 1) What the response to my post was. So far nobody has said that it's a really bad idea since I posted details of the route. Unless there are many howls of outrage, I'll assume it's not an outrageously bad idea. 2) How to differentiate between the different segments. I can't use from and to because those are supposed to be terminal destinations (preferably as shown on the bus itself). So I need a new tag (or two). I could get by with something like segment="A to B", segment="B to C" etc. But there's probably a better way of doing it. And I'd like to do that both for human readability when mapping and to allow umap a way of distinguishing between subroutes with an overpass query. 3) What else I haven't thought of. What's show-stopper might turn up after I've spent time splitting the route. -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
