No. That doesn’t work either. I can now see the point why OSM wants all route variants as a separate relation on their own.

Just created relation 8276636, which I have called an augmented_route. The idea is that it points to ‘the’ bus route (in a given direction), but also contains meta-data about that bus route, such as which bits are optionally not served etc. A simplistic rendered could still look inside and get the first member, which is a normal route and render that.

The other members of this augmented route are all relations, being variations to the route: alternative pathways and short runnings (and the reasons for those).

I don’t want to do it as a super_route as, that is already used to group many routes, not group routes with their variants

The idea is that routing or rendering software will optionally add/subtract these route variants, according to whatever conditions govern them. These variants generally involve matching node-pairs in them with the same ones in the ‘main’ route, and replacing them with their own contents. Obviously, this will require a bit of disambiguation to cope with self-crossers and the like, but I don’t want to add ‘role=junction-point-1’ or the like yet, to members in the main route.

I also need to have a think about how these variants can be made to affect ‘interval’ type tagging. E.g, adding an optional short-running might double the frequency from 2BPH to 4BPH.

Obviously, I haven’t thought this all the way through yet.

I’m finding it hard going mapping bus routes, due to all the various anomalies and trying to shoehorn that into OSM’s guidelines.

I’ve just put together some 8 relations, all notionally the same route number in the same direction. This is a maintenance nightmare, but I suppose I could come up with some sort of tool for automatically checking for consistency.

Doing them as seprate relations, as OSM requires, now makes it meaningless to put an interval tag on, because, as separate routes, they don’t look at all “regular”: the interval is only meaningful across the whole set of route variants.

Having to do a route as e.g. 2 relations, just for a minor peak-only variant is insane, the main reason for which is this:

You can’t tag a small section of a route (unless there’s a way of putting arbitrary text in line with stops and ways in a relation).

I need some form of route segmentation, which will be supported by the renderers, and which will be seen as a contiguous route by any routing software. If I can’t see any sane pre-existing precedent, I’m going to have to do my own thing. I’m imaginging a structure like this:

interval=60 Stop1 Stop2 Way1 Way2 interval=15 Stop3 Stop4 Way3 Way4 Way5 Way6

Stop3 Way3

I’ve decided to give this interval thing a try. Main problem is reconciling it with the requirement that all route variants have a relation to themselves. My route has two ‘core’ variants, one of which is a short run of the other. The ‘1’ variant runs at 2 BPH, and the ‘2’ variant also runs at 2 BPH. This is obviously a total of 4 BPH for anyone wanting to travel both to and from points on the common section of route. However, they are engineered so that they interleave, and that the 4 BPH really is ‘one every fifteen minutes’, as opposed to four buses spread irregularly about within the hour.

This is one reason I’d like to have route segments; we could specify the interval for alternative routes, short-runnings, and telescopings without having to use heuristics to infer it by spotting common parts of routes.

This particular pair of examples (relations 8,257,900 and 8,265,640) are midday-only buses (‘midday’ within the definition of the interval tag). Can someone check I’ve done it right, please. The defining characteristic of this route/variant is that it serves a village, which is effectively inaccessible due to traffic congestion other than between 0900 and 1500. There is one other such trip, in the afternoon peak, but I’ve omitted that, as I’d rather understate the availability of buses on that route.

Very unsure about how best to present bus routes in a concise manner. I don’t want to have to put the whole timetable on OSM, as it would become OOD very quickly.

Numbering the variants seems a silly idea, as that would make it difficult to add new ones or to split existing ones. I can’t think what else to do, though, so I’ll do it like that FTTB.

I don’t want to put every minor variant on, because it would make people think that there is a regular service, when it’s just occasional (and how to define 'occasional' ?) and I don’t want to miss routes off, as it will make it look like there’s no service at all.

Maybe I should add some form of BPH or BPD tag ? Should BPH relate to the average across the whole day, or just within the section of the day where it operates ? I can’t just add text like ‘no service after 1900’ as that would depend on which section of the route we’re talking about. I could do that if we could map routes as segments, but we can’t; we have to do each entire route variant as a separate relation.

I am still struggling to map the local bus routes where I live. It is difficult to reconcile reality with what people expect and with the OSM guidelines. The schema with which I have come up goes something like this:

map each variant of a bus route (route letter/number, direction, reverse-runs, self-crossings, short-runnings, telescoping, spoon routes, intermediate terminuses, ecs movements, letter/number ambiguity, same vehicles changing number) as a separate relation, as the guidelines say:

take, as my starting point, the block in most bus timetables where it says “.. and then at these minutes past each hour, until…”. Tag such routes with bobby444:direction=E, W, or whatever bobby444:variant=1, 2, etc

For any variations on these, outside this block, add higher variant numbers, with higher numbers corresponding to something like a ‘routing metric’, with higher numbers corresponding to less frequent, less likely, less useful, less regular variants. The variant numbers must obviously be unique, but I haven’t decided whether they should be contiguous or not.

For minor variations (the test for minor being ‘can I realistically walk from any point on this route to a suitable point on the parent route), the variants get a decimal number. Such variants might be not serving a shopping center after shopping hours, or not going into a housing estate at times when it would cause congestion. A variant can either ‘add’ or ‘take away’ ways and/or stops from a parent route.

The idea is that any simplistic route renderer will just take the routes as they are, and just overlay them so that they end up looking like a huge undifferentiated web (as now), but a more complex renderer will be able to ‘spot the difference’ and decide how to present a less popular route (dotted line, omit it altogether, show it all the time, add textual annotations, allow the user to filter it in/out based on day/time)

The namespace bobby444 won’t be suitable for long term use.