Re: [Talk-transit] Public transport proposal
On 01/14/2011 08:37 AM, André Joost wrote: Am 13.01.11 21:57, schrieb Michał Borsuk: If this is your project, please stop at once, and wait until after the vote. Otherwise you will piss off many valuable mappers. I think you never used josm so far. You're tryng to derail the conversation. This is about ignoring everybody who doesn't agree with the proposal, not about which is my favourite mapper. As a simple mapper, you have the ability to build yourself a preset and use it on your own, and maybe share it with other users. And I would *never* listen to someone who tells me what I should do in the tone you are using currently. This is a very smart argument ad personam to remain arrogant. I demand your response to the arguments I have presented. The tone is, I believe, justified. Again: the actions of the person who is develipong the plugin for a PROPOSAL is nothing but telling all those who disagree we will push the proposal anyway. That is more than arrogant. LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 14.01.2011 02:16, Tobias Knerr: Dominik Mahrer wrote: One month ago I already posted an RFC on this proposal. In the meantime I got plenty of comments and I have extended/corrected/rewritten nearly the whole proposal. I'm not very happy with the extensive use of relations. Especially nested relations strongly suggest that the level of complexity is beyond what's appropriate for a crowd-sourced project like OSM. The most prominent issue are stop area groups. The necessity of these has already been questioned. I, too, tend to think that determining them algorithmically would ultimately be a better choice. Removing the nested relations for stop area groups would eliminate one of the most complex concepts from the proposal, making it more accessible to mappers. Additionally, I suggest to reconsider the requirement to use stop area relations even in simple cases Many bus stops are very straightforward: They consist of usually two platforms with a common name. This name is usually unique within a range of several kilometres and, if tagged to the platform elements, could therefore be used instead of a relation to identify the components of the stop area. +1 I don't think the stop_area-relation for the vast majority of simple bus, tram or train stops is necessary. öpnvkarte.de and other sites working with the data prove that you can reliably determine nodes belonging to one stop via easy algorithms/preprocessing. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
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. I am in :) and the proposal should aim also to keep the existing status quo for backwards compatibility (i.e. highway=bus_stop as the essential basic element of a bus stop). I know there are more people who are interested to join. Tiziano OSM Mapper of the whole city bus network in Padova, Italy ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
Michał Borsuk michal.borsuk at gmail.com writes: Au contraire. Whatever is used, is the law, or is going to become the law. There is no divine being telling us what to do, so your promise of not being obliged to do whatever is worth nothing. because by using something you put the obligation on the community. Nope. If the author doesn't want to implement some feature, he might avoid its implementation. Surely that means his editor won't be used for working with this feature, but that not a problem: still, it can be used for working with all other features. Again, on the contrary. We are introducing laws aimed at attracting beginners. Clearly, the choice of beginners is going to be Potlatch. Hence we are limited by what is available at the moment. And let's not forget the popularity contest. Last time I checked, each of the three editors had an equal share. I agree. However, mapping public transport now is complicated as well, so I personally do not expect beginner to start from public transport. Instead, s/he might (and probably will) start from POIs, since they're very visible and extreme easy to map, or Bing-drawing. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
Michał Borsuk michal.borsuk at gmail.com writes: Is it a mere coincidence that the majority which doesn't see a problem is also the majority that supports the proposal? Probably. I, for one, will not be insulted if I'll hear you are developing a plugin for JOSM implementing some other proposal. ___ 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] NEW Proposed Feature
On Fri, Jan 14, 2011 at 11:46 AM, ant antof...@gmail.com wrote: 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. Bus stops tend to be a lot closer to the road than houses, and don't tend to stop on corners, so I struggle to envisage a situation where it is actually ambiguous. Any ambiguity could probably be resolved by simply putting the node closer to the correct road. If it's only a small number of cases, it's unlikely anyone would bother processing the relation data (they'd just accept a tiny error rate). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Public Transport Proposal
I've been reading this: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transpor t which I assume is the correct one to understand these discussions. The key section I believe is: Main Problem with the existing Schema * Inconsistent handling of railway=tram_stop / railway=halt (node on the way) and highway=bus_stop (node beside the way). * highway=bus_stop beside the way causes extra preprocessing for routing software. * No separate tags for stop position and platform / pole. * Insufficient possibility for line variants for bus lines. I don't see the first point as an issue. So they're inconsistent. If they're documented though that isn't a problem. The problem comes when people edit the wiki to try and change the definition to something other than that which is already widely used. Because these wiki changes has caused some debate, particularly about highway=bus_stop, I do like the backwards compatibility of public_transport=platform and public_transport=stop_position as people can use these new tags and still tag highway=bus_stop (either correctly besides the way, or wrongly in the way g) as they prefer. It is a shame that the wiki edits have made such unambiguous tags necessary though. The second point I can't comment on as I've never written routing software. As routing software exists and this proposal isn't (widely) used, it can't be a big issue, and I believe another post in this forum has made a similar point. The third point is only an issue if you feel it necessary to map the stop positions, which as per my comment on the second point I remain to be convinced about. The fourth point seems almost valid to me. While the existing forward/backward/alternate roles for route relations might make rendering the routes simple, I can see that having separate relations for the route from B to A and from A to B *if they are not identical but reversed* could have applications. Whether a route_master relation is necessary or not I am unconvinced about - it feels too much like using relations as categories which isn't what they are for. It may be a bit more work to create the relations originally, and maintain them on an ongoing basis, but some people map individual trees and how often do you need to resurvey those to check they haven't been hit by lightning, killed by disease or just plain felled? Or pubs - how often do you check each of those that yu map hasn't closed down in these financially difficult times? Maintaining the map going forward will be the bigger part of the project. None of the problems listed suggest any need for stop_areas or stop_area_groups, and the proposal indeed shows that the same can be done with appropriate tagging of the objects, or ignoring the stop_area_groups relation existence. So if we discount the stop_area, stop_area_group and route_master relations as unnecessary (sorry, optional), this proposal isn't really that big a change and I don't see why people are getting so upset about it. Ed ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Am 14.01.2011 12:46, schrieb ant: 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 :) So late because I tried to get others, who are valuable mappers for sure, to see that the proposal is going the wrong way. 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. You're welcome. 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). But is it really? I am stuck with the mapping of buses, so frankly I don't have the overview of how trams are mapped, but many issues raised here are really important. But if this IS really an issue, how about treating tram where it doesn't have a right of was as a bus, and where it operates on separate track, as a train? This will be confusing to new users IF they don't read the manual (they will see two seemingly different systems for one tram line), but this has a valuable advantage: it fits the German Stadtbahn - Karlsruhe mode anybody? Where a vehicle (not a train, not a tram) enters both the street network, and regular railway network? (this is not limited to Karlsruhe, this is indeed a big thing in Germany, the tram networks of many cities are connected by sections of old railways converted into this half-train-, half-tram). This would possibly also keep some sort of compatibility. Disadvantage: messy to implement two standards on one line. One suggestion here is to focus on the platform/pole and to scrape the on-way nodes completely (e.g. Richard's last post). I've implemented it before I knew of the entire mess with two competing standards. It wasn't my decision, somebody told me that we map bus stops where they are physically. I also thought along these lines: OSM has a higher resolution than the existing maps, so a stop position in the centre of the street isn't representative enough. * highway=bus_stop beside the way causes extra preprocessing for routing software. True, but something the data collectors don't have to deal with? True but unimportant. And besides, isn't it already a standard to add bus stops to the bus route? I've been doing so. * 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. Again, how about roles? Why don't we try to use them? it seems that they have been largely abandoned. But from the point of view of a non-geek roles are easier to grasp than separate routes. Again, how do you copy a route in Potlatch? Sorry to repeat myself, but how is it that Potlatch is universally ignored, whereas it's the entry-level tool that almost everybody uses? 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. 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 2. lack of the option to duplicate a route in the entry-level software 3. lack of the need in the majority of cases (other cases: roles should be enough*) 4. incompatibility with present mapping standards, I mean printed maps - two routes per line may seem strange to beginners As for roles vs. two relations (3.), I mean to introduce arbitrary roles for legs of strange bus/tram lines. Let the user call the leg where a bus calls on Sunday mornings Sunday morning service only. This is pefectly enough for the rendering software, and as for routing software, I've expressed my doubts (but it should be also enough - those roles can be indexed). HTH. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___
Re: [Talk-transit] Public transport proposal
Am 14.01.2011 12:29, schrieb Oleksandr Vlasov: Michał Borsukmichal.borsukat gmail.com writes: Au contraire. Whatever is used, is the law, or is going to become the law. There is no divine being telling us what to do, so your promise of not being obliged to do whatever is worth nothing. because by using something you put the obligation on the community. Nope. If the author doesn't want to implement some feature, he might avoid its implementation. Surely that means his editor won't be used for working with this feature, but that not a problem: still, it can be used for working with all other features. This were true if we had 30 editors, but we have three. We have to bend over to those who maintain them. Again, on the contrary. We are introducing laws aimed at attracting beginners. Clearly, the choice of beginners is going to be Potlatch. Hence we are limited by what is available at the moment. And let's not forget the popularity contest. Last time I checked, each of the three editors had an equal share. I agree. However, mapping public transport now is complicated as well, so I personally do not expect beginner to start from public transport. Part of the mess is exactly the lack of a sensible and well documented (wiki page!) standard. My aim is to allow semi-beginners to be able to map at least the simplest things. Instead, s/he might (and probably will) start from POIs, since they're very visible and extreme easy to map, or Bing-drawing. This may be surprising, but in many areas the map is pretty full. In my area almost everything is mapped. If somebody likes editing OSM, they might just as well turn to mapping bus lines, with some help from us. Greetings, -- 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] 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
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
On 14 January 2011 18:56, ant antof...@gmail.com wrote: 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. Wrong, due to different opening hours at different bus stops. 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? -- 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] 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
...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. 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... 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. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
