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

[Jo]

Hmm, I was thinking of staying more or less within the lines of what we
have now, but take away the burden of 10, 20, 70 relations on the same
piece of road. Those sub relations could describe how to get from one stop
to the next, or describe the common parts of how buses get from A to J with
several stops in between. Nesting the subroutes/route_parts more than once
sounds tempting...

I don't see it as a coincidence that different lines would also be able to
'reuse' those same subroutes. In fact, that's the whole idea.

I would keep the stops in the top level route relations, so the route_parts
only contain ways.

Does it make sense for me to elaborate on this and invest time into an
actual proposal?

Polyglot


2013/12/1 Erik Johansson <emj at kth.se>

> On Sun, Dec 1, 2013 at 1:09 PM, Shaun McDonald
> <shaun at shaunmcdonald.me.uk> wrote:
> > Which is why I believe that it’s better to use GTFS data, and auto snap
> the
> > GTFS data to the OSM data. There then needs to be some hints in the OSM
> data
> > as to which roads buses do and don’t or shouldn’t run on. Bus routes also
> > change far more frequently than fixed infrastructure or cycle or walking
> > routes, hence why I think a different way to deal with the data is
> > appropriate.
>
> +1
>
> But there are several places around here where busses won't take the
> direct route (not sure why), so autosnapping wont work but if you can
> add virtual stops on the way that would work...
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20131201/f6ee7f60/attachment.html>