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

[Teuxe]

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/988c25cb/attachment.html>