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
explicitly.
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.
Michael
_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit
