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] NEW Proposed Feature
On 01/28/2011 02:45 PM, Jo wrote: Yes that's one option. I'm a bit reluctant to put in separate relations for each direction unless someone actually gives me a compelling reason to do so. I already have some ways with more than 20 relations, and I don't really want to double that number without good reason. http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M Lijn 7 uses Krijkelberg twice. Bus stop Sint-Kamillus is served by both directions. This can be mapped without ambiguity if there is one relation for each direction. Do we need such level of details if we can't present it to the user at present? http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M Bus station in Leuven. It's perfectly clear where the buses will travel. Not so if both directions are in only one relation. Is the improvement worth the extra time? Sure it would be possible to program something to process a 1 route relation, but it would not be straightforward. Such situations are quite exceptional. I would know, because I've mapped a mixed urban-suburban area, where some lines are the perfect A-to-B straight lines, and some are pretty crazy (spoon shape is the least strange of all). So: how about two relations per line are to be optional in cases where one relation does not successfully explain the route? Most importantly though, with one route relation per direction, it's a whole lot easier for the mappers to check that the relation is continuous. At the cost of extra time to enter and maintain, and confusion (it's not how it is on printed maps!). I've managed to check continuity with one route, and if you're worried about continuity in the aspect of future routing, then it's irrelevant - routing software does not follow the route itself, but its bus stops. I am a die-hard opponent of relation-per-direction, but please convince me that it is really worth it. As far as routes go that have a shorter itinerary during the week, I wouldn't make an extra sets of relations for those. Simply put the longest road traveled in both relations. Sure, that's the way to go, but what is your proposal for routes with different paths? I have at least 2 such routes, each has 4 variants. I have so far mapped them as one relation, but this is suboptimal. Four relations are not much better, and if I were to apply one relation per direction, I'd have eight. That's an overkill. Jo LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Potlatch 2 includes a display of the ways/nodes in order, and you can move them about, but it doesn't currently tell you anything about the member, except the id and the role (so it's pretty much a list of random numbers). I've raised a ticket requesting at least the member's name to be displayed, maybe also the distance from the first member (which would let you put them in rough order, unless your route doubles back on itself). If we had something like that then I think ordered relations would at last be practical in Potlatch. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
2011/2/2 Michał Borsuk michal.bor...@gmail.com: On 01/28/2011 02:45 PM, Jo wrote: Yes that's one option. I'm a bit reluctant to put in separate relations for each direction unless someone actually gives me a compelling reason to do so. I already have some ways with more than 20 relations, and I don't really want to double that number without good reason. http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M Lijn 7 uses Krijkelberg twice. Bus stop Sint-Kamillus is served by both directions. This can be mapped without ambiguity if there is one relation for each direction. Do we need such level of details if we can't present it to the user at present? We're mapping for the future. öpnvkarte is not functioning anymore anyway at present, so the only way of viewing routes is in an editor like JOSM. What I mean, is that at present we can't present anything to the user. http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M Bus station in Leuven. It's perfectly clear where the buses will travel. Not so if both directions are in only one relation. Is the improvement worth the extra time? That's something everyone will have to weigh for themselves. Sure it would be possible to program something to process a 1 route relation, but it would not be straightforward. Such situations are quite exceptional. I would know, because I've mapped a mixed urban-suburban area, where some lines are the perfect A-to-B straight lines, and some are pretty crazy (spoon shape is the least strange of all). Not all that exceptional, over here it seems to happen in 5-10% of all bus routes I'm mapping. Buses making loops and spoons, that is. So: how about two relations per line are to be optional in cases where one relation does not successfully explain the route? Sounds fair. Maybe we should have a tag to indicate which approach was used. paradigm=allinoneroute or paradigm=onerouteperdirection I'm sure someone will come up with better names. Most importantly though, with one route relation per direction, it's a whole lot easier for the mappers to check that the relation is continuous. At the cost of extra time to enter and maintain, and confusion (it's not how it is on printed maps!). Many things in OSM are not like in printed maps, since a printed map is only one of the possible goals. For instance people also want to create drawings of sequences of stops. I've managed to check continuity with one route, and if you're worried about continuity in the aspect of future routing, then it's irrelevant - routing software does not follow the route itself, but its bus stops. I am a die-hard opponent of relation-per-direction, but please convince me that it is really worth it. If the examples I've presented a few days ago can't convince you, I'm afraid nothing will, so 'I rest my case' :-) As far as routes go that have a shorter itinerary during the week, I wouldn't make an extra sets of relations for those. Simply put the longest road traveled in both relations. Sure, that's the way to go, but what is your proposal for routes with different paths? I have at least 2 such routes, each has 4 variants. I have so far mapped them as one relation, but this is suboptimal. Four relations are not much better, and if I were to apply one relation per direction, I'd have eight. That's an overkill. I guess I'm fortunate our PT company assigns a new ref number when such a situation occurs. This means there are many routes which share large parts of their paths... So the number of relations doesn't become less, but since the ref number is different, we don't have another choice but to create separate relations for these cases. Cheers, Jo ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On Wed, Feb 2, 2011 at 1:42 PM, Jo winfi...@gmail.com wrote: Is it possible to add a way to a relation twice with Potlatch? And is it possible to show that 1 way is part of a relation multiple times? Yes. Oxford Bus route 9 now has a certain section of the Green Road roundabout twice. 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.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
