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 parkride 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)te...@teddy.ch 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
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 12:23 AM, Michael von Glasow wrote: On 02/05/2011 06:09 PM, Richard Mann wrote: On Sat, Feb 5, 2011 at 12:32 AM, Michael von Glasow mich...@vonglasow.com wrote: if I may just comment on the relation: I would also use stop rather than forward_stop and backward_stop for the roles since the outward and return directions of a spoon route are somewhat hard to tell apart. (Unless one stop in the loop is formally designated as the terminus where services routinely end.) You have to use forward_stop and backward_stop if you combine the two directions in one relation, otherwise the same-named stop in the two directions don't get combined on the line diagram. You're probably right (though I haven't tried plotting spoon lines yet), when the same stop is served twice, the tool needs that information. stop works well for single-direction relations. Maybe it would be best to use forward_stop and backward_stop for the stops which are served in both directions and stop for the stops in the loop. I did not play around with actual renderers, but in theory the renderer should be able to get the diagram out of the order of the stops, regardless of the role. If one stop is twice in the route relation it should be obvious that it has to be some kind of loop. So in theory forward_stop and backward_stop can be replaced by the role stop. Or did I miss something? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02.02.2011 13:04, Michał Borsuk wrote: Let's just get down to differences, I say your proposal is too difficult. I've already spoken well about its data integrity, but new users don't care about it. We need something that is as good as yours in data integrity, and as easy to grasp as my proposals. Yours is good for beginners. And yours is also good for a white area mapper. Advanced mappers are not happy with it. In an every dog shit area a mapper wants to map with a higher resolution then highway=bus_stop can provide. And an every dog shit mapper is possibly interested in mapping detailed geo-based meta information like routes. I tried to reduce my proposal to allow simpler cases. stop_area_group has been completely removed. A lot is now optional (stop_position, platform, stop_area, route_master). So it should be possible for beginners to learn step-by-step what they want/need. And one relation per direction is easier to explain then forward/backward roles. And I do not think we (mappers) can replace an existing public transport routing solution like hafas (too complex and too dynamic). The maximum possible in my opinion is to import this data into OSM. But with a single route relation solution I do not see such a solution. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 02/03/2011 12:40 AM, Richard Mann wrote: On Wed, Feb 2, 2011 at 11:10 PM, Michael von Glasow mich...@vonglasow.com wrote: Hence, in most cases the extra node on the way is what I call courtesy tagging - it makes things easier for the renderer (less preprocessing) but can be automated. I would tend towards manual tagging only in those cases in which heuristics are likely to produce incorrect or unpredictable results (e.g. bus stop in the middle between two carriageways). I agree - it's courtesy tagging, but since the node is already there, it seems fairly harmless to tag it with something if/when people move railway=tram_stop to a node beside the way. It doesn't introduce complexity in the way that relations do. There is already a tag for this: public_transport=stop_position. Used 27'000 times in OSM. And you are right, in many (but not all) cases it is courtesy tagging. Therefore I have changed it in my proposal to optional. I'm quite happy if people want to leave tram_stop on the track for the moment. It's not ideal in terms of pedestrian routing, but that can wait. I do not think it is a good idea to redefine thousands of used railway=tram_stop. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] 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 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] 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 01/26/2011 08:40 PM, Michał Borsuk wrote: Line 10 Winterthur: line# relation# # of runs 10 407 6 10 408 1 10 409 1 10 410 6 10 411 3 10 412 3 10 413 6 10 414 3 10 415 3 10 416 1 10 417 6 10 418 3 10 419 1 10 420 3 10 702 2 10 703 2 Voila, one line, 16 relations (unless routes 702 and 703 are yet another line 10 in another place). I wonder how many follow the same trace. The bus service number 10 in Wintherthur is the most simple case you can have. Absolutely no exceptions. See timetables of the two terminal stations: http://online.fahrplaninfo.zvv.ch/showpdf.php?pdf=pdf/21/ah_21110a/ah_21110a_j11_a_02929.pdf http://online.fahrplaninfo.zvv.ch/showpdf.php?pdf=pdf/21/ah_21110a/ah_21110a_j11_b_01826.pdf This gives exactly two relations. And the list you have created does not match bus line 10 in Winterthur at all. Not even the total number of runs is correct... Line 10 Zürich: line# relation# # of runs 10 120 56 10 121 12 10 122 12 10 123 1 10 124 50 10 125 6 10 126 1 Interesting! And where do they start and end? Here your Y line has 7 relations. Again, perhaps they follow the same path, but my general point is to show the level of complication of the data. You can make everything as complicate as you want. It is your choice. But it is not necessary. And again: Why can't you accept, that others want to map something more in detail then you do? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
On 01/25/2011 12:01 AM, Michał Borsuk wrote: So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: ... This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). I don't know where you got these 23 routes. Tram line 10 in Zürich is a Y-Line. One terminal station at one end and two alternating accessed terminal stations at the other end. Period. This gives exactly four routes (two variants in each direction). And where did you got the other 19 routes? Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 11:04 PM, Richard Fairhurst wrote: Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. Thanks for clarification of facts. But then I do not understand what part of the proposal is not compatible with potlatch... Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 08:38 PM, Michał Borsuk wrote: On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: - stop_area is not needed/too complicated: [...]And it does not seam to be too complicated, And as for not needed: can we have a *separate discussion* on how routing works? There had already been voices that stop_area isn't really necessary, and while I don't claim to be pro in routing software, I am pretty sure we don't need them. For routing we do not need them, you are right. And we do not need them if all of the attributes are already tagged at the relations members. But you can tag the shared and identical attributes of all relations members only to the relation instead of all members (if you want). In the proposal all these tags are attributed with the sentence recommended if no public_transport=stop_area exists. So if you like, leave away the stop_area and tag all shared attributes to all nodes/ways. The more exact the OSM map is, the more likely it is that the two directions do not share the same way for the both directions (the lines of one street are split up). Again, this is not an argument as OSM is not a routing software, but a map. Exactly, OSM is a map. And on a map I want to be able to read the route of a public transport service. - route directions/variants is too complicated: My opinion is: The roles forward/backward in the current tagging schema is complicated and very, very error-prone. Then let's drop them altogether. I agree with that! Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/24/2011 10:10 AM, Michał Borsuk wrote: As far as I understand the issue, stop areas are used to tie different stops into one transferring area. No, you did not understand correct. stop_area_group is (was?) for that. Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
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] 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
[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 - 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
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
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 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 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/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
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
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
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
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 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
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
[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] 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] 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
