Improve the editing of bus routes at bus stop

[nlehuby]

Hi,

I would like to ease the action of telling that some bus route stops at a bus stop.
The UI should look like this :

• a semi combo field in the bus stop preset
• the field would be filled by existing bus route relations (using graph.parentRelations function)
• the autocomplete should propose the nearby bus route relations (maybe using the existing ui component ?)
• for the added bus routes, the bus_stop should be added as a member (using the relation addMember function)

What do you think ?

[bhousel]

This would be really complicated to do. I like the idea behind the UI, but almost all of the fields in iD (including the semicombos) are direct mapping between the UI and the tags, not relation memberships, so this would be a very different kind of field from how the semi combo fields works now.

It would be almost like the turn restrictions field, creating and removing relation memberships. So if we want to make a special route mapping field, we should think more about what's possible to do with a completely new kind of field, rather than repurposing the semi combo to do route memberships (which it really can't do).

[PanierAvide]

@bhousel How much time do you think would be necessary to create this new kind of field ?

[bhousel]

How much time do you think would be necessary to create this new kind of field ?

I don't know, sorry!

[slhh]

We need to address the real problems of adding a stop to a bus route here:

• place the stop at the correct position in the relation according to the itinerary.
• allow identification of the correct route relation. Variants (e.g. an express service) might share the same network, linenumber, and destination.

[nlehuby]

Ordering the stops within the route is a whole different topic. When you are at the stop, or have some photo of the stop, you may not know how to place the stop within the route, you need to analyse the whole trace to find out.
By the way, iD already allows to add a bus_stop to a route, without handling this.

Yes, you are right, variants may share the same network, number and destination (in fact, they may even share all their tags)
It seems to me that we don't have so many variants with the same tags, and we may deal with it : dealing with 80% of the cases would be better than dealing with none, don't you think ?

[PanierAvide]

+1 There are so many bus networks around, and only a few have bus lines with multiple variants/destinations. Think of all small networks having only less than 5 bus lines with very simple routes.

[slhh]

@nlehuby

Ordering the stops within the route is a whole different topic.
Not really, and at least not with the currrent public transport data model.

• A typical user, who is contributing his local knowledge by adding the bus_stop to a route, does quite likely have some knowledge of the sequence of stops. ID should encourage the user to also contribute this valuable information.
• The currrent public transport data model does not allow for adding a stop to the route without adding sequence information, and adding potentially wrong information purely based on editor heuristics is not nice.

When you are at the stop, or have some photo of the stop, you may not know how to place the stop within the route,

This usecase seems to be more typical for advanced users surveying an unknown region, who might prefer JOSM anyway, but I agree it is a relevant usecase. We should support this, but we need to amend the data model.

you need to analyse the whole trace to find out.

This seems to require advanced users and a big amount of loaded data.
In order to fit the requirements of iD's architecture and typical users, we likely need to invent a more local approch to get the sequence arranged.

[slhh]

It seems to me that we don't have so many variants with the same tags,

How many variants exist depends on the habits of the operator, and there are likely strong regional differences. In addition there are strong regional differences how complete all existing variants are mapped. Following the rule of the public transport proposal strictly would often generate an awful quantity of variants to be mapped. An extreme case is where the operator lets the bus switch to a different route at the end station without forcing passengers to leave the bus. The proposal requires a separate variant relation for such a combination.

and we may deal with it : dealing with 80% of the cases would be better than dealing with none, don't you think ?

Even if these were the only options, I wouldn't be be sure because it might led to damaging the remaining misleading 20% of the cases.

We should just target the 100% of the cases in the following way:
List the bus routes as proposed, but unfolded additional information for identification of the relation on click, e.g. "from", "via", "description", or "note" tags, or in the worst case the relation id. We might limit the shown information to the subset which is sufficient to identify the route relation uniquely.

[nlehuby]

Can we imagine an intermediate version of this whole feature?

Today, you can already add lines info on bus stop.
You can click on the "+" button under the "all relations", and search for relations.

But you get any relations (even boundaries, or bus route_master that does not make sense for a bus stop).
If the name of the bus route is long, you only see the beginning, which may be confusing.

For instance, if I'm looking for the RATP bus, number 117, towards "Champigny Saint-Maur RER". The correct one here is the second one in the list.

We could have an improved version of this feature by

• filtering the relations types to let the user select only bus routes
• use ref, network and to tags to have a shorter and usable way to select the bus route, and maybe even allow auto-complete relations on network
• automatically add a stop or platform role

We still cannot specify the order, or use other tags to choose between all the variants of the line, but we improve the user experience on this topic.
What do you think ?

[1ec5]

If the name of the bus route is long, you only see the beginning, which may be confusing.

#4694 adds a tooltip that displays the name in full.

filtering the relations types to let the user select only bus routes

For roads along the route, iD couldn’t filter the list automatically, since a given road can legitimately belong to other kinds of routes and also some non-route relations (such as turn restrictions). So it would have to be an explicit button or something. I’m not sure of an elegant way to fit that into the current UI.

On the other hand, this might work for bus stops and stop positions. At least we could ensure that the bus route relations appear first in the list.

use ref, network and to tags to have a shorter and usable way to select the bus route, and maybe even allow auto-complete relations on network

Relatedly, #3622 would keep a relation in the list even after it goes out of view. This can be handy if you know of some bus stops along the route but not the exact path of the entire route.

automatically add a stop or platform role

#4695 broadens this idea to more situations where iD could helpfully set the correct role, so the user doesn’t always have to remember to set it.

[slhh]

For roads along the route, iD couldn’t filter the list automatically, since a given road can legitimately belong to other kinds of routes and also some non-route relations (such as turn restrictions).

+1. Also stop and platforms can belong to stop_areas. Maybe, a stop position can be a via member of a turn restriction, a platform way or area might belong to a pultipolygon, etc.

So it would have to be an explicit button or something. I’m not sure of an elegant way to fit that into the current UI.

For some specific features (like stops and platform) split the all relations section into multiple parts, special-purpose ones and a other relations one. Each section would have its own add button.
For example a bus stop we could have the sections:

• bus routes
• stop areas
• other relations

If there is also a tram=yes tag, we can either add a tram routes section or use a common public transports route section, which might be called "bus/tram routes", and routes can be filtered accordingly to bus and tram only.

Where required, each special purpose section can have a special behaviour, for example controls to put a stop in the correct position in the member sequence.

Maybe, we can later move the display of such special purpose sections by CSS into frames generated by fields. This would encourage users even more to add routes etc.