You're certainly not alone. I'm mapping the _single_ bus route in my
area, but it has about a zillion variations, none of which is entirely
predictable without access to the full timetable data. This single route
is effectively a mini network all by itself.
I thought as you did, that some commonality should be enforced, with the
use of sub-relations.
E.g. you have on routes going ABCDEFG, BCDEH, CDEFK, EFGH, ABCFG, ABDEF
But how do you break things up into sub-relations ?
You could, for example, treat BCDE as a sub-relation to be incorporated
into the first two.
But then, what about the third one ? Do you have a separate
sub-relation (CDE) and does that then become a sub-sub-relation of BCDE
?
What do you do if two bus routes happen to have commonality
_by_accident_ ? If four routes have BCDE as a common section and the
road is later split to have a X segment between BC and DE, but
only two of the routes follow this new route.
I tried to do this but every time I tried to add a new bus route, I had
to split a sub relation into smaller and smaller units, giving a
three-level-hierarchy !
Then, there's the question of what to do about the stops: if the stops
are not coincident with the start/end of a way or sub-relation, what
happens when a stop is missed/duplicated when two ways/sub-relations are
bolted end-to-end ?
I really don't think sub-relations are the answer (but I wish they
were). I'd like some form of intelligent cross-checking tools so that a
person can come along and _see_ what inter-route anomalies exist.
Continuing my rant, none of the renderers seem to do sub-relations
properly. Even when they do, they seem to show both the sub-relation
_and_ the containing relation as separate routes, leading to
messy duplications.
I'd also like some means to tag a route segment (whether as a
subrelation or not) with stuff like "school journeys only", "shopping
hours only","early morning garage journeys only", for various opt-outs
and where special trips segue into the main route. I flat refuse to have
multiple separate relations for things like this, mainly because the
opt-outs are uncorrelated to each other.
Date: Sun, 1 Dec 2013 11:17:02 +0100
From: Jo <winfi...@gmail.com>
To: "Public transport/transit/shared taxi related topics"
<talk-transit@openstreetmap.org>
Subject: [Talk-transit] maintenance is very time consuming on public
transport routes
Message-ID:
<CAJ6DwMCpTWwYx__qHD7LYy0GvtFiuMdv2xrkGSG9HCaLW=o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20131
201/8891f6c0/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 01 Dec 2013 12:43:16 +0100
From: Teuxe <te...@free.fr>
Message-ID: <bed95376-bd8e-45f2-bd11-4f5d2fac9...@email.android.com>
Content-Type: text/plain; charset="utf-8"
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 <winfi...@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@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/20131
201/988c25cb/attachment-0001.html>
------------------------------
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
End of Talk-transit Digest, Vol 45, Issue 1
*******************************************
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
