Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Am 10.02.2011 19:50, schrieb Michael von Glasow: What I am certain of is that OSM can represent public transport routes, possibly with some concessions on precision (such as not handling some route variants). Yes and no. That is, to some extent: in cities perhaps all the main lines, but not all. Not even 90% with difficult concessions. The present trend (at least in the places in Europe I've analyzed) is that line is a collection of runs, not a single path from a to b. The line itself is more and more often obscured from the user, because modern routing software (namely HAFAS in Germany) allows such management. You will not find a list of routes on the website of my transport company. All that is available is a map, but with very simplified route display. Granted, I don't live in a typical city, it's an urban nightmare, neither dense city, nor a village, rather a spread suburb, but it's not unique in Europe, and very usual in North America. Bottom line: the concept of line as known is disappearing in many places. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/10/2011 11:01 AM, Dominik Mahrer (Teddy) wrote: If I visit a bus stop by foot I can manage to map the pole/platform. So this could be level 1. But when I visit within the bus, I can only manage to map the stop position. So this would be level 1. What should be level 1 then? All you need when mapping from within the bus is the information whether the stop you've registered is on the left or on the right side of the road (or two facing stops). Then simply place a highway=bus_stop on the appropriate side of the road. Admittedly, this is less precise than visiting the place on foot, but: - when in a bus, the major source of imprecision is degradation of the GPS signal, which often introduces errors of a few meters (more than the width of the sidewalk) and dwarfs the imprecision introduced by guesstimating the distance between the way and the stop node; the location of the pole thus ends up in about the same range of imprecision as the stop position itself - if you have aerial imagery available (preferably from government sources, which tend to be more precise than Bing and the like), in many cases you can make out some features of the bus stop on the images - the shelter, road markings, a widened/narrowed sidewalk - and fine-tune your position with that - when all else fails, you can always leave a fixme tag, explaining that the position of the stop is approximate and other mappers should feel free to correct it As for defining the levels, I would define level 1 as the simplest scheme in terms of learning curve, and when in doubt, opt for the tags with the highest diffusion. So here I'd definitely go for highway=bus_stop on level 1. And I do not think we (mappers) can replace an existing public transport routing solution like hafas (too complex and too dynamic). There have been calls for this. IMO it is feasible, but as a layer on OSM, not within. Maybe, you are right. But then the next question that pops up is: Do we then need the bus routes within OSM at all? Wouldn't it make more sense to move them to this new layer? Transiki, as I have understood, aims to provide this layer on top of OSM (in fact going even further than just routes). If you're looking for the 100% solution, maybe that's the place to develop it. On the other hand, Transiki isn't there yet and I don't even know where it's going. What I am certain of is that OSM can represent public transport routes, possibly with some concessions on precision (such as not handling some route variants). Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/08/2011 09:17 PM, Dominik Mahrer (Teddy) wrote: Here we're getting into one of the uglier parts of transport mapping - large terminals (amenity=bus_station) with multiple stop positions and platforms. I deliberately left that out of the proposal I presented (my plan is to present that as a later extension). Do you have an idea how it will look like? Well, a rough one: So far we've had amenity=bus_station tagged as a node or area for the whole thing - I think this makes sense to keep. In many cases buses have a fixed platform at which they stop. Hence, we need * a node/area for each platform/boarding position * a tag which designates it as such (some candidates are already in use) * a name or ref (where one exists on the ground) Then, we need some way to associate the platforms with the bus station: * if the bus station is mapped as an area, platforms must be within the station * if the bus station is mapped as a point, take the point which is closest to the platform * as an alternative, just use a relation - then we might as well drop the extra node/area for the bus station and apply the type=amenity; amenity=bus_station tags to the relation instead; renderers could then display an icon on the centroid and/or draw the convex hull of all members Not sure about this one yet, though, especially about the third alternative. Representing the whole bus station as a relation, in combination with being able to add the bus station as a whole to a route relation (see below), would introduce nested relations, which I realize some people don't like... Finally we need a way to add bus stations to route relations: * If the bus line has a designated platform (which may also be used by other buses, but the line in question may not stop at another), and you know it, add that with role=stop. * If the bus stops at different platforms depending on the time of the day or other factors, add the whole bus station with role=stop. * If you just don't know at which platform the bus stops, add the whole bus station (like above). If you've found out the details for a bus route, replace the bus station with the platform in the route relation. If the platform is a member of the relation, there is no need to add the bus station as well - in the best case this is convenience tagging, in the worst case it may actually confuse renderers (two members for one and the same stop). Line sketch renderers should use a combination of bus station and platform name/ref, where available: Assuming name=Terminal West for the bus station and ref=D for the platform, this could be rendered as: Terminal West, Platform D (note that the string Platform would be supplied by the application itself). If the platform has no name or ref, or the relation contains the whole bus station, just use the name of the bus station (as with an ordinary bus stop). But that's still a rough idea in my mind... Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/07/2011 11:11 PM, Richard Mann wrote: On Mon, Feb 7, 2011 at 9:40 PM, Michael von Glasow mich...@vonglasow.com wrote: http://www.openstreetmap.org/browse/relation/611446 Single-direction, the first stop (Bonola) is a platform member (no stop member exists for this one); all others are stop members. Both directions rendered: http://78.46.81.38/api/sketch-line?network=SITAMref=80style=padua As far as I can tell the sketch-line ignores the highway=platform/role=platform ways. I think Bonola renders because it's a stop and a platform in the reverse direction relation: http://www.openstreetmap.org/browse/relation/611538 Ouch... you're right, that's why I added the public_transport=stop_position with the stop role, sketch-line wouldn't render the platform alone. It's been quite a while since... Here we're getting into one of the uglier parts of transport mapping - large terminals (amenity=bus_station) with multiple stop positions and platforms. I deliberately left that out of the proposal I presented (my plan is to present that as a later extension). Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Here we're getting into one of the uglier parts of transport mapping - large terminals (amenity=bus_station) with multiple stop positions and platforms. I deliberately left that out of the proposal I presented (my plan is to present that as a later extension). Do you have an idea how it will look like? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Mon, Feb 7, 2011 at 5:39 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: I did not play around with actual renderers, but in theory the renderer should be able to get the diagram out of the order of the stops, regardless of the role. If one stop is twice in the route relation it should be obvious that it has to be some kind of loop. So in theory forward_stop and backward_stop can be replaced by the role stop. In theory data users should be able to do without roles at all (though they might appreciate some help if there are a lot of direction-specific stop names), and data users should be encouraged not to depend on them. I think the simplified advice is that roles aren't required (but that if you want to make the line-diagram service work with a two-directions relation, then - for the moment - you need to do xyz). Can anyone point me to a route relation with platform stop members, so I can check how the line-diagram service works in that situation? Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/07/2011 10:45 AM, Richard Mann wrote: Can anyone point me to a route relation with platform stop members, so I can check how the line-diagram service works in that situation? http://www.openstreetmap.org/browse/relation/611446 Single-direction, the first stop (Bonola) is a platform member (no stop member exists for this one); all others are stop members. Both directions rendered: http://78.46.81.38/api/sketch-line?network=SITAMref=80style=padua Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/05/2011 06:09 PM, Richard Mann wrote: On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow mich...@vonglasow.com wrote: if I may just comment on the relation: I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) You have to use forward_stop and backward_stop if you combine the two directions in one relation, otherwise the same-named stop in the two directions don't get combined on the line diagram. You're probably right (though I haven't tried plotting spoon lines yet), when the same stop is served twice, the tool needs that information. stop works well for single-direction relations. Maybe it would be best to use forward_stop and backward_stop for the stops which are served in both directions and stop for the stops in the loop. Then again, I'm wondering whether that's too much tagging for the renderer already. Couldn't a well-written renderer look at the stop names and deduct from these the fact that the stop is the same? Or can you think of any case in which that wouldn't work? I think if you use two relations, one for each direction, it combines them regardless of role (and even if there's no role). I did a lot of experimenting to get a simple, one-relation-per-direction line to render correctly. If I remember that correctly, the stop role is required (forward_stop, backward_stop or platform will also work). The tags on the members also seem to matter (e.g. amenity=bus_station, even with the correct role, does not get rendered.) Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Sun, Feb 6, 2011 at 11:23 PM, Michael von Glasow mich...@vonglasow.com wrote: I did a lot of experimenting to get a simple, one-relation-per-direction line to render correctly. If I remember that correctly, the stop role is required (forward_stop, backward_stop or platform will also work). The tags on the members also seem to matter (e.g. amenity=bus_station, even with the correct role, does not get rendered.) http://www.openstreetmap.org/browse/relation/34631 doesn't have roles on the nodes (and it's one of the two relations used for the working example on http://78.46.81.38/public_transport.html ). ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/07/2011 12:23 AM, Michael von Glasow wrote: On 02/05/2011 06:09 PM, Richard Mann wrote: On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow mich...@vonglasow.com wrote: if I may just comment on the relation: I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) You have to use forward_stop and backward_stop if you combine the two directions in one relation, otherwise the same-named stop in the two directions don't get combined on the line diagram. You're probably right (though I haven't tried plotting spoon lines yet), when the same stop is served twice, the tool needs that information. stop works well for single-direction relations. Maybe it would be best to use forward_stop and backward_stop for the stops which are served in both directions and stop for the stops in the loop. I did not play around with actual renderers, but in theory the renderer should be able to get the diagram out of the order of the stops, regardless of the role. If one stop is twice in the route relation it should be obvious that it has to be some kind of loop. So in theory forward_stop and backward_stop can be replaced by the role stop. Or did I miss something? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow
mich...@vonglasow.com wrote:
if I may just comment on the relation: I would also use stop
rather than forward_stop and backward_stop for the roles since the
outward and return directions of a spoon route are somewhat hard to tell
apart. (Unless one stop in the loop is formally designated as the terminus
where services routinely end.)
You have to use forward_stop and backward_stop if you combine the two
directions in one relation, otherwise the same-named stop in the two
directions don't get combined on the line diagram. I think if you use
two relations, one for each direction, it combines them regardless of
role (and even if there's no role).
{I don't know what it does if there are both platform and stop nodes -
possibly puts them both in}
Richard
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On Thu, Feb 3, 2011 at 10:37 PM, Michael von Glasow mich...@vonglasow.com wrote: On 02/03/2011 12:04 PM, Richard Mann wrote: ... something else (railway=tram_station) should go on the centroid as a courtesy tag. I would in fact tend towards using public_transport=stop_position, as suggested by Dominik, given that it's already being used. I don't think public_transport=stop_position is a particularly obvious tag (except as part of a wider scheme), so I'd probably mention both and see which we can persuade people to render. I've been attempting to order a relation using P2 (I don't recommend trying it yourself yet - the process needs streamlining). I managed to sort the nodes in a two-directions-with-loops relation: http://www.openstreetmap.org/browse/relation/85299 and got a reasonable line-diagram, once I'd added forward_stop and backward_stop: http://78.46.81.38/api/sketch-route?85299 I think this confirms that line diagrams will work fine with stops beside the way. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/04/2011 12:09 PM, Richard Mann wrote: I've been attempting to order a relation using P2 (I don't recommend trying it yourself yet - the process needs streamlining). I managed to sort the nodes in a two-directions-with-loops relation: http://www.openstreetmap.org/browse/relation/85299 and got a reasonable line-diagram, once I'd added forward_stop and backward_stop: if I may just comment on the relation: I would start and end at the terminus (which seems to be The Oval) - that way the relation represents the longest way a passenger can travel (assuming services don't normally end at some point in the loop), which I think is most intuitive. I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) http://78.46.81.38/api/sketch-route?85299 I think this confirms that line diagrams will work fine with stops beside the way. In fact - as I understand it, the tool ignores ways completely and just examines stop members and their order. As far as I know, retrieving the stops of a line on openbusmap works the same way. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/03/2011 12:04 PM, Richard Mann wrote: On Thu, Feb 3, 2011 at 5:40 AM, Dominik Mahrer (Teddy)te...@teddy.ch wrote: I do not think it is a good idea to redefine thousands of used railway=tram_stop. The problem is that railway=tram_stop is used to mean a number of different things, which have different geo-locations when you start mapping in more detail. You are emphasising one particular meaning (the stop area centroid), and other people emphasise another meaning (an indicator of the boarding location). We can't know which is dominant. To ensure basic compatibility, I suggest all schemes should use nodes tagged railway=tram_stop, and make them ordered members of the route relation with role=stop (or maybe forward_stop/backward_stop). I don't think we need to be prescriptive about where those nodes are placed, just tell people there are two basic options (on track or either side of the track). I think the simplified scheme probably _recommends_ these nodes should in due course be beside the track, and possibly on platforms, and that something else (railway=tram_station) should go on the centroid as a courtesy tag. I agree that the courtesy tag probably won't hurt much if mappers decide to use that. I would in fact tend towards using public_transport=stop_position, as suggested by Dominik, given that it's already being used. (While I consider that beyond the scope of the proposal, we might still keep it in mind for a future amendment). In fact, even if we decide on placing tram stop nodes next to the way, I don't think the existing nodes will do much harm. They continue to be perfectly valid - the only information they lack is which side of the track they are on. It's the equivalent of representing a parking lot by a single point tagged amenity=parking, or one single way tagged railway=rail going into a railway terminus of 20 or 30 platforms - not incorrect but just not very detailed. I wouldn't start a cleaning binge in my area, during the course of which I move all stops - I'd probably update them on the fly when I'm editing in the surroundings anyway. However, making the position of the tram stop a recommendation (on the way is OK, but next to the way is detailed and thus preferred) sounds like a good compromise. Michael ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/27/2011 07:20 AM, Dominik Mahrer (Teddy) wrote: On 01/26/2011 08:40 PM, Michał Borsuk wrote: The bus service number 10 in Wintherthur is the most simple case you can have. Absolutely no exceptions. See timetables of the two terminal stations: So there is yet another line 10 mixed at the same index. Interesting approach taken at HaCon, indeed. Line 10 Zürich: line# relation# # of runs 10 120 56 10 121 12 10 122 12 10 123 1 10 124 50 10 125 6 10 126 1 Interesting! Indeed. How do you imagine to build routing using present, or proposed, data structures? And where do they start and end? That's beyond my point, which was to show that complication of data structures in OSM is unnecessary, because even at the level you are proposing, adding routing information won't be possible. And again: Why can't you accept, that others want to map something more in detail then you do? I don't ever remember expressing how I would like to map, because I am not speaking about my personal preferences (unlike many people here), but about what in my opinion is good for the OSM and its future. I do not understand why so many people want to turn OSM into their personal playground, and do not think about new users, for whom learning curve is important. Let's just get down to differences, I say your proposal is too difficult. I've already spoken well about its data integrity, but new users don't care about it. We need something that is as good as yours in data integrity, and as easy to grasp as my proposals. Teddych LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/27/2011 06:56 PM, ant wrote: Hi, On 27.01.2011 10:49, Richard Mann wrote: Thanks, Richard. I think we've got three broad decisions: 1) Whether the use of stop area / group relations should be a) widespread b) exceptional b b, ideally with a definition to what cases those exceptions are. 2) Whether route relations should a) contain all the variants in one relation, with no attempt at ordering, just stops identified as forward/backward b) try to match all the individual stop-sets that you might find in a timetable c) contain an ordered set of ways/stops, in whatever fashion the mapper feels appropriate b (by the way: how would (a) work in the case of a ring line?) a or b For ring or spoon-shaped lines, select an arbitrary terminus/termini. IMHO It's easier to do an exception for the occasional ring line, than enforce more difficult data structures on mappers (although I personally dislike roles, and would love to see them improved). 3) Whether there should be a new public_transport key, to try to clarify the bus_stop/tram_stop distinction a) aim to move tram_stops to alongside the track, and put something else (tram_stop_group / tram_station?) on the track b) aim to move bus_stops onto the road, and put something else (platform?) alongside c) encourage the use of platforms on tram systems, and use those in the relation instead of tram_stop d) add a new public_transport key, so that public_transport=platform can be used for everything c and d (we shouldn't redefine tags that are in million-times use!) c. with pole *or* platform. Ideally there would be some degree of compatibility between tram stops and bus stops, i.e. a pair of tags on each side that are at least compatible to a degree. cheers ant Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02.02.2011 13:04, Michał Borsuk wrote: Let's just get down to differences, I say your proposal is too difficult. I've already spoken well about its data integrity, but new users don't care about it. We need something that is as good as yours in data integrity, and as easy to grasp as my proposals. Yours is good for beginners. And yours is also good for a white area mapper. Advanced mappers are not happy with it. In an every dog shit area a mapper wants to map with a higher resolution then highway=bus_stop can provide. And an every dog shit mapper is possibly interested in mapping detailed geo-based meta information like routes. I tried to reduce my proposal to allow simpler cases. stop_area_group has been completely removed. A lot is now optional (stop_position, platform, stop_area, route_master). So it should be possible for beginners to learn step-by-step what they want/need. And one relation per direction is easier to explain then forward/backward roles. And I do not think we (mappers) can replace an existing public transport routing solution like hafas (too complex and too dynamic). The maximum possible in my opinion is to import this data into OSM. But with a single route relation solution I do not see such a solution. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/03/2011 12:40 AM, Richard Mann wrote: On Wed, Feb 2, 2011 at 11:10 PM, Michael von Glasow mich...@vonglasow.com wrote: Hence, in most cases the extra node on the way is what I call courtesy tagging - it makes things easier for the renderer (less preprocessing) but can be automated. I would tend towards manual tagging only in those cases in which heuristics are likely to produce incorrect or unpredictable results (e.g. bus stop in the middle between two carriageways). I agree - it's courtesy tagging, but since the node is already there, it seems fairly harmless to tag it with something if/when people move railway=tram_stop to a node beside the way. It doesn't introduce complexity in the way that relations do. There is already a tag for this: public_transport=stop_position. Used 27'000 times in OSM. And you are right, in many (but not all) cases it is courtesy tagging. Therefore I have changed it in my proposal to optional. I'm quite happy if people want to leave tram_stop on the track for the moment. It's not ideal in terms of pedestrian routing, but that can wait. I do not think it is a good idea to redefine thousands of used railway=tram_stop. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Hi, On 27.01.2011 10:49, Richard Mann wrote: I think we've got three broad decisions: 1) Whether the use of stop area / group relations should be a) widespread b) exceptional b 2) Whether route relations should a) contain all the variants in one relation, with no attempt at ordering, just stops identified as forward/backward b) try to match all the individual stop-sets that you might find in a timetable c) contain an ordered set of ways/stops, in whatever fashion the mapper feels appropriate b (by the way: how would (a) work in the case of a ring line?) 3) Whether there should be a new public_transport key, to try to clarify the bus_stop/tram_stop distinction a) aim to move tram_stops to alongside the track, and put something else (tram_stop_group / tram_station?) on the track b) aim to move bus_stops onto the road, and put something else (platform?) alongside c) encourage the use of platforms on tram systems, and use those in the relation instead of tram_stop d) add a new public_transport key, so that public_transport=platform can be used for everything c and d (we shouldn't redefine tags that are in million-times use!) cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Am 27.01.2011 18:56, schrieb ant: Hi, On 27.01.2011 10:49, Richard Mann wrote: I think we've got three broad decisions: 1) Whether the use of stop area / group relations should be a) widespread b) exceptional b a) possibility to micromap. 2) Whether route relations should a) contain all the variants in one relation, with no attempt at ordering, just stops identified as forward/backward b) try to match all the individual stop-sets that you might find in a timetable c) contain an ordered set of ways/stops, in whatever fashion the mapper feels appropriate b (by the way: how would (a) work in the case of a ring line?) c) with b) prefered 3) Whether there should be a new public_transport key, to try to clarify the bus_stop/tram_stop distinction a) aim to move tram_stops to alongside the track, and put something else (tram_stop_group / tram_station?) on the track b) aim to move bus_stops onto the road, and put something else (platform?) alongside c) encourage the use of platforms on tram systems, and use those in the relation instead of tram_stop d) add a new public_transport key, so that public_transport=platform can be used for everything c and d (we shouldn't redefine tags that are in million-times use!) why not use public_transport=stop_position and platform from OXAMA cheers ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Am 25.01.2011 13:52, schrieb Dominik Mahrer (Teddy): On 01/25/2011 12:01 AM, Michał Borsuk wrote: So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: ... This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). I don't know where you got these 23 routes. Here's an excerpt from the ZVV timetable for Bus 210, uptown Zürich The name ZVV doesn't ring a bell? It's Zürcher Verkehrsverbund. And the data come from this: http://www.zvv.ch/en/timetables/online-timetable.html LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 26.01.2011 09:28, Michał Borsuk wrote: Here's an excerpt from the ZVV timetable for Bus 210, uptown Zürich In Zürich / ZVV there does NOT exist a bus 210. And the data come from this: http://www.zvv.ch/en/timetables/online-timetable.html This is a form. It is no data output. What did you enter and what did you get? ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/26/2011 08:40 PM, Michał Borsuk wrote: Line 10 Winterthur: line# relation# # of runs 10 407 6 10 408 1 10 409 1 10 410 6 10 411 3 10 412 3 10 413 6 10 414 3 10 415 3 10 416 1 10 417 6 10 418 3 10 419 1 10 420 3 10 702 2 10 703 2 Voila, one line, 16 relations (unless routes 702 and 703 are yet another line 10 in another place). I wonder how many follow the same trace. The bus service number 10 in Wintherthur is the most simple case you can have. Absolutely no exceptions. See timetables of the two terminal stations: http://online.fahrplaninfo.zvv.ch/showpdf.php?pdf=pdf/21/ah_21110a/ah_21110a_j11_a_02929.pdf http://online.fahrplaninfo.zvv.ch/showpdf.php?pdf=pdf/21/ah_21110a/ah_21110a_j11_b_01826.pdf This gives exactly two relations. And the list you have created does not match bus line 10 in Winterthur at all. Not even the total number of runs is correct... Line 10 Zürich: line# relation# # of runs 10 120 56 10 121 12 10 122 12 10 123 1 10 124 50 10 125 6 10 126 1 Interesting! And where do they start and end? Here your Y line has 7 relations. Again, perhaps they follow the same path, but my general point is to show the level of complication of the data. You can make everything as complicate as you want. It is your choice. But it is not necessary. And again: Why can't you accept, that others want to map something more in detail then you do? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/25/2011 12:01 AM, Michał Borsuk wrote: So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: ... This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). I don't know where you got these 23 routes. Tram line 10 in Zürich is a Y-Line. One terminal station at one end and two alternating accessed terminal stations at the other end. Period. This gives exactly four routes (two variants in each direction). And where did you got the other 19 routes? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/24/2011 10:16 AM, Dominik Mahrer (Teddy) wrote: On 01/22/2011 08:38 PM, Michał Borsuk wrote: On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: The more exact the OSM map is, the more likely it is that the two directions do not share the same way for the both directions (the lines of one street are split up). Again, this is not an argument as OSM is not a routing software, but a map. Exactly, OSM is a map. And on a map I want to be able to read the route of a public transport service. We've exchanged arguments in this field before, let me present an actual example from your area that shows the level of complication of modern-day timetables (and Zürich actually is still quite traditional in that matter): Here's an excerpt from the ZVV timetable for Bus 210, uptown Zürich: line_nbr,route 201,557 201,558 Bus 210 consists of two routes, 557 and 558. Sounds easy, doesn't it? Route 557 would be mapped in OSM as route in one direction, and route 558 as the opposite. Indeed, it is so: route,stop_name 557,Uitikon, Wängi 557,Uitikon, Gläseren 557,Uitikon, Roracher 557,Uitikon, Dorf 557,Uitikon, Halde 557,Uitikon Waldegg, Post 557,Uitikon Waldegg, Neuhaus 557,Ringlikon, Langwis 557,Ringlikon, Dorf 557,Ringlikon, Sonnhalde 557,Uitikon Waldegg, Bahnhof ...and... 558,Uitikon Waldegg, Bahnhof 558,Uitikon Waldegg, Neuhaus 558,Uitikon Waldegg, Post 558,Uitikon, Halde 558,Uitikon, Dorf 558,Uitikon, Roracher 558,Uitikon, Gläseren 558,Uitikon, Wängi So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: line_nbr,route,nbr_or_runs 10,120,56 10,124,50 10,121,12 10,122,12 10,125,6 10,407,6 10,410,6 10,413,6 10,417,6 10,411,3 10,412,3 10,414,3 10,415,3 10,418,3 10,420,3 10,702,2 10,703,2 10,123,1 10,126,1 10,408,1 10,409,1 10,416,1 10,419,1 This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). Surely not all of them have different paths, but I guess some do. And that's just for a random line in a big city. Now take a small city: 300 thousand people spread over big area. Bus lines around me that normally consist of several relations. Most of those can be ignored, they are very early morning routes, or they follow the same path, but many do not, they are simply very different variations, 4 different paths per direction is nothing unusual over here, detours for school runs are neither (more paths!). My intention is to show to you all that times of tram/bus lines where the vehicle started at point A, drove to point B, and so throughout the day are slowly over. You won't be able to map your favourite line on OSM, unless it's as simple as the bus 201 shown above. And then what do we do with the more complicated lines? We're supposed to make a standard that would accommodate many different PT systems. So again, my suggestion is to map all variants in both direction as one relation, because we can't show the desired level of details anyway, and leave the rest to the routing layer/software/website, whatever. It is perfectly possible to combine then real timetable data with OSM, to create a multicolour maps and other eye candy. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
