Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On Mon, Dec 13, 2010 at 7:56 PM, Dominik Mahrer (Teddy) wrote: > You want to use railway=platform for relations for trains. Why creating a > new tag highway=tram_stop instead of railway=platform? 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. > Why replacing the stop position for trams/trains with the platform/pole in > routes? 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). > > 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. > 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. Richard ___ 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
[Talk-transit] Station micromapping ?
Hello transit mappers, I am interested in station "micro maps" with details such as stairways, levels, corridors, ticketing machines, multilevel maps, platforms, lifts... My ultimate goal is to provide information for pedestrian and/or people with specific needs with info about the route from their train to the station entrance or to a specific connexion. Does anybody have some good examples from which I could learn ? or some appropriate resources/tutorial ? Examples I've found are : - http://www.openstreetmap.org/?lat=48.755206&lon=1.943722&zoom=18&layers=M - http://www.openstreetmap.org/?lat=48.787432&lon=2.044487&zoom=18&layers=M - http://www.openstreetmap.org/?lat=48.86867&lon=2.34126&zoom=18&layers=M My interest is further explained (in french) here : http://transid.blogspot.com/2010/11/plans-des-gares-de-france-sur-osm.html Yann ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On Mon, Dec 13, 2010 at 5:26 PM, Albin Michlmayr wrote: > ... 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. Quite a large proportion (?90%) of the public_transport=platform nodes are also tagged highway=bus_stop (and bus=yes). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
Am Mon, 13 Dec 2010 12:12:15 + schrieb Richard Mann : > I think I may have figured out what it is that the established tags > can't do. Yes, I guess you found a quite good summary for the roots of this discussion. > If you've got a railway=tram with a series of nice neat (and > well-established) railway=tram_stop nodes then you can only make that > railway=tram_stop node a member of a route relation once. The oxomoa > conclusion was to have single-direction route relations. > > 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). 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. 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 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. 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. Regards, Albin ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On Mon, Dec 13, 2010 at 1:50 PM, Dominik Mahrer (Teddy) 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 > 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. > 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. Richard ___ 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
I think I may have figured out what it is that the established tags can't do. If you've got a railway=tram with a series of nice neat (and well-established) railway=tram_stop nodes then you can only make that railway=tram_stop node a member of a route relation once. The oxomoa conclusion was to have single-direction route relations. 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 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. 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. Richard ___ 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
I'm one of the people who would like to add data about Public Tranportation. Since nobody likes to have to enter the same data several times, I can understand the need for a 'definitive' way to map PT in such a way that all downstream users (map rendereres, routers, etc) have the information they need to work with. Apparently the system that you want to call established does not completely cater for that, so people come up with improvements. 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. Cheers, Jo 2010/12/13 Richard Mann > On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) > wrote: > > 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. > > "established" would be a better term > > ___ > 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 Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) wrote: > 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. "established" would be a better term ___ 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
