[OSM-dev] Proposal: Make relations ordered
Richard Fairhurst
richard at systemeD.net
Mon Mar 17 12:49:13 GMT 2008
Frederik Ramm wrote:
> In this case, the idea was that the intersection is theoretically
> unrestricted, you just want a way to describe the route the bus takes.
> Turn restrictions don't help you there. - One example people were
> mentioning is bus stops; they want to make the bus stops members of the
> relation, and they want to be able to print them out in the correct
> sequence. What they can do, today, is have the membes in the roles
> "stop01" to "stop99" and achieve ordering through that.
In 99.9% of cases that's unnecessary. If you have a bus route with
stops A, B and C:
A--------B------C
then it's blindingly obvious that the bus in the A-C direction calls
in the order A,B,C, unless someone has been taking the bus name "The
Oakham Hopper" way too literally.
(For those not aware of the Oakham Hopper:
http://uncyclopedia.org/wiki/Image:Oakhamhopper.gif )
So you just have the rare ribbon case:
|
A----B---+------C
| |
E------D
There are any number of ways you could model this without needing
ordering, whether you call it a turn restriction or not. Have a tag,
or role, on B saying "between stops A and C". Have a turn
restriction-like relation on B with scope limited to the bus route.
Or, my preferred solution, just say "sod it" because it doesn't matter
in practice. Really it doesn't. If it's a bus, there is really no
point in trying to assess bus routes without bus timetables, and the
timetable will make it perfectly clear what order the stops are in. If
it's a bike route, what I do at "+" depends entirely whether I'm
feeling too knackered to go round the loop - I can see from the map
that a loop is available.
Surely one of the unwritten guiding principles of OSM is "don't make
things complicated just to cater for a few edge cases"?
(Anyway, I should stop arguing about relations and actually finish all
the supporting code in Potlatch that'll enable me to deploy Dave's
excellent relations stuff.)
cheers
Richard
More information about the dev
mailing list