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
On Sun, Jan 23, 2011 at 10:38 PM, Richard Mann richard.mann.westoxf...@gmail.com wrote: On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). Richard Oh, and that 48,525 of them were added in this changeset! http://www.openstreetmap.org/browse/changeset/3891683 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
I have not been able to follow the large number of posts on this group in recent weeks - but I can confirm that stopareas are an important part of NaPTAN data in the UK, and are an important aspect of the way that stops data are used in journey planning applications. It would be a pity if OSM decided they were not needed ... because they are needed by at least some USERS of the data. The definitions of stopareas need to be created by those who have a functional need for them - they are not arbitrary - but where they exist, then I suggest that OSM community should import them. Roger -Original Message- From: Richard Mann [mailto:richard.mann.westoxf...@gmail.com] Sent: 23 January 2011 22:38 To: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Summary of Public Transport Proposal Criticism On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 11:04 PM, Richard Fairhurst wrote: Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. Thanks for clarification of facts. But then I do not understand what part of the proposal is not compatible with potlatch... 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
Am 24.01.2011 10:00, schrieb Dominik Mahrer (Teddy): On 01/22/2011 11:04 PM, Richard Fairhurst wrote: Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. Thanks for clarification of facts. But then I do not understand what part of the proposal is not compatible with potlatch... I'll do that 10 second research. Will be back with the info. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 08:38 PM, Michał Borsuk wrote: On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: - stop_area is not needed/too complicated: [...]And it does not seam to be too complicated, And as for not needed: can we have a *separate discussion* on how routing works? There had already been voices that stop_area isn't really necessary, and while I don't claim to be pro in routing software, I am pretty sure we don't need them. For routing we do not need them, you are right. And we do not need them if all of the attributes are already tagged at the relations members. But you can tag the shared and identical attributes of all relations members only to the relation instead of all members (if you want). In the proposal all these tags are attributed with the sentence recommended if no public_transport=stop_area exists. So if you like, leave away the stop_area and tag all shared attributes to all nodes/ways. 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. - route directions/variants is too complicated: My opinion is: The roles forward/backward in the current tagging schema is complicated and very, very error-prone. Then let's drop them altogether. I agree with that! 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
On 01/24/2011 10:10 AM, Michał Borsuk wrote: As far as I understand the issue, stop areas are used to tie different stops into one transferring area. No, you did not understand correct. stop_area_group is (was?) for that. 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
Am 24.01.2011 10:39, schrieb Dominik Mahrer (Teddy): On 01/24/2011 10:10 AM, Michał Borsuk wrote: As far as I understand the issue, stop areas are used to tie different stops into one transferring area. No, you did not understand correct. stop_area_group is (was?) for that. Then what is the exact difference between public_transport=stop_area and amenity=bus_station (or equivalent for other vehicle types)? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Mon, Jan 24, 2011 at 9:10 AM, Michał Borsuk michal.bor...@gmail.comwrote: Am 24.01.2011 09:39, schrieb Roger Slevin: I have not been able to follow the large number of posts on this group in recent weeks - but I can confirm that stopareas are an important part of NaPTAN data in the UK, and are an important aspect of the way that stops data are used in journey planning applications. This is true, but IMHO obsolete. They are used in situations where the routing application does not possess the information on the location of stops. OSM does have that information. Such places can be calculated, instead of being entered by hand. Hi all. I've been following this debate but haven't had time to post as of yet. It seems one of the main bones of contention is that 'stop areas' can be calculated from the existing geographical data, rather than needing to be explicitly stated. I would agree with this if stop areas simply imply 'it is physically possible to interchange between these stops fairly quickly'. However, there's a possible conceptual meaning to 'stop area' which is separate from and non-inferrable from the geographical realities. To take a famous example, I don't think you'd consider Embankment and Charing Cross stations to be part of the same stop area, even though they're very close to each other? On the other hand, some stop areas (Waterloo perhaps) may be huge, even though it may take you more ten minutes to get from one stop to another (even from one tube platform to another). I don't know whether this is intended from the current proposal or not, but I think you could construct a definition of stop areas along the lines of: a collection of public transport stops, often of differing modes, which are often physically connected by short walkways, often sharing the same name, are advertised as being an interchange on public transport maps and diagrams, and may be treated as a valid interchange by fare structures. - this would seem to me to be a valid use for relations. ?? That said, I'd agree that they're often not really needed in simple cases such as two bus stops on opposite sides of the road. Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/24/2011 11:00 AM, Michał Borsuk wrote: Am 24.01.2011 10:39, schrieb Dominik Mahrer (Teddy): On 01/24/2011 10:10 AM, Michał Borsuk wrote: As far as I understand the issue, stop areas are used to tie different stops into one transferring area. No, you did not understand correct. stop_area_group is (was?) for that. By the way, I have removed stop_area_group from the proposal. Then what is the exact difference between public_transport=stop_area and amenity=bus_station (or equivalent for other vehicle types)? public_transport=station is an area usually dedicated to public transport (in contrary a simple platform or pole can be part of a/placed on a sidewalk and the bus can stop on the street without bus bay and is therefore shared with other infrastructure). A station can be a building or an area (similar to landuse) and has an exact geographic position. public_transport=stop_area contains all the attributes that are shared by all the primitives (reference, operator, network, ...). All this information has nothing to do with the geographic positioning. It is to reduce redundancy. If you prefer put the attributes to all the primitives and leave away the stop area. 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
Frankie, I think you have mentioned some good examples. For simple pairs or even small clusters of stops then a stoparea often can be defined by rules – and indeed the systems I am working with in the UK uses such rules to define an “implicit” stoparea – the rules we use are that the commonnames of the stoppoints must be identical, and for a pair of stops they must not be more than 150m apart – or for a cluster the maximum span increases to 250m. Such rules work well in our experience and reduce significantly the number of “explicit” stopareas that need to be created in NaPTAN. These rules work IF the commonname of the stop is identical. If that is not the case, then there are great dangers in assuming proximity alone will give good results – because of natural barriers or other local features that it would be difficult to ensure are understood when trying to create implicit simple stopareas. Stopareas, however, can be much more complex and involve a hierarchy of stopareas to build a complete interchange. For that to work each component stoparea needs to have an explicit reference and therefore needs to be coded explicitly in the NaPTAN data. Only then can you say that stoparea A contains stopareas B, C and D – and interchange is therefore possible between stoppoints in all those stopareas. I think the fundamental question that has not been asked – let alone answered – in the debate so far (at least in those parts of the debate that I have managed to read) is this. Does OSM want to be able to provide data which is a representation of physical reality – in other words it is only interested in stoppoints because they exist on the ground, and not stopareas because they are an abstract concept? Or does OSM want to be able to engage in more detail for public transport and provide data that can be used for functions such as journey planning – in which case it needs either explicit stoparea references throughout, or it needs rules to cover the implicit definition of most stopareas, and explicit relationships to cover those which cannot be defined by rules. If OSM only holds stoppoint data then it represents the physical geography of the situation – and that would be sufficient to allow public transport routes to be added to OSM using those stoppoint references. But as soon as you want to consider aspects of public transport network, then the data will not be sufficient at stoppoint level only. Roger From: Frankie Roberto [mailto:fran...@frankieroberto.com] Sent: 24 January 2011 10:06 To: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Summary of Public Transport Proposal Criticism On Mon, Jan 24, 2011 at 9:10 AM, Michał Borsuk michal.bor...@gmail.com wrote: Am 24.01.2011 09:39, schrieb Roger Slevin: I have not been able to follow the large number of posts on this group in recent weeks - but I can confirm that stopareas are an important part of NaPTAN data in the UK, and are an important aspect of the way that stops data are used in journey planning applications. This is true, but IMHO obsolete. They are used in situations where the routing application does not possess the information on the location of stops. OSM does have that information. Such places can be calculated, instead of being entered by hand. Hi all. I've been following this debate but haven't had time to post as of yet. It seems one of the main bones of contention is that 'stop areas' can be calculated from the existing geographical data, rather than needing to be explicitly stated. I would agree with this if stop areas simply imply 'it is physically possible to interchange between these stops fairly quickly'. However, there's a possible conceptual meaning to 'stop area' which is separate from and non-inferrable from the geographical realities. To take a famous example, I don't think you'd consider Embankment and Charing Cross stations to be part of the same stop area, even though they're very close to each other? On the other hand, some stop areas (Waterloo perhaps) may be huge, even though it may take you more ten minutes to get from one stop to another (even from one tube platform to another). I don't know whether this is intended from the current proposal or not, but I think you could construct a definition of stop areas along the lines of: a collection of public transport stops, often of differing modes, which are often physically connected by short walkways, often sharing the same name, are advertised as being an interchange on public transport maps and diagrams, and may be treated as a valid interchange by fare structures. - this would seem to me to be a valid use for relations. ?? That said, I'd agree that they're often not really needed in simple cases such as two bus stops on opposite sides of the road. Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 23.01.2011 13:18, Michał Borsuk wrote: On 01/23/2011 12:57 PM, Vincent Privat wrote: 2011/1/23 Michał Borsuk michal.bor...@gmail.com mailto:michal.bor...@gmail.com Could you please explain what you mean, because I'm not sure. The links provided show bus routes with nothing difficult in particular. They could be mapped as one relation each, only if bus stops are tagged correctly. I just want to be sure we can draw in OSM the exact same map as I gave as examples. That is possible with openbusmap.org (öpnvkarte.de), although there are reports of some minor problems. These examples show distincts ways taken by buses, depending on the direction. If it can be done for these simple lines just with a single relation and stops tagged correctly, it's fine for me. No, this can't be done in such detail, but it's not necessary as of 2011. All you need to know is where is the bus stop for the direction you're interested in, or whether the bus stop you found serves you correctly. All the rest is done by the routing software. Note that most modern public transport companies no longer publish bus routes as maps, because 1) they force you to use the routing software, 2) bus lines often vary throughout the day or week - nowadays it's impossible to draw bus lines correctly. How do you put the message on OSM that bus passes here on Sunday morning? I'm sorry, but saying it is not necessary seems very arrogant to me. Maybe it is not necessary for what you want to use OSM for, but that doesn't mean that we can't use it for something else. Last time I checked, OSM was open and everybody was able to map whatever they wanted. Thinking about the 100+ messages about this topic, this might actually be the reason for the problems in finding a good proposal. You have an idea of what you want to do with the data and you think that everybody else wants to do the same stuff. That's not the case! People will want to use the data in different ways and that is fine, so what we need is a public transport proposal that allows everybody to map whatever they want to map. That includes people like you who only want the bus stops, but it also includes people like Vincent or me who would like to map also physical path a bus takes on the street. Christian ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Mon, Jan 24, 2011 at 11:40 AM, Christian christ...@balticfinance.com wrote: but it also includes people ... who would like to map also physical path a bus takes on the street. I think there's a logic in encouraging the use of ordered relations to show the paths of bus/etc routes - because this makes the data more browsable/maintainable. I think there's also a logic in putting branches in separate relations, for the same reason. If there are lots of branches that share a ref (or don't have refs), it's probably easier however to leave them bundled together. You'd hope that data users might make reasonable sense of data with errors/gaps in it, but it's good to harness the mapper's ability to look at maps/diagrams, spot the error and fix it. So I'd go for a little more order than Michal is proposing, but I'd agree that we need to keep it as simple as we can, with the advanced stuff used strictly only when necessary, and only to the extent that is necessary. On the general issue of when to use stop areas - if the raw distance is sometimes inappropriate, then we should mark these as exceptions, not mark everything. You don't even really need to group all the objects on either side of the barrier, as long as there are different names (+?network) on each side of the barrier - simply link one object on each side, and let the data user join up the rest using the name tag. So for instance, there might be a relation linking the Charing Cross station node to the Embankment station node, giving a minimum walking time. Contrariwise, you might have another relation linking Bank and Monument, advising that a penalty for going via surface level is inappropriate. (With apologies to those of you unfamiliar with the intricacies of the London Underground) 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
On 01/24/2011 12:40 PM, Christian wrote: On 23.01.2011 13:18, Michał Borsuk wrote: No, this can't be done in such detail, but it's not necessary as of 2011. All you need to know is where is the bus stop for the direction you're interested in, or whether the bus stop you found serves you correctly. All the rest is done by the routing software. [...] I'm sorry, but saying it is not necessary seems very arrogant to me. Maybe it is not necessary for what you want to use OSM for, but that doesn't mean that we can't use it for something else. Last time I checked, OSM was open and everybody was able to map whatever they wanted. Not at all. Nowhere it is written that anarchy is encouraged. If it were, I would have already applied what *I* think is proper, instead of finding a common solution. If disagree then please attack my arguments with counter-arguments. I stand by what I wrote. Thinking about the 100+ messages about this topic, this might actually be the reason for the problems in finding a good proposal. You have an idea of what you want to do with the data and you think that everybody else wants to do the same stuff. That's not the case! I am aware of this. Sometimes the minority is correct. People will want to use the data in different ways and that is fine, so what we need is a public transport proposal that allows everybody to map whatever they want to map. That includes people like you who only want the bus stops, but it also includes people like Vincent or me who would like to map also physical path a bus takes on the street. My proposal does cover that. A simple bus line will be mapped as it was before, with the minor exception that the route will not contain the direction (you don't need that as a user) - but the stops will. 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
On 01/24/2011 02:09 PM, Richard Mann wrote: On Mon, Jan 24, 2011 at 11:40 AM, Christianchrist...@balticfinance.com wrote: but it also includes people ... who would like to map also physical path a bus takes on the street. I think there's a logic in encouraging the use of ordered relations to show the paths of bus/etc routes - because this makes the data more browsable/maintainable. Nobody denies that. The problem since the beginning is the cost, i.e. the amount of time needed to implement and maintain this solution. 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
On 01/24/2011 12:40 PM, Christian wrote: On 23.01.2011 13:18, Michał Borsuk wrote: No, this can't be done in such detail, but it's not necessary as of 2011. All you need to know is where is the bus stop for the direction you're interested in, or whether the bus stop you found serves you correctly. All the rest is done by the routing software. [...] I'm sorry, but saying it is not necessary seems very arrogant to me. Maybe it is not necessary for what you want to use OSM for, but that doesn't mean that we can't use it for something else. Last time I checked, OSM was open and everybody was able to map whatever they wanted. Not at all. Nowhere it is written that anarchy is encouraged. If it were, I would have already applied what *I* think is proper, instead of finding a common solution. If disagree then please attack my arguments with counter-arguments. I stand by what I wrote. Well, I could agree with you that your proposal is fine for most usage cases. But below you say it yourself, the direction is lost, so for all those usage cases where people would like the direction your proposal isn't working. Thinking about the 100+ messages about this topic, this might actually be the reason for the problems in finding a good proposal. You have an idea of what you want to do with the data and you think that everybody else wants to do the same stuff. That's not the case! I am aware of this. Sometimes the minority is correct. I'm not sure if there is a right or wrong here. Its just different ways to use the data. People will want to use the data in different ways and that is fine, so what we need is a public transport proposal that allows everybody to map whatever they want to map. That includes people like you who only want the bus stops, but it also includes people like Vincent or me who would like to map also physical path a bus takes on the street. My proposal does cover that. A simple bus line will be mapped as it was before, with the minor exception that the route will not contain the direction (you don't need that as a user) - but the stops will. I have to read your proposal again, maybe I missed something. I thought your proposal wouldn't allow me to see the exact roads a bus travels on between two stops. If that is the case and the road between two stops is known with your proposal, just not the direction, how about changing/amending your proposal to add an *optional* argument or maybe a relation somewhere to store the direction? If someone wants the direction (for whatever reason) they could still be 100% compatible with your proposal but do some extra work and also get the direction - which only makes sense when the roads are different depending on the direction. Christian ___ 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
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/25/2011 12:19 AM, Michał Borsuk wrote: On 01/24/2011 11:38 PM, Christian Krützfeldt wrote: If disagree then please attack my arguments with counter-arguments. I stand by what I wrote. Well, I could agree with you that your proposal is fine for most usage cases. But below you say it yourself, the direction is lost, so for all those usage cases where people would like the direction your proposal isn't working. Graphically lost, so no arrows (that didn't work anyway, because there are streets in which bus A runs one-way north, bus B runs one-way south, and openbusmap.org could not render this). This is what I mean http://www.openbusmap.org/?lat=49.26791lon=7.10739zoom=16layers=BT http://www.openbusmap.org/?lat=49.24427lon=7.14187zoom=17layers=BT Buses 521, 522, and 525,526 respectively, each run in one direction, but the opposite one, and openbusmap.org is lost. 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
On 01/24/2011 11:22 AM, Dominik Mahrer (Teddy) wrote: By the way, I have removed stop_area_group from the proposal. In essence this is good. I tried to implement this concept in OSM, but could not find (come up with) a sensible standard. Then what is the exact difference between public_transport=stop_area and amenity=bus_station (or equivalent for other vehicle types)? public_transport=station is an area usually dedicated to public transport [...] public_transport=stop_area contains all the attributes that are shared by all the primitives (reference, operator, network, ...). I do see this advantage here, but again, this is something demanding for humans that is not required by routing software. And frankly I do not see such an improvement in data consistency over amenity=bus_station (or equivalents for other vehicles). Rather I'd see questions to which is which. Smaller stop areas could be left as poles/platforms, larger ones naturally constitute a type structure. Perhaps the name bus station does not have to be applied to 4 platforms on the side of a Stadtbahn stop, but that's intuitive to users (if not, we can hint them). 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
On 01/24/2011 11:06 AM, Frankie Roberto wrote: [...] I don't think you'd consider Embankment and Charing Cross stations to be part of the same stop area, even though they're very close to each other? On the other hand, some stop areas (Waterloo perhaps) may be huge, even though it may take you more ten minutes to get from one stop to another (even from one tube platform to another). I don't exactly remember Charing Cross area, but I know where you're going with it. I actually see an advantage of OSM over traditional routing software. I have been sent by HAFAS (THE German routing application) from one bus stop to another very close one, but across a stream. The app simply calculates distances in a straight line. OSM, on the other hand, does have all the information: foot passages, bridges, etc. Again, let's leave to the software what is relatively easily calculated. And if a connection is too difficult (Charing Cross-Embankment above), it can be added to the connections cache. Such caches (static tables) are present in all major routing apps, so again, nothing new here. And much less work. I don't know whether this is intended from the current proposal or not, but I think you could construct a definition of stop areas along the lines of: a collection of public transport stops, often of differing modes, which are often physically connected by short walkways, often sharing the same name, are advertised as being an interchange on public transport maps and diagrams, and may be treated as a valid interchange by fare structures. I must disagree, see above. 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
On Tuesday, January 25, 2011 at 00:23 CET, Michal Borsuk michal.bor...@gmail.com wrote: On 01/25/2011 12:19 AM, Michal Borsuk wrote: Graphically lost, so no arrows (that didn't work anyway, because there are streets in which bus A runs one-way north, bus B runs one-way south, and openbusmap.org could not render this). This is what I mean http://www.openbusmap.org/?lat=49.26791lon=7.10739zoom=16layers=BT http://www.openbusmap.org/?lat=49.24427lon=7.14187zoom=17layers=BT Buses 521, 522, and 525,526 respectively, each run in one direction, but the opposite one, and openbusmap.org is lost. It's clear what you mean, but not addressing the directional issue because one renderer of public transportation can't cope with a particular corner case doesn't make sense. I agree that the direction in most cases can be inferred from the stops, but I'd guess ambiguous corner cases aren't too infrequent. Also, it doesn't necessarily mean we should place this burden on all renderers (who otherwise don't have to analyze the relations and draw conclusions). Placing an extra tagging complexity load on all mappers is of course also undesirable. -- Magnus Bäck ba...@swipnet.se ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 10:00 PM, Vincent Privat wrote: 2011/1/22 Michał Borsuk michal.bor...@gmail.com mailto:michal.bor...@gmail.com In urban regions it is common that a bus line has different routes for the both directions (often one way). This doesn't matter as OSM itself is not routing software. 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. And as a map, we need to make the distinction between different ways, Different directions, you mean? No, we don't. We need unique bus stops in order to know in which direction the bus goes. I agree we can remove the stop_area_group notion, but not this one, this is really a needed map feature, for a very common situation ! Could you please explain what you mean, because I'm not sure. The links provided show bus routes with nothing difficult in particular. They could be mapped as one relation each, only if bus stops are tagged correctly. 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
2011/1/23 Michał Borsuk michal.bor...@gmail.com Could you please explain what you mean, because I'm not sure. The links provided show bus routes with nothing difficult in particular. They could be mapped as one relation each, only if bus stops are tagged correctly. I just want to be sure we can draw in OSM the exact same map as I gave as examples. These examples show distincts ways taken by buses, depending on the direction. If it can be done for these simple lines just with a single relation and stops tagged correctly, it's fine for me. However, I still have doubts concerning this line, which is the most complex in my city: http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf I don't see how we can map this without at least 2 relations, where the line splits up in the two directions Sept Deniers and Stade E. Wallon. And about the night extension to the SNCF railway station, I think we'd need a distinct relation as this line is called 16S instead of 16. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 11:04 PM, Richard Fairhurst wrote: Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. It was me who said it, and I stand by the general comment. While Potlatch 2 may indeed deal with nested relations, the proposed schema is not compatible with it. 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
On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). 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
Thanks Michal for your explanations, this is greatly appreciated :) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Summary of Public Transport Proposal Criticism
I try to seperate the criticism from the spam around my proposal: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). For me this is a reasonable number and we can't say it is only a minority of eccentric mappers. It is a widely used tagging schema, badly with several flavors. And it does not seam to be too complicated, otherwise it would not be that much. - stop_area_group is not needed: I am about to change my mind here. stop_area_group was introduced by oxomoa nearly two years ago. And there are less then 500 usages, not a reasonable number. I also see that the routing is better done with the existing ways of OSM, so for routing it is usually not needed (like I thought). I would like to introduce an unofficial vote on this list if I should remove stop_area_group from the proposal. Please answer to this mail with stop_area_group: keep if I should keep it or stop_area_group: remove if I should remove the section stop_area_group from the proposal. - route directions/variants is not needed: In urban regions it is common that a bus line has different routes for the both directions (often one way). 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). Out in the country where often both directions share the same way for the whole part and perhaps not all bus stops are mapped the two directions are only the reversed of the corresponding other. It is correct, then it does not make sense to add two relations. But this proposal does not obsolete the already known tagging schema with only one relation. Why not using this then? - route directions/variants is too complicated: My opinion is: The roles forward/backward in the current tagging schema is complicated and very, very error-prone. In my region nearly all routes tagged with roles have errors. Reasons: reversed ways or forward/backward was not understood correctly and has been tagged as the direction of the bus instead of the way. - route_master is not needed: If all the information is tagged at the variants/directions it is not really needed, this is correct. I thought it is clearly described in the proposal that you can skip the route_master if you think it is not needed. Even if this would not explicitly been written you are free to leave away unneeded things, this is OSM. IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: Nested relations is a basic API function. And it is used also for other schemas then for public transport (e.g. commonly used for borders). Each of the three editors have their advantages and disadvantages. None of the editor is the reference implementation. The reference is the API. If potlatch should be an editor for everything, the authors of potlatch should see it as an obligation to implement support for nested relations (even if this proposal is not approved). 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
On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: I try to seperate the criticism from the spam around my proposal: - stop_area is not needed/too complicated: [...]And it does not seam to be too complicated, We have so many advanced issues in comparison to the total number of PT objects because we have a pitiful total number of PT objects on the map. If we keep, or even increase, the level of complication, then the map will not gain new mappers. And as for not needed: can we have a *separate discussion* on how routing works? There had already been voices that stop_area isn't really necessary, and while I don't claim to be pro in routing software, I am pretty sure we don't need them. I could elaborate, but not in this thread. The problem is our admin is overwhelmed, and seemingly doesn't past new threads. So why keep something that is essentially neither part of the map (map shows location of objects, not their relation), nor part of the routing algorithm? - route directions/variants is not needed: In urban regions it is common that a bus line has different routes for the both directions (often one way). This doesn't matter as OSM itself is not routing software. While coming up with an alternative I actually realized that roles are only needed on bus stops (in HAFAS system, and not at all in most North American systems), in order to make two bus stops with the same stop_id unique. 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. - route directions/variants is too complicated: My opinion is: The roles forward/backward in the current tagging schema is complicated and very, very error-prone. Then let's drop them altogether. One relation for one timetable route, no matter how complicated it is. The rest will be (and can be) dealt with by the middle layer of software that will hopefully eventually deal with routing. Each of the three editors have their advantages and disadvantages. None of the editor is the reference implementation. The reference is the API. The real reference is the use of editors. You can't simply produce something, and then count/expect that it will be implemented. That way you will create a beautiful piece of law, with horrible usability. If potlatch should be an editor for everything,the authors of potlatch should see it as an obligation to implement support for nested relations What authors of Potlatch should see is immaterial here. We are their slaves, because Potlatch is used by entry-level users, who hopefully would do a large part of the work that is now done by pros, leaving the pros to do things that beginners cannot, or should not do. Surely we do not have to shape the proposal towards 100% Potlatch compatibility, but let's finally talk about what is entry-level stuff, and what is not. I propose that the creation of bus, tram, trolleybus and S-Bahn/stadtbahn lines be considered entry-level, and so be the creation of bus stops. 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
2011/1/22 Michał Borsuk michal.bor...@gmail.com In urban regions it is common that a bus line has different routes for the both directions (often one way). This doesn't matter as OSM itself is not routing software. 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. And as a map, we need to make the distinction between different ways, so the argument is perfectly valid. How would you draw these example maps without this notion ? http://tisseo.fr/sites/default/files/Tisseo_hiv01web.pdf http://tisseo.fr/sites/default/files/Tisseo_hiv03web_0.pdf http://tisseo.fr/sites/default/files/Tisseo_hiv14web.pdf http://tisseo.fr/sites/default/files/Tisseo_hiv15web_0.pdf http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf I agree we can remove the stop_area_group notion, but not this one, this is really a needed map feature, for a very common situation ! ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
