[Talk-transit] maintenance is very time consuming on public transport routes

Jo winfixit at gmail.com
Sun Dec 1 10:17:02 UTC 2013


This subject has come up here and there already. I'm in the process of
adding public transport routes for all the buses and trams in my region.

- each variation of a route gets its own route relation
- at times there are 40 variations
- on average 2-6
- buses tend to use the same ways for several routes, which is logical as
that' s where the stops are.

This means that there are main roads with up to 70 bus routes on them.

If somebody wants to split that into 2 oneways, it's a lot of work to fix
all those route relations.

There is an easy solution to this problem: work hierarchically

routes should be allowed to contain subroutes

This is already done for some foot/hiking routes.

An example:


which is composed of several route_parts:


These route parts can then also be used for other routes which also use
that same asphalt (I didn' t do that in the example).

When somebody splits/recombines a way, there are 2 route_part relations to
fix and all the parents that depend on stay correct automatically.

It's necessary, of course, that the routes still get rendered when divided
into subroutes like that, otherwise it' s quite useless.

Does it make sense to make a proposal for this on the wiki, or will it be
shot down immediately? I've been giving this a lot of thought and I see
we're about to hit a brick wall. What I don't understand is that I seem to
be the only one who sees it this way. Yes, I hear people complain about the
multitude of relations every once in a while, but I don't ever see anyone
propose a solution.

It may seem more complicated this way, but it isn't really. It may also
seem like adding yet more relations, but there will be less relations on
the actual ways.

Maintenance of the route relations the way they are now, is an incredible
waste of time. Time that could be spent in a more productive way. Either
for the project or IRL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20131201/8891f6c0/attachment.html>

More information about the Talk-transit mailing list