[Talk-transit] Proposed Feature - RFC - Public Transport

Michael von Glasow michael at vonglasow.com
Thu Dec 9 23:08:18 GMT 2010

On 12/09/2010 06:35 AM, Dominik Mahrer (Teddy) wrote:
> Hi Michael
>> In the new proposal I am missing some details on how to build relations:
>> 1. Should the outward and return trip be represented as two separate
>> relations, as a single relation or is that up to the mapper?
> Each direction should be in a separate relation. This is written in 
> the proposal. Both directions/variants should be member of a master 
> relation.
you're right, I overlooked that. I already use separate relations for 
each direction so I agree on that unless we find a convenient way of 
reducing the number of relation needed. I don't use master relations - 
in most cases, the relations of a single line are sufficiently 
identified by their ref and network. There may be exceptions, though: 
the network name is not guaranteed to be unique, and in that case it may 
be difficult to separate two lines with the same network names which in 
fact belong to different networks. Plus, here in Milan line variants are 
often (not always) indicated by adding a slash. For instance, line 42/ 
may mostly follow line 42 but serve some extra stops not served by 42 
(and, in some cases, skipping the last stops of 42).
>> 2. Which members should the relation contain, and in which order?
> You are not the first with this question, so I added some explanations 
> to the proposal:
> First the stop_positions ordered (with role stop), then platforms 
> ordered (with role platform) and then the ways ordered (without role).
>> 3. Which data primitive should be added for stops?
> Stop positions AND platform. Stop position is important for the route 
> itself, the platform is important for pedestrian routing.
Fine for me, though it does mean some more effort to enter data. Except 
that we might consider adding the platform right after the stop it 
belongs to - that would make it easier to verify that both are there.
>> 4. How are line variants mapped?
> Problem 1:
> A - B1/B2 - C - D - E1/E2 - F
> In morning and evening hours the bus stops at B2 instead of B1.
> During school holiday the bus stops at E2 instead of E1.
> This gives us four possibilities really used.
> When you add alt-roles to a stop you can't say when is what route 
> used. So this does not work, we need really four relations.
Yes, this is a more complex variant of my market example (yours is the 
equivalent of two markets, say, one on Monday and Wednesday and the 
other on Wednesday and Friday). As I mentioned in my post, I have no 
feasible solution for mapping this in a single relation.
> Problem 2:
> What do you want to say with role forward/backward? Forward/backward 
> compared to what? To the route direction or to the tagged way 
> direction? Actually both is used in the OSM database and no one knows 
> how to interpret it. Role forward and backward is in my eyes a nice 
> try to solve a problem. But it confused more then it solved. We should 
> leave this away.
As far as I know, this is accurately defined: it is relative to the 
tagged way direction, which may or may correspond to the route 
direction. But I, too, realize that this part confuses people. If we 
agree that ways must always be sorted, each way sharing an end node with 
the ones before and after (which I strongly recommend), then we can 
extract this information from the route itself without tagging it 
> Practical:
> I map the variant with the most stops (in your example twice A B1 E1 
> K. In JOSM you can easily copy a relation and change what is 
> different. So to handle your 8 variants should not take 8 times 
> mapping one variant.
That works when you have the entire route from beginning to end. But 
some of us (I do) often follow just a part of the way and enter that, 
hoping to complete it at a later occasion (or someone else doing it). 
And once you have two partially-complete relations, updating them both 
together mostly means editing each relation manually.
> I personally leave away the very special cases (ex. first course 
> starts at B instead of A). This is only relevant when timetable 
> information is added to.
For some applications, namely public transport maps and route sketches, 
this information might still be useful. For instance, those parts of the 
route which are omitted by some courses could be represented as a dashed 
line, the rest being drawn as a solid line.


More information about the Talk-transit mailing list