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

[Jo]

I'm brooding on this for over a year now, but it's only recently that I've
started to add lots of route relations for buses and trams, complete with
all the variations.

This proposal would, of course, also make it a lot easier to add the
relations in the first place.

For the conversion, I can come up with a script to go from one way of
mapping to an other.

Once we work with subroute relations, it will also become a lot easier to
have deviations which take several months in OSM.

Shaun, if you want you can use GTFS for your purposes. This won't stop
people from adding those routes to OSM. So we need a more sensible way to
accomplish that anyway. The advantage of having it all in OSM, is that is
then all in OSM. No need to start hunting for the appropriate GTFS files
for a given region.

Polyglot


2013/12/1 Teuxe <teuxe at free.fr>

> Hi,
>
> You're certainly not alone: I was precisely thinking of such a kind of
> solution these last days.
>
> I'm usually mapping bus routes and the variants are really heavy to
> duplicate. This is also the reason why I didn't get too close yet to the
> train lines/infrastructure (which are far longer in general and can support
> many different missions - I have a life outside OSM !).
>
> It's not adding more relations in fact, it's merely adding shorter ones to
> the database instead of enormous ones, which is +1 (+10 ?) for adopting
> such scheme.
>
> Now from the point of view of using the data. I heard that the current
> hierarchical way of organizing data in public_transport scheme is already
> hard to use with queries in the database (I don't have details but you guys
> who know will surely take part of the discussion here). I suppose that
> doing cross searches with a same Relation table would be a mess? So it may
> be a harder task for rendering and for computing routes.
>
> However I'm certain that a mapper time is more precious than a CPU time,
> and we will find a method to make the process faster... I personally fully
> agree with such a logic hierarchical scheme. Thanks for having written my
> message before me, Polyglot ;)
>
> Teuxe
>
> PS. Far-related subject: does OSM use SQL-based queries? Can I find
> comparisons with "big-data NoSQL" bases somewhere?
>
>
>
> Jo <winfixit at gmail.com> a écrit :
>>
>> Hi,
>>
>> 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:
>>
>> http://www.openstreetmap.org/relation/2336780
>>
>> which is composed of several route_parts:
>>
>> http://www.openstreetmap.org/relation/2336774
>>
>> 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.
>>
>> Polyglot
>>
>> ------------------------------
>>
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
> --
> Envoyé de mon téléphone avec Kaiten Mail. Excusez la brièveté.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20131201/8422b5a5/attachment.html>