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] Bus/Tram/Metro paths export
Hi, On 27.01.2011 11:31, Tiziano D'Angelo wrote: Hello, after doing so much work onto bus/tram relations in my city Padova, I'd like now to extract some geographically exact paths of single routes from OSM database, possibly in SVG format, and use them on a Padova-PT website I am going to build soon. Most of you are probably familiar with http://78.46.81.38/public_transport.html , and I can already obtain sketches of the routes, but my aim is to obtain something with this output: http://upload.wikimedia.org/wikipedia/commons/9/9b/Ligne_4.gif for just a single line like in the example, or also with more lines (selecting for example all evening lines, or all Sunday lines). In this case, for a simpler rendering of everything, the stops aside the way should be coupled together if they have the same name (as in OPNVKarte) and the corresponding dot should be part of the drawn route. I do not have extendend programming skills, therefore I don't know how to obtain it, can somebody help? If you want to work with OpenLayers, you can simply create GPX files from the routes you want to draw (there are GPX export functions in JOSM and Merkaartor). Then you'll need a list of stops and their positions. To couple stops together, you could search stops that share the same name and find the intersection of the line connecting the two poles with the track you are drawing. Finally you need to draw the labels. OpenLayers should support that, but I haven't used this feature yet. Hope this helps. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public Transport Line Diagram
Hi, On 26.01.2011 09:20, Michał Borsuk wrote: That's a mess! 1. Tram lines are normally represented by a single line on the map, not one line per track That's no problem, but if you do it that way, put tram stop nodes on each track. Better yet, add the platforms besides the tracks (Poznan has Bing imagery, doesn't it?) 2. Each route is represented by relation[s], so this http://www.openstreetmap.org/browse/node/175610061 is completely wrong What's wrong with that? 3. Tram stops have the wrong tags Yes, should be railway=tram_stop cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 23.01.2011 15:01, Michał Borsuk wrote: Any updates from the wiki front? I have started something: http://wiki.openstreetmap.org/wiki/WikiProject_Cleanup/Public_transport I'll need your help with this, so feel free to edit and discuss. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 15.01.2011 14:46, Michał Borsuk wrote: Yes! I've been raising this issue here, it may have died among other arguments: An overhaul and update of the documentation is more important than pushing the new schema. Do you have the resources to lead this project of cleaning the mess with wiki pages? I can help, but I can't supervise at this moment. Hopefully! Yes, I'll dig into the depths of the wiki and let you know. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Hi, On 15.01.2011 02:20, David Peek wrote: ...Also, it is quite unlikely that a stop is served in only one direction whereas the road it resides on is used in both. For stops that are situated at a segment that is served only in one direction, it is clear in what direction the stop is used, isn't it.. Actually, this is not unlikely at all. All you need is an uneven spacing of bus stops on each side of the road, if only one node is marked for a stop on either side of the road. Yes, you're right, it is not that unlikely. But still, these role definitions are obsolete, because it has become common practice to put bus stops beside the road. If paired bus stops are marked separately on each side of the road - which seems to be the standard - only one is served in each direction, even if the road is used in both directions, so the reverse of your point appears to be true... In that case the definition given in the wiki doesn't apply any more, because, according to it, the choice of role explicitly depends on the way a node is part of. (Weak point by the way: which role is the right one for a stop node that is part of two ways having different orientations?) If I've misunderstood what you meant, my apologies. I hope this discussion actually gets somewhere useful - I'm getting annoyed at the amount of what I'm increasingly regarding as spam arriving in my inbox. Should we move the discussion to the proposal's talk page? cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 14.01.2011 21:28, Michał Borsuk wrote: I will elaborate on the complexity of timetable datasets, with actual examples, if time permits. One question here, are you developing this software as an academic assignment? If so, in which journal would you like to publish? Are you addressing me? I'm not developing anything related to public transport at the moment. But I'm thinking about it and I'm also waiting for transiki to reach a stage that might allow integration of timetables. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 14.01.2011 21:13, Michał Borsuk wrote: 3. lack of the need in the majority of cases (other cases: roles should be enough*) See my other posts. Frankly not sure which one. Do you care to summarize what you mean? I had my posting from 18:53 CET in mind, it's about getting a platform's direction and why things get complicated when single relations are used. It leads me to the conclusion that the extensive usage of roles is hardly avoidable, even in simple cases. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Sorry for flooding this list. On 14.01.2011 13:30, Michał Borsuk wrote: What's wrong with multiple, non-nested relations? - I'm not saying we need a route master. 1. weak point in case of rerouting: a beginner may move only one route; more work How often does a PT route get rerouted compared to shops shutting down and popping up? 2. lack of the option to duplicate a route in the entry-level software Until this gets fixed, mappers will spend twice the time. That is bad, but a software that is considered entry-level needs not support the more complicated standards. Compare Notepad and MS Word. 3. lack of the need in the majority of cases (other cases: roles should be enough*) See my other posts. 4. incompatibility with present mapping standards, I mean printed maps -> two routes per line may seem strange to beginners If you're talking about printed map standards - they aren't really comparable to OSM and its richness of detail. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 14.01.2011 14:29, Richard Mann wrote: I think one relation for both directions is reasonably achievable and simple (assuming P2 will allow a way to be a member at two positions in the ordered list). This will allow many routes to be one service / one relation. Relations that don't work if they aren't ordered correctly won't ever work. Really, no one cares about relation ordering, and everybody is going to mess it up. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 14.01.2011 14:29, Richard Mann wrote: If I were ever to map it, I'd put it in as a separate relation and put days of operation in the two variants (do we have a tag for that?). I I've seen people use "opening_hours" on route relations. might also want a tag on the relation such as operation=normal|variant|??? to help renderers pick out the "normal" ones for rendering. Oxomoa recommends the use of "alternate=yes/no". cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Hi, On 14.01.2011 13:30, Michał Borsuk wrote: Even invariant lines become challenging for beginners, because the concept of forward and backward roles is really difficult to grasp. I may have got it wrong, but on a simple line from A to B, with bus_stops serviced in both directions (a good majority of lines), I don't see any use of the roles. I have the information that "here, at this bus stops you have bus 105", and that's all I need now. I've used roles on lines that have different paths, and with the scarse information "out there", I managed to understand it, so again, we need Actually, you made me just realize that by doing that (not adding "forward" and "backard" to stops) I ignored the direction iformation, which would be useful to the disabled, but indeed that's a lot of work. It is not just useful, it is necessary in order to route pedestrians to the correct one of two platforms. By the way, the wiki page on route relations [1] is completely pointless on this matter. From the section "Members": forward/backward if a route should only be followed in one direction for some or all of its length, the "role" can indicate this for some or all of the constituent ways. "forward" means the route follows this way only in the direction of the way and "backward" means the route runs only against the direction of the way. OK, so if there is a route section served only in one direction, we can use this to specify that direction. forward/backward:stop A Bus stop or train halt, on the route, which is only be used in one direction. The direction is related to the direction of the way, nothing to do with towards/away from any bus station or terminus. Ouch... this obviously implies that stops be placed *on the way*, which is wrong by itself (as for buses). Also, it is quite unlikely that a stop is served in only one direction whereas the road it resides on is used in both. For stops that are situated at a segment that is served only in one direction, it is clear in what direction the stop is used, isn't it. Problem still not solved, we want to specify which direction a particular platform/pole serves on a two-way segment. In order to do that - assuming we are not using more than one relation - we must (1) include the first and last stop as "first"/"last" members and (2) shift the meaning of "forward_stop"/"backward_stop" to what it is just not meant to be according to the description given and specify it for every single element. (OK we could assume that, depending on the country, platforms are right/left of the road, but I'm not really comfortable with that.) cheers ant [1] http://wiki.openstreetmap.org/wiki/Relation:route ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Hi, On 14.01.2011 09:58, Michał Borsuk wrote: How about you, and the few of us who understand why the proposal is a mere nonsense, develop a better proposal? We seem to share the understanding of the flaws; a new proposal may lead to a secession, which is the ugliest thing possible, but I am not sure we can continue to improve the current proposal. Finally, that sounds much more like positive criticism :) By the way, thanks Michał, for pointing out details of the routing techniques that I obviously got wrong. Now let's see how we can tackle the issues we have. Main Problem with the existing Schema (these are copied from the proposal) * Inconsistent handling of railway=tram_stop / railway=halt (node on the way) and highway=bus_stop (node beside the way). One suggestion here is to focus on the platform/pole and to scrape the on-way nodes completely (e.g. Richard's last post). Are there other suggestions? I agree that the platforms are more crucial than anything else (because of pedestrian routing), but how to integrate the widely used tram stop centroids into the proposal? * highway=bus_stop beside the way causes extra preprocessing for routing software. True, but something the data collectors don't have to deal with? I think it depends. Example: If a housenumber is located exactly on the corner of two streets (and no street name attached to it), an algorithm could only guess which street it belongs to. Probably similar ambiguities are possible for bus stops as well (even if only in a very few cases). My opinion: we should require no stop position nodes neither stop area relations for simple and clear cases. But we should have a solid scheme at hand just in case we need them. * No separate tags for stop position and platform / pole. Have been proposed. * Insufficient possibility for line variants for bus lines. Mapping variants of PT lines is indeed close to impossible if people still enforce the "one relation for one line" mantra. Even invariant lines become challenging for beginners, because the concept of forward and backward roles is really difficult to grasp. What's wrong with multiple, non-nested relations? - I'm not saying we need a route master. Opinions please... cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 17:27, Richard Mann wrote: On Wed, Jan 12, 2011 at 4:07 PM, ant wrote: So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Stop areas are about linking the stop (notionally on the footway) to the road. Or they are about linking platforms with the same name. You can do that as you go along. The stopping_position and stop_area relation are just clutter. If you know the latlons of two stop areas, you can work out how to get between them by running your pedestrian routing algorithm. Marking footways between stops (other than the ones you can assume are adjacent to any roads not marked with footway=no) is more useful than linking the stop areas into a group and implying there is free access between any stop area within it. Basically you use relations to link objects which have a geographical relationship - not just a geographical proximity. I think there is some misunderstanding. I'm talking about the use of relations to group stop positions and platforms together that are considered a stop or station where one can change vehicles. These could, for example, consist of two separate tram stops and four different bus stops and could serve several bus and tram lines (or even metro). Maybe this should be tagged "stop_area_group" rather than "stop_area". In any case these objects certainly have a relationship - they serve as interchange nodes in a public transport network. I'm not defending the use of stop area relations on singular stops that have only one platform on each side of the road... that would be clutter indeed. There's sense in adding "group" objects if data relates to the group (eg to a station and not to it's individual platforms), but I'd find a convenient node or area to hold the info, not put it on an unnecessary relation. And if the information is relatively simple (eg a name), I'd settle for putting it on all the nodes, rather than create an artificial single object to hold it. As I said, it depends on the scale of the stop (area (group)). cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 16:40, Michał Borsuk wrote: Am 12.01.2011 16:30, schrieb ant: Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? By introducing an abstract interface layer with your own objects, that is your own internal standard, into which all the "messy" present standards would be translated. This is easy. Then you play with *your* objects, your program is not directly dependent on the OSM PT standards. Any changes to the standards will require only a few lines of code to the abstract interface layer. There are some minimum requirements that the data should meet in order to make it easy. In particular, it should resemble the network structure of a PT network, i.e. bus and tram stops acting as nodes that connect bus and tram lines with each other. A node in this context means "a place where i can change from one bus (tram) line to another without having to walk more than a few metres". In the proposed scheme a stop area is exactly this. So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 16:00, Richard Mann wrote: On Wed, Jan 12, 2011 at 2:50 PM, ant wrote: Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. I don't know what applications you have in mind, but if they can do more than draw some lines on a map, this sounds like black magic to me. Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Hi, On 12.01.2011 13:40, Michał Borsuk wrote: Yes, we are - at the cost of (sorry to repeat the mantra) "efficiency, compatibility with the existing software and easier learning curve". From our point of view (or mine, depends how you see it), the quality of the final product is a mathematical product of quite a few parameters (including the mantra above), NOT the quality of the data alone. Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. Another mapper will come and turn it into a stop area and update the route relations. I'm not saying everybody should do it now and everywhere. But the proposed public transport scheme is a solid basis to work with and one that is scalable enough to meet requirements we might not yet be thinking about. I've already provided my criticism to the proposed schema, so not to repeat myself, on another topic: I have been sort of thinking along the same lines as you are here (assistance to the users of public transport). I came to the conclusion that the easiest thing would be to take the bus stop code and combine it with the link to the local timetable online. For example, to cover entire area of Germany one would need to import stop codes as the "stop_id" tag, and then have a list of online timetables combined with geographical location those timetables cover. As some people (myself included) have already imported stop_id's, the last step - the mapping of public transport authorities to the geographical area, and providing a link to the online timetable is relatively banal. An overlay would then take the stop_id, combine it with the URL, and here opens your timetable website. I don't think that this is sufficient. People will develop standalone OSM routing applications for public transport and won't accept any dependency on external websites... cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Hi Michał, On 12.01.2011 12:45, Michał Borsuk wrote: Am 12.01.2011 12:37, schrieb ant: On 12.01.2011 09:52, Michał Borsuk wrote: The visually impaired are a very small minority, and clearly OSM has different, more basic issues to deal with. We should focus on the mainstream first, to get OSM out of the beta version it is now. It is not our primary aim to serve some kind of mainstream. It is to collect any geographical data that could be useful to somebody. And yes, "somebody" includes blind people, too. I did not exclude blind people from the pool of users. I simply said that they are a minority, and should be treated as such. Not with greater privileges than most of us. Therefore I see no point to spend great amounts of time mapping lines in a special way so that we could preserve the fact that line X calls at bus stop Y in each direction. I simply see no point to focus on this, in the present state of OSM. Look at this Western European town: http://www.openstreetmap.org/?lat=49.10581&lon=6.71405&zoom=15&layers=M I mapped one line through the town, and then simply had to get a level lower, to first map the streets, because simply there was nothing to draw the bus lines on. Later somebody added buildings from the French Cadastre, and the town looks grotesque: now I can guess where the streets should be between thebuildings. But still, there is no point to map more lines before the street network exists. In such a situation should we really think about the blind, or should we focus on the very basic: to put the lines on the map? Certainly it doesn't make sense to talk about bus stops when the road network isn't even finished yet. Totally agree. The point is, we are in the process of establishing a kind-of-standard about public transport network. There has been lots of struggle about this topic, and therefore it's quite an important process. Since I am working on a project that deals with navigation for the blind and visually impaired, I know how important these mapping standards (if you can call anything in OSM a "standard" at all) are. If we continue to stick to the old scheme, or any extremely simplistic scheme, we are simply missing the basis for future development in the area of blind people's navigation (and probably many other areas as well). I'm not saying everybody should do it now and everywhere. But the proposed public transport scheme is a solid basis to work with and one that is scalable enough to meet requirements we might not yet be thinking about. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 12.01.2011 09:52, Michał Borsuk wrote: Am 12.01.2011 07:50, schrieb André Joost: Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information when you are at the spot. It is written on the timetable. If you are able to see, yes. But disabled (that is everyone who has to use public transport because he/she is not able to drive a car) not. The visually impaired are a very small minority, and clearly OSM has different, more basic issues to deal with. We should focus on the mainstream first, to get OSM out of the beta version it is now. It is not our primary aim to serve some kind of mainstream. It is to collect any geographical data that could be useful to somebody. And yes, "somebody" includes blind people, too. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Hi, On 12.01.2011 11:16, Richard Mann wrote: 3) It doesn't matter whether people use one relation per direction or two. Both are readily parsable. However, "forward"/"backward" must refer to the direction of the way, not the direction of the route, otherwise you are cutting across other uses of those roles. I've been using the public transport scheme with separate relations for each direction for quite a while. It's true it's a bit more work, but one of the advantages is that the confusing roles "forward" and "backward" are *not* necessary in that case. And keeping in mind that the road network is growing in detail, i.e. mapping of double carriageways, at some point maybe even individual lanes, the benefit of the "simplicity" of single relations is always traded off against the downside of inner complexity. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] bus stops/platforms with electronic display of when the buses pass through
Hi, I use departures_board=yes/no on platforms (or stops). cheers ant On 01.10.2010 22:39, Jo wrote: Hi, I didn't find a tag to use for synoptic displays indicating when buses are coming through (either as a time left to wait, or a full display of normal time+delay) at the bus stop level. And another one (at the bus_station level) with all the buses that are passing through (like the ones in train stations and airports). That one may even deserve its own node to indicate where it is and possibly even an indication in what direction it's facing. Jo ___ 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
