Re: [Talk-transit] New administrator and comments/questions on the new public transport schema
Hi Peter On 05/02/2011 06:23 PM, Peter Miller wrote: Thanks, but that doesn't answer how one avoids getting two station names rendered, one from the node positioned at exactly where one wants it and which can be used in route relations and another from the centre of the area? The idea of the proposal is that only the name of the stop_area-relation gets rendered (if there is a relation). At the moment no renderer supports this. Thanks for the above. The professional European transport model (transmodel) allows nested stop areas and these are used extensively in the UK bus model much of which is already loaded into OSM. I will continue to use hierarchical stop area (as you are doing). One can propose this feature with public_transport=stop_area_group seperately (as it was in Oxomoa). In the discussion of the public transport proposal it was not supported by most participants. Regards Teddy ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] New administrator and comments/questions on the new public transport schema
Hi Peter On 05/01/2011 10:49 AM, Peter Miller wrote: Just to say that I have just set Stefan Bethke up as an admin. There are now two administrators, myself and Stefan which is much better. I would like to also say how impressed I am with the new public transport schema which is proving to be very useful for modeling the main railway stations in London. I have also been working on the OSM wiki over the past week providing more detail about this schema on more pages. Here are a few pages that I have pretty much finished. http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation Thanks for your work on the wiki! One question I do have is about how to tag the boundary of a station. For some purposes it seems to be important to have a node representing the station, and a node is also useful because it can be positioned over the main concourse or at any other appropriate location as opposed to being in the centre of the boundary which is often in the tracks/platform area. This begs the question about how to tag the area of the station. On normal maps a stop_area should not be drawn. So there is another possibility to draw the boundary (if alreay supported by renderers): public_transport=station area=yes If you have a building this should be tagged with: public_transport=station building=yes Take Paddington Station in London as an example. Here is the overarching stop_area for all the elements of public transport associated in some way with Paddington Station (this including the mainline station, two underground stations and a bunch of bus stops). http://www.openstreetmap.org/browse/relation/204439 Here is the stop area for Paddington mainline station itself (note that there is a node with role 'station' and the outline of the station with the role 'building'). Incidentally I am also starting to add footways within the station to the relation with the role 'access'. http://www.openstreetmap.org/browse/relation/1562706 Here is the station node. Note the 'note' that reads "DO NOT delete as route relations cannot have the building (area) as a 'stop'." http://www.openstreetmap.org/browse/node/558489676 And here is the boundary of the station from which I removed the 'railway=station' tag and added a note that reads "please do not add a railway=station tag - there is already a node performing this function." http://www.openstreetmap.org/browse/way/8877521/history I am not 100% comfortable with this approach because without a 'railway=station' tag the area is rendered as any other building rather than as a station. However.. if one adds the 'railway=station' tag to the building outline then one gets another instance of railway station rendered on the map. I know that we shouldn't tag to suit the renderer - this is more a question about how we want to tag things unambiguously and what we want the map to look like and therefore what we want the rendered to do! What I would recommend in your examples: Add type=public_transport public_transport=stop_area to all the relations. In earlier days during the RFC of the proposal there was a public_transport=stop_area_group what exactly fitted your needs for your http://www.openstreetmap.org/browse/relation/204439 During the discussion we removed this from the proposal and we saied one should leave away such a relation as a whole. I personally still add such relations and do not remove them. Have a look at the following example: http://www.openstreetmap.org/browse/relation/1279034 This is the stop_area_group relation containing ONLY other stop_areas. One for railway and the other for the bus. The relations for the railway also includes park&ride and the stations building (http://www.openstreetmap.org/browse/way/82160292) The other realation for the bus stations contains a station tagged with area=yes to show the outline of the bus station (http://www.openstreetmap.org/browse/way/83334745). A railway=station is not used anymore and has been replaced by public_transport=station. Actually it does not get rendered completely, but I think this is only a question of time until the renderers are updated. Hope I have answered all your questions. Regards Teddy ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - Public Transport - Voting
Hi Richard Important is the tagging-list, not the talk-list. I have sent it to the tagging-list and additionally because it is transit related to the talk-transit-list. Thanks Teddy On 31.03.2011 12:01, Richard Mann wrote: This should be announced on the talk list. Richard On Thu, Mar 31, 2011 at 9:41 AM, Dominik Mahrer (Teddy) wrote: Hi Voting is open for public transport proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Regards Teddy ___ 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposed Feature - Public Transport - Voting
Hi Voting is open for public transport proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Regards Teddy ___ 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 09.02.2011 23:12, Michał Borsuk wrote: On 02/02/2011 03:14 PM, Dominik Mahrer (Teddy) wrote: 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. Enter scalability. Those two proposals mixed and *ordered* in a sensible manner can provide ease of use, as well as sufficient coverage of more advanced issues. For beginners level 1, for advanced users with big needs level three. In other words, with very little cutting we'd simply need to order jobs/tasks for mappers from easy to advanced, write a wiki page, and there you go. This sorting-and-ordering would be a major task, so it needs to be done in a quiet atmosphere. Basically I call your request "good", but I'm not sure about the levels. For a bus stop, what would be level 1 for you, what level 2 and 3? 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? 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. Genau. Unfortunately, bad documentation seems to be a standard among FSF projects. I see few volunteers to do that work. Perhaps I misunderstood something. I wrote a proposal that should cover all what is technically needed to map on an advanced level and also permits beginner level mapping. But I did not write a beginners howto or a public transport tutorial. I thought such a tutorial would be based on an approved proposal. Based on the point of view that you see the proposal as a tutorial, I understand now many (if not all) of your criticism! If you see my proposal as a tutorial, it is bad. Very bad. As I have written I do not see my proposal as tutorial, I see it as description of the technically needed that fulfills data integrity. The tutorial is the next step after the proposal is approved. And one relation per direction is easier to explain then forward/backward roles. Yes, but it has a steeper curve if one relation per direction is obligatory. Still, what about variations (like a,b,c,d, but under one line?) I do not want and I can not forbid using one relation for both directions. One relation per service is IMHO better then none. And one relation per direction is better then one per service. In the tutorial I would explain this. If anyone thinks one relation is sufficient then he/she should only use one relation. I know services in Switzerland where this is the case and I by myself would not create two direction-relations (especially single track, rail-bounded and bidirectional vehicles that has its platform on only one side). But if a tram line has mapped every track separate instead of only one way or a bus line that has plenty of one way streets, it would make sense to also create two relations for the two directions. 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? By the way, what do you mean "dynamic"? I don't have a very good opinion of HAFAS, it does its job, but is very old, and IMHO at its edge of development due to silly data structures. With too dynamic I mean that the timetables can change every year. The maximum possible in my opinion is to import this data into OSM. That has been done. Partially, yes. But with a single route relation solution I do not see such a solution. Neither with one route per relation, but I've already covered the topic, exactly in this thread. You name a line in ZVV area, I provide you (if time permits) with routes and bus stops under that line. In other words, automatic import of HAFAS route data to OSM is not possible, because under each line sits a collection of routes, minimum 4 (unless the terminus is also the depot). Those less used must be removed from the import. Yes, of course, if you import the whole data from Hafas you end up with a huge number of relations. But if you import and maintain it automatically, do we have to care about the number of relations? If we map it by hand, w
Re: [Talk-transit] NEW Proposed Feature
On 09.02.2011 23:18, Michał Borsuk wrote: On 02/02/2011 02:42 PM, Jo wrote: Is it possible to add a way to a relation twice with Potlatch? Out of 80 lines I "manage", I have such a situation once (not a way, but a bus stop, actually). Is it an issue in your area? Out of the top of my head I remember at least five situations within four different bus lines where this situation occurs. I'm sure if I would go throught all ZVV bus lines I would get more. 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
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 02/07/2011 10:45 AM, Richard Mann wrote: On Mon, Feb 7, 2011 at 5:39 AM, Dominik Mahrer (Teddy) 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? A normal route with two variants in one direction: http://78.46.81.38/api/sketch-route?1244881&1274167&1244883 A kind of ring route, but first/last tree stops are identical: http://78.46.81.38/api/sketch-route?1342764 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/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 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 02/03/2011 12:40 AM, Richard Mann wrote: On Wed, Feb 2, 2011 at 11:10 PM, Michael von Glasow 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
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] NEW Proposed Feature
On 27.01.2011 22:06, Michael von Glasow wrote: You can find the proposal at: http://wiki.openstreetmap.org/wiki/Proposed_features/Simplified_Public_Transport_Scheme Constructive feedback and suggestions are welcome and can be sent to the list or left on the proposal's discussion page. It seams to me, this proposal is a sipmlified version of my proposal with the following key features: Used well known tags for stops (also possible with mine). Stop area left away (also possible with mine). One relation per direction (identical to mine). Route master left away (also possible with mine). So I do not see a real benefit of this proposal... One thing that can not be represented: If a tram stop is also a light_rail stop. In Zurich we have several stops they are both at the same time. And one thing I'm not sure if it is a good idea: to redefine railway=halt/railway=tram_stop to beside the way. I personally would not try to redefine a well known tag. 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/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] Public Transport Line Diagram
On 26.01.2011 09:20, Michał Borsuk wrote: 1. Tram lines are normally represented by a single line on the map, not one line per track This is what you think is correct. Why don't you accept, that others want and do map more exact and more in detail then you? 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 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/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] New proposal to store public transport data
On 01/24/2011 07:24 PM, Michał Borsuk wrote: On 01/24/2011 03:04 PM, Oleksandr Vlasov wrote: 3. bus_stop already defines `ref' tag, will proposed `stop_id' be something different? > ref= on a bus stop? That's news to me (sadly). I used stop_id=, but the mess probably comes from the fact that there's mess in the documentation. In the OSM wiki I did not find stop_id= at all. Basically there is written about ref= and sometimes about uic_ref= and asset_ref= but not stop_id= 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 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
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
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/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
[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] Proposed Feature - 2nd RFC - Public Transport
On 01/11/2011 10:42 AM, Sander Deryckere wrote: Before this becomes standard, could someone please make a script to transform one tagging scheme in an other? Not for uploading, just because apps have difficulties to support all the different tagging schemes. And after all, we want the data to be useful. In the proposal there is a table that maps all the existing tags to the proposed tags. The table can also be used to map from proposed to existing. See: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Compatibility_with_well_known_tags Teddych ___ 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 01/11/2011 05:10 PM, Michał Borsuk wrote: Again, I am not criticizing the project from data point of view. Data-wise it is very good. OK. But it's too difficult to learn, and really unnecessary in many cases. This is a different problem and basically has nothing to do with the proposal itself. I'm a public transport fanatic. But nearly one year I did not even map one simple bus stop. When I tried (and I mean really tried) to map public transport I knew relations and roles and I was already familiar with subrelations. With the first (pretended simple) bus route I tried to map I already was not able to map correctly and complete. I began searching for alternatives and found Oxomoa, unified stoparea, stop place and others. All are created because the current schema is not able to represent all eventualities. And many bus routes have their specialities. As a newbie-public-transport-mapper I did not know which flavor of schema I should use to map my special bus route. The jungle of possible schema is already densely wooded. But none of the schema has an approved status. So everyone uses another schema. In my eyes the absolutely worsted case. I accepted a lot of criticism and added, changed and extended a lot. I am open to change my proposal. I am also open to approve a completely different schema. Michał, please feel free to tell me what to change to improve the proposal. To say this proposal has a "bad learning curve" may be correct, but it does not help further. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Hi all 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. Please visit again http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/29/2010 12:30 AM, Richard Mann wrote: If someone maps a single node on the way and calls it highway=bus_stop, then that should be OK (but not recommended). unified_stoparea recommends that. You would allow but not recommend it, correct? If someone then wants to put highway=bus_stop nodes on either side, that should be seen as the more correct tagging. The original node should be stripped of it's highway=bus_stop tag, or changed to something meaningless like highway=bus_stop_group_centroid or highway=bus_stop_position (if it genuinely is a stopping position, rather than a group centroid). What about changing it to platform, if it is really the platform/pole? Regards Teddy ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Hi Richard On 12/22/2010 12:16 AM, Richard Mann wrote: But what would you suggest to use as the stop_position for bus stops, if you would have to decide? I would expect data users to infer it from the position of the bus stop. Logically, you could mark a node for the stop_position between the bus-stop and the way (or even on the way if the stop_position blocks all traffic on the way). But this is pretty pointless - data users will probably ignore them anyway, and infer it from the bus stop location. Data users can do with the data what they think it is best. Also Mappers can map what they think it is best. If this is congruent is another question. I guess you will never map a stop_position. Other mappers want to map a stop_position. At the moment they abuse highway=bus_stop as stop_position. There is no (approved/rendered) alternative. I think you agree that this is not an optimal solution. What do you suggest these mappers to use for as stop_position? Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 11:35 PM, Richard Mann wrote: Because sometimes trams just stop in the road, not at anything that might be described as a platform. The only thing you can see is a pole (looking remarkably like a bus stop, in fact). You could call them railway=platform nodes, but it doesn't sound right. You could call them bus stops, but then they'd render as bus stops. Calling them highway=tram_stop allows the nodes to be used by bus relations, while still using a conventional railway=tram_stop for rendering purposes. So I think there is the consensus that there exist tree things that can be mapped: stop position (railway=tram_stop), platform (railway=platform) and the pole (new tag highway=tram_stop). You suggest to only add the platform (or if not existing the pole) to the route. If there is only the platform mapped this is obvious. How would you handle existing routes, only containing the stop_positions (railway=tram_stop)? Removing stop positions and adding the platform/pole? Because the platform/pole is a direct indicator of where the passengers should go to catch the service. The stop position is an indirect indicator of where the passengers should go - ok for simple pairs of tram platforms, but less use for anything else. I struggle to see the value of knowing the stop position except for rendering (it's just the point on the path of the service which happens to be closest to the platform/pole). So you would deprecate railway=tram_stop as the stop position? I read implicitly that you agree to use the platform instead of the >> pole for relations, correct? > Yes. The things that might constitute a stop (platform, bus_stop, tram_stop, halt, station etc) are all quite distinct from the things that constitute the path of the service. If it stops at a platform, and you have that object available to put in the list of stops in the relation, then I'd use it. We are in consensus. I do not want to obligate someone to tag a stop position. Adding a stop position would close an incompleteness compared to trams/trains too. And there are mappers they think it is useful/necessary. Those mappers tag it actually with public_transport=stop_position+bus=yes and/or highway=bus_stop on the way. What do you suggest those mappers? Removing the tags? Tag what you like, as they say, but the route relation should include a clear list of stops. If some people want to use on-the-way nodes as a proxy for the platform (and they do), then having both platforms and stop_positions in the relation strikes me as likely to cause confusion. Better to only put one node (or platform way/area) in the relation per stop. Only adding on-the-way nodes into the relation is often used, correct. But I agree that this is incomplete. My proposal therefore would add both (stop position and platform). I think I will have to extend my proposal that it is not mandatory to map all the proposed points. But what would you suggest to use as the stop_position for bus stops, if you would have to decide? Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
Today morning I got this off the list: On 12/14/2010 07:56 AM, Michał Borsuk wrote: I already told you twice to behave, you little shit. If it continues, I will have you removed from the list. Perhaps I did not find the best words. Please excuse me. English is not my first language. But if this is the way of conversation on this list and if admins? have to threat like this because others have a different meaning, I don't know if I want/need to be on this list... Thanks to all they have brought up constructive criticism about my proposal, I have a lot to complete and correct now. Regards, Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 07:06 PM, Richard Mann wrote: Quite a large proportion (?90%) of the public_transport=platform nodes are also tagged highway=bus_stop (and bus=yes). Depending of the view this is one of the following: 1. It is the result of combining Oxomoa/public transport with unified stoparea. or: 2. It is Oxomoa with renderer compatible tags until Oxomoa gets rendered correctly on its own. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 06:26 PM, Albin Michlmayr wrote: Till now I solved this by defining one stop in the loop as terminus. This lines then take different routes for each direction. Therefore I found the solution with single-direction route relations quite suitable. I don't know if this is the best solution for openstreetmap but I defenately think that there ist missing something in the established scheme. I agree, I do it equal. The forward or backward role of a way in the relation is in my opinion useless, because it is not clear if it refers to the direction of the way or the route. Currently it is used in both senses. I agree to this too. I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. When I first discovered the oxomoa-scheme I thougt that it's quite a good idea to use the new tag "public_transport" because what's the difference between bus and tram stops - there are enough stops used by both means of transport. After following this discussion here I'm not so shure any more because world wide there are already mapped about 66 bus stops as highway=bus_stop and it's senseless to retag all this stops. On the contrary there are also already mapped about 57000 objects as public_transport=* (23000 nodes as stop_position and 22000 nodes and ways as platform) which of course is much less but also too many to retag all these. Because highway=bus_stop (pole) and railway=tram_stop/halt (stop position) have different meanings the current schema is stamped with an inconsistency. Resolving this inconsistency would require a redefinition of at least one of these tags. As you have written: This does not make sense. I don't know which tags are best to be used at the moment but I'm really interested in a broadly accepted guideline for a more unified taging in the future. The longer I think about it, I think it would make sense to use new and clearly defined tags. But the well known tags highway=bus_stop and railway=tram_stop should not lose the meaning/value. In the new schema it should be defined how they are interpreted. For example: node on the way => stop position; node beside the way => pole/platform. So we do not loose information and the already invested work does not lose the value. Actually in my proposal this is missing. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 03:56 PM, Richard Mann wrote: Adding highway=tram_stop as the representation of the tram pole eliminates the inconsistency between railway=tram_stop and highway=bus_stop. What do you suggest for trains? railway=platform ways/areas replace the station nodes in the ordered list of stops You want to use railway=platform for relations for trains. Why creating a new tag highway=tram_stop instead of railway=platform? Why replacing the stop position for trams/trains with the platform/pole in routes? Here in Switzerland we have up to 470m long trains (German ICE), so we have up to 470m long platforms with often two or more poles (or displays as a replacement) per platform. Does it make sense to map all poles/displays and to add them to the relation? Doesn't it make more sense to replace the pole(s)/display(s) with the platform for relation data to simplify things? If the platform breaks into distinct sections (such as the A-E on DB main stations or U-Z on SNCF) then there could be distinct nodes/ways/areas for each section. You might have the whole length of the platform as an area, with subsections (or groups of subsections) done as ways, so you can choose which to make a member of the relation. Which mainline service uses which platform can be a bit variable, so you may just end up using the station node anyway. In some (rare?) cases splitting the platform into several ways/areas would make sense. I know a hand full of practical examples. I read implicitly that you agree to use the platform instead of the pole for relations, correct? What do you suggest as the stop position for buses (as counterpart of railway=tram_stop and railway=halt)? Or would you leave this completely away? I wouldn't tag it. It isn't tagged at the vast majority of bus stops, so data users are going to have to find a way of coping with it not being marked, and will probably ignore any that are marked. I also wouldn't include the stop position in a relation unless it's the only node available. For those thousands of highway=bus_stop tagged beside the way (interpreted as pole) this is the best way to handle. Those tagged on the way should be interpreted as stop position. I do not want to obligate someone to tag a stop position. Adding a stop position would close an incompleteness compared to trams/trains too. And there are mappers they think it is useful/necessary. Those mappers tag it actually with public_transport=stop_position+bus=yes and/or highway=bus_stop on the way. What do you suggest those mappers? Removing the tags? Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 01:12 PM, Richard Mann wrote: But this doesn't work well when you have lines that loop at the ends (fairly common with bus services), because the two relations overlap (you have to make certain nodes members in both relations, and that starts crossing a complexity/maintainability threshold). I see the problem with looping lines and I know several practical examples. Even hafas sometimes can not handle this correctly and if then this is usually solved that one stop is defined as the terminal stop. The stops before belong to the route to the terminal stop, the others to the route back. So in theory you have to change the bus at the terminal stop, in practice this is not the case. I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. I support that one node for a 40m long tram stop isn't really enough. My suggestion: 1) highway=bus_stop - nodes to mark bus stop poles and to be members of bus relations (can also be used for tram relations) 2) highway=tram_stop - nodes to mark tram stop poles and to be members of tram relations (can also be used for bus relations). Renderers may prefer not to render these (there will generally be a railway=tram_stop node to use instead). There are only 13 of these in the world according to taginfo, so adoption of this tag for this purpose is unlikely to annoy anyone too much. 3) railway=tram_stop - nodes to mark the centre of the tram stop area, in the absence of a stop area relation. Mostly for rendering/labelling purposes. Can be used as a member of uni-directional relations, if setting up highway=tram_stop nodes is viewed as too complicated. This is constructive. Thanks for that. May I ask you some questions about that? railway=tram_stop and railway=halt are mainly used for the stop position of a tram/train. highway=bus_stop is the representation of the pole (current schema). Adding highway=tram_stop as the representation of the tram pole eliminates the inconsistency between railway=tram_stop and highway=bus_stop. What do you suggest for trains? Here in Switzerland we have up to 470m long trains (German ICE), so we have up to 470m long platforms with often two or more poles (or displays as a replacement) per platform. Does it make sense to map all poles/displays and to add them to the relation? Doesn't it make more sense to replace the pole(s)/display(s) with the platform for relation data to simplify things? What do you suggest as the stop position for buses (as counterpart of railway=tram_stop and railway=halt)? Or would you leave this completely away? Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 11:52 AM, Jo wrote: I like the proposal, the only thing I don't like about it is the massive duplication of information in the route relations, which will make it harder to maintain them in the long run. But I see why we would do it that way. Maybe I'll come up with a proposal for 'proto-relations' made up of other 'routepart'-relations some time. Those could get converted to the massively duplicated relations automatically then. When I understand correct you mean the same as Marl brought up on the talk page under "Shared Route Segments": http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Public_Transport#Shared_Route_Segments Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 02:17 AM, David Peek wrote: Can I just add, this seems to sum up most of my feelings towards this discussion - if it can be called that. Yes you can, and thanks you do. On 12 December 2010 13:35, Jerry Clough - OSM mailto:sk53_...@yahoo.co.uk>> wrote: Odd, this, as I can immediately think of the opposite use case: several marked bus stops, but the buses stop at random positions over about 100m of road depending on how many other buses are present. Individual buses serving the same routes will stop in completely different places (sometimes two or more buses serving the same route will be present at the stop). Not sure about this, but it's not the main thrust of the message in my opinion. The main message I want to say is: There are mappers hoping for/needing a more exact schema to be able to reflect some cases they can not be mapped adequate at the moment. Please stop referring to the current widespread practice of highway=bus_stop mapped at the pole as 'old': in doing so you are instantly raising the hackles of those who have spent time on the ground mapping, rather than writing proposals on the wiki. Agreed. "Old" implies it has been replaced or is depreciated. That is unhelpful given to my knowledge this is the case neither in theory or (more importantly) in practice. You both are right, "old" is the wrong word for what I wanted to say. I do not want to replace or deprecate highway=bus_stop. Because English is not my first language, I catched up to consult my dictionary and I think "traditional" or "conventional" would be the better word, expressing what I wanted to say. For all I know the various discussions and proposals may have some value, but I find the initial tone off-putting, lacking respect and overly confrontational. It is not a good route (;-)) to building consensus. By far and away the best approach is to map a specific area, and show how it really adds value to the map and to a range of data consumers (not just a pet public transport router). If it really is better than what exists you'll get people using it: telling people they're stupid, which is the basic tone of many messages to this list and discussions on the wiki is less likely to be successful. Thanks for the constructive idea to map an area with that. I will do this for a bus line. As I implied further up, I don't think discussions is really an appropriate word. Most of the messages seem to be of the "I am right, you are wrong" variety. Hardly a good way to build consensus. You are right, this is not the way to a consensus. I get a lot of constructive criticism about the proposal, especially on the talk page. This gives me a lot of input to revise the proposal. This also shows me that many mappers are interested in something new/corrected. In contrast to that I get only one message on this list: We have a schema, we do not want to correct the inconsistency of it and we do not want to have anything additional. I do not say my proposal is the best. But I think it is time to extend/correct the currently used schema. Constructive criticism is highly welcome. Regards, Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/11/2010 03:32 PM, Michał Borsuk wrote: And by the way: What physical thing is represented by railway=tram_stop? I don't deal with trams. So you have a very limited view of Public Transport. Whenever I criticize Oxomoa I hear the same silly argument: "but in my Siedlung there's a bus that does such a complicated thing...". So what? Who cares? The mapper cares. In his eyes it is not silly. It is the willing of mapping it as correct as possible. If you do not want to care about complicated things, this does not mean others do not want too. I am not sure if I know what "the old system" is. Maybe we actually criticize the same thing. I'd do it this way: highway:bus_stop for each bus stop, and then the bus stops are added to each line (relation) that stops there. Nothing more is needed from the point of view of even rich future applications in OSM. There is the info where the bus stop is, there's the line, if we ever want to link OSM with timetables (as I am planning), then we have everything we need. I do it the same way. The differences are the details. Would you be so kind and withdraw from the accusation that the reason behind the resistance is the unwillingness to convert the existing system? You do not deal with trams, you have written. So you have a limited view and can not see the inconsistency in the schema. And you can not see the need for changing the schema. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/11/2010 09:26 AM, Michał Borsuk wrote: Many city and/or network public transport wiki pages in central europe recommend to use highway=bus_stop _on_ the way And they are wrong. Because according to OSM's principles, the object should be placed where it physically exists. Depending of what highway=bus_stop should represent. If it represents the pole/platform they are wrong. If it represents the yellow zigzag line on the street they are right. And by the way: What physical thing is represented by railway=tram_stop? I would like to approve a tagging schema that is clearly defined. ..but which is not against the principles of OSM. What is against the principles of OSM in public transport proposal? Imagine that you're not German. I do not have to imagine this, I am not German. > Do you see how unnecessarily complicated Oxomoa's plan is? It covers very, very small details (read: they rarely occur), at the some time forcing much more work on simple (most often occurring) situations. Your beginners version: highway=bus_stop beside the way highway=platform beside the way Oxomoas beginner version: public_transport=stop_position on the way public_transport=platform beside the way Where is the difference in effort? If this is still too much effort, you can leave away one of them. I guess you do. Sometimes I do either. Whatever proposal/schema you take (old/unified/oxomoa/stop place): Nothing of the tags is a *must*. Everything is optional. You can invest as much effort in tagging you want. But the upper limit of (unified/oxomoa/stop place) is much higher then in the old, very limited schema. Au contraire, my fellow mapper, and it this discussion was *closed*. Two years ago or so. I opened it again in 2010, because the underlaying basics changed since then. There are as many bus stops near the road as there are out there in the field, because the resolution of the map is so detailed, that placing one dot on the road is not enough. Moreover, as far as I remember, North American system (contrary to Hafas), gives each physical stop place a different index number. How do you want to map this with the old schema? You do not have a stop place/stop position tag. The platform definitely is beside the way Where? Behind the corner? On the left? On the right? No, this is not detailed enough. As you said: There where it physically exists. My understanding for those they have put hundreds of tags on/beside the way. They do not want to move them (in which direction ever). Do you have any other personal accusations towards other mappers? This is not an accusation, this is the only plausible reason I heard until now for not changing the old schema. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/11/2010 12:39 AM, Richard Mann wrote: The English-language discussion appears to have long reached a consensus (except for you). The decision to place highway=bus_stop beside the road has been made before highway=platform existed. Without highway=platform I also would vote for beside the way. Then highway=platform has bin introduced. Beside the way. Since two and a have year we have two tags for a bus stop beside the way. At the same position. This definitely does not make sense. Or does it for you? The decision to place highway=bus_stop was based on the fact that one should be able to see on maps in which direction a bus runs. The need for highway=bus_stop beside the way has been replaced with the approved feature highway=platform. Could you give me an argument why highway=bus_stop should be beside the way? To place highway=bus_stop beside the way is inconsistent and incomplete. If some people wish to use highway=bus_stop on the road, with highway=platform alongside, that can perfectly well be deciphered by software, and clearly documented as an alternative approach, This is the point where we are in the wiki now. And this is very close to unified stoparea. It does not need a public_transport key to confuse matters further. If we define highway=bus_stop *on* the way, we do not need another tag, you are right. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/10/2010 08:55 PM, Richard Mann wrote: I would agree that on-highway highway=bus_stop should be phased out (is anyone saying they should be retained?). I think they're a hangover from the time before we realised that tagging the pole was a better approach. In the mean time, I don't think it causes any major problem (it just isn't as clear as tagging the pole). Many city and/or network public transport wiki pages in central europe recommend to use highway=bus_stop _on_ the way (in coexistence with Oxomoa and unified stoparea and public transport proposal). So highway=bus_stop on the way does not get phased out. Even on the wiki page highway=bus_stop is not clearly defined as _beside_ the way. highway=bus_stop is a fuzzy tag. I do not like this war around this tag. Especially see the German talk page. I would like to approve a tagging schema that is clearly defined. Doing this with new tags is portably the easiest way. Redefining highway=bus_stop on or beside the way seams to be nearly impossible. Again: Have a look at the German talk page. Why is highway=bus_stop recommended to use _on_ the way? Because it does not make sense to have two tags _beside_ the way (highway=bus_stop and highway=platform). The platform definitely is beside the way (It is an approved feature and I never heard other voices). highway=bus_stop _on_ the way would be in consistence with railway=tram_stop. And it would be a stop position. And it would fit unified stoparea. My understanding for those they have put hundreds of tags on/beside the way. They do not want to move them (in which direction ever). Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Think of a terminal bus station somewhere in the center of a city. Four bus lines end here. One platform of 50m. The four lines stop always at the same position (line 1 is first,..., line 4 is last). Only one pole for all buses. Where do you place your tags? Or how do you tell where to wait for bus number 4? At the pole that is 40m away from the stop position? It is up to you to use a new schema, or not if you dislike. I usually do not map already mapped routes/stations again, so I do not have to drop an original node. But when I map a new station I map stop position AND platform. On 10.12.2010 14:51, Richard Mann wrote: Dominik/Teddy Please could you explain what situation do highway=bus_stop / highway=platform / railway=platform not cover already, that requires public_transport=platform to be added to the list? If you're not intending to deprecate, then you're just adding complexity. highway=platform is for buses/nonrail railway=platform is for train/tam/rail What should be used if there are buses and trams at the same station? I do not plan to replace existing tags with highway/railway=public_transport, but I will tag unmapped platforms with public_transport=platform. If so this can be done with a bot. highway=bus_stop is used different. Sometimes as stop position, more often as platform/pole. See http://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dbus_stop#Results_2010-10-27 The meaning of how highway=bus_stop should be used differ. It can not be replaced easily with a new public_transport tag. Also I think you need to make a clearer case for public_transport=stopping_position. You claim it's needed for routing - but routers currently seem to manage without. The existing tags can cover the simpler situations (starting with a single node, then two or three nodes, then the two nodes become platform ways/areas), and still used for the more-complicated situations (>2 platforms / bus_stops), just grouped into a relation (and at which point you might well drop the original single node). 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] Proposed Feature - RFC - Public Transport
Hi Richard There appears to be a degree of consensus on using one type=route relation per direction (though it's not entirely clear whether this is really necessary), not worrying overmuch about telescopic routes or occasional diversions, and (groaning but) creating separate relations for routes that branch. Some of the work to implement this is waiting on Potlatch2 (which will have rather better relation support). I think the biggest uncertainty is how you handle loops at the end of a route - do you have overlapping single-direction relations, pick an abritrary position to change direction, or stick with having both directions in the same relation and let the data user worry about it. This sounds more to try to find a consensus then all you have written before. It's up to the mapper how much time he/she wants to spend in mapping bus/tram routes. The more time he/she has the more exact the result will be. One simple relation per direction is not more work then only one relation for both directions with complicated roles. If you do not want (or your software can't) create a master relation, just leave it away. Reflecting very complicated variants should be possible for interested power mappers. This is what Oxomoa already wanted to cover nearly two years ago and several mappers are already using. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Hi Richard The only inconsistency is that "tram_stop" generally refers to a stopping place and "bus_stop" generally refers to a quay. This is not enough reason to propose changing half a million established tags. Sometimes trams stop at bus_stops and sometimes buses stop at platforms, but that's not a reason to change the tags to something more generic. It does not make sense to change more then half a million tags. I did not write this, I do not mean that. And the proposal does not conflict with highway=bus_stop or another tag you and many others are using the way you explained. The proposal is NOT for redefining or replacing highway=bus_stop!!! (Other proposals do.) Your way of tagging is the "old" way. Historically crown and widely used/accepted. It is NOT deprecated or obsolete. But keep in mind that there are more and more mappers they want a more exact schema then you are using. We should give them ONE approved possibility how they can do it. Otherwise everyone does it different (like today). So we should find a consensus how this more exact schema should lock like. To say we do not need anything else we have (this is how I read your text) is not a consensus. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/09/2010 11:40 PM, Michael von Glasow wrote: http://78.46.81.38/api/sketch-line?network=SITAM&ref=69&style=padua Nice tool. But usability can be improved (GUI is missing). Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/10/2010 12:08 AM, Michael von Glasow wrote: 3. Which data primitive should be added for stops? Stop positions AND platform. Stop position is important for the route itself, the platform is important for pedestrian routing. Fine for me, though it does mean some more effort to enter data. Except that we might consider adding the platform right after the stop it belongs to - that would make it easier to verify that both are there. You are right. I have to think about. As far as I know, this is accurately defined: it is relative to the tagged way direction, which may or may correspond to the route direction. But I, too, realize that this part confuses people. If we agree that ways must always be sorted, each way sharing an end node with the ones before and after (which I strongly recommend), then we can extract this information from the route itself without tagging it explicitly. It is defined, yes. But not everyone reads the part, and even if he/she read it and does it correctly: Another mapper could reverse the way for some reason and the relation is broken. Practical: I map the variant with the most stops (in your example twice A B1 E1 K. In JOSM you can easily copy a relation and change what is different. So to handle your 8 variants should not take 8 times mapping one variant. That works when you have the entire route from beginning to end. But some of us (I do) often follow just a part of the way and enter that, hoping to complete it at a later occasion (or someone else doing it). And once you have two partially-complete relations, updating them both together mostly means editing each relation manually. This is correct, but this is not a problem of partially or not. This is brought up by a route for each variant. But I hope your routes in Milan are not updated every two weeks... Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/10/2010 01:45 AM, Richard Mann wrote: highway=bus_stop on a node next to a road railway=tram_stop on a node on railway=tram railway=platform on a node or way or area next to the tram tracks This is how you are using it. It is inconsistent. It is incomplete. It is historic. Beside your opinion there exist other, better schema that are _in use_: - Oxomoa (draft) - Public Transport (proposal) - unified stoparea (proposal) - stop place (proposal) - several variations of the four listed schema. If we go on waiting to approve one of them, the number of ideas and proposals will grow and the variations of them will increase too. This is not what OSM is designed for. OSM is useless if everyone makes it different. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 09.12.2010 13:31, Michał Borsuk wrote: There is the issue of "multiple relations per line" in oxomoa, which in my opinion is a total misfit. There are "roles" in relations, and different variants of a route can be put there. Two, or more, relations per line is not only "illegal" (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Potlatch and Merkaartor account for 2/3 edits together. This simply cannot be passed to the final draft unchanged (as is). A missing feature in a specific software implementation usually is not a criteria of using or not using a feature in an API. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Hi Michael In the new proposal I am missing some details on how to build relations: 1. Should the outward and return trip be represented as two separate relations, as a single relation or is that up to the mapper? Each direction should be in a separate relation. This is written in the proposal. Both directions/variants should be member of a master relation. 2. Which members should the relation contain, and in which order? You are not the first with this question, so I added some explanations to the proposal: First the stop_positions ordered (with role stop), then platforms ordered (with role platform) and then the ways ordered (without role). 3. Which data primitive should be added for stops? Stop positions AND platform. Stop position is important for the route itself, the platform is important for pedestrian routing. 4. How are line variants mapped? Problem 1: A - B1/B2 - C - D - E1/E2 - F In morning and evening hours the bus stops at B2 instead of B1. During school holiday the bus stops at E2 instead of E1. This gives us four possibilities really used. When you add alt-roles to a stop you can't say when is what route used. So this does not work, we need really four relations. Problem 2: What do you want to say with role forward/backward? Forward/backward compared to what? To the route direction or to the tagged way direction? Actually both is used in the OSM database and no one knows how to interpret it. Role forward and backward is in my eyes a nice try to solve a problem. But it confused more then it solved. We should leave this away. Practical: I map the variant with the most stops (in your example twice A B1 E1 K. In JOSM you can easily copy a relation and change what is different. So to handle your 8 variants should not take 8 times mapping one variant. I personally leave away the very special cases (ex. first course starts at B instead of A). This is only relevant when timetable information is added to. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Hello Yes, the Public Transport proposal is basically based on Oxomoa, but in some details different. unified stoparea would "redefine" highway=bus_stop from beside the way to on the way. I'm quite sure this would reject the proposal in a vote. unified stoparea and public transport can and do exist beside each other. But you are right, it does not make sense to approve both proposals. I do not care about which of the two proposals will be approved. But I think it is time to get a more exact schema approved then the fuzzy/non-existing schema (A railway station of 400m length and 20 platforms or a bus stop for 3 buses per direction of 50m length is reduced to one node) we have now. Regards Teddych On 12/08/2010 06:02 PM, Oleksandr Vlasov wrote: Dominik Mahrer (Teddy teddy.ch> writes: I want to invite everyone to comment the (in central europe) already widely used new Public Transport Schema: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Hello, it's based on Oxomoa scheme, isn't it? What's the status of the "unified stoparea" proposal then? those two contradict each other and unified stoparea is in RFC stage for a year now. Are there any data regarding actual usage of those two (I understand that unified stoparea uses quite common tags and thus it's hard to compare just a number of appropriate tags' occurrences) Regards, ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposed Feature - RFC - Public Transport
Hi, I want to invite everyone to comment the (in central europe) already widely used new Public Transport Schema: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport on the main OSM page
Hello list http://wiki.openstreetmap.org/wiki/OSM_Inspector provides a similar view (Public Transport Network) like ÖPVN-Karte. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit