[Talk-transit] How to tag bike rule on transit vehicles?
Different bus/train/ferry/other public transit services could sach have different policies on whether bicycles can be allowed onboard or not. How should they be tagged? Off hand I have think of several types of permission: - Allowed - Prior notification needed - Only during some time period (not allowed during peak hour or holiday only) - Specific service frequency only - Only for frequencies using particular behicle - Folded bike only - Only if wheels are removed and packed into cycling bag - Disallowed Should they be tagged on individual route related or network relation? ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Talk-transit Digest, Vol 104, Issue 1
>From Hong Kong's situation, I don't think it is wise to simply use capacity to differentiate between minibus and regular bus. Ithe city, minibus and regular buses are generally two different types of service, operated by different companies in different mode and according to different rules. Some bus companies have adopted exactly the same model of vehicle as minibus companies for rural bus routes, but they still differentiate against each others in term of which network they belongs to, boarding/aligning points, seat arrangement inside vehicle cabin, on-board facilities, and other different details. I think it'd thus be more appropriate to differentiate between minibus and regular bus services using information of which brand or network those routes belongs, instead of the actual capacity onboard of each buses serving those routes. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Making bus lines more specific
在 2020年4月28日週二 20:45，Robin Däneke 寫道： > Because the discussion of this thread already ran into the direction of > changing different aspects about the tagging, I used it for the general > discussion. If we refine the buses, it could go hand in hand with > everything else. I’d be interested in which refinements would be needed > there as part of my general suggestion. But in my current WIP-suggestion > the „bus=yes,tram=yes“ should not be necesarry, only a route relation type > for each mean of transport. > ??? "Because the discussion of this thread already ran into the direction of changing different aspects about the tagging, I used it for the general discussion. "??? Your reply was literally the second one in the thread that hijacked it and directed everyone's attention away from the original topic, and the feature in your WIP are also irrelevant to the bus type refinement that was being suggested. > If I could get a list of types of buses, I could think about how to do > this. > Idealy, we leave the „route=bus“ and then add another sub_tag group bus=* > or bus_type=*. Then the generalized „bus" would still be valid but the > specification would be available if needed... > > Should I open a new thread for the general discussion? > Congratulations you have already hijacked this thread successfully and turned this thread into a thread for general discussion that have nothing to do with the original topic. > KR > RobinD > > Am 28.04.2020 um 14:34 schrieb Phake Nick : > > Excuse me, I am a bit lost on how refining bus stop/station/platform tags > will help resolving the issue of making bus route tagging more specific, > and differentiate between different rype of bus services, which is the > topic of this email thread? > > 在 2020年4月28日週二 15:45，Robin Däneke 寫道： > >> Hello everybody, >> >> I have lately been thinking about somehow reworking (or giving a new push >> to) the current p_t:v2 scheme. >> Especially for the fact, that, since it was first proposed and accepted, >> not a lot has changed in which tags are rendered, how certain things are >> hence mapped and the Wiki-Pages on the topic have also changed in the last >> years without any visible going through another proposal process. >> >> When I started mapping in 2011, and first read the german and then the >> english p:t:v2 wiki pages, it was: >> - highway=bus_stop is a legacy tag that should eventually be completely >> phased out >> - stop positions and platforms are to be both mapped >> and some other things I already forgot… >> Now, iD has a rule in its verifyer, that requires highway=bus_stop on >> platform nodes. The point of the public_transport tags is, among other >> points, to replace less dedicated highway tags. >> I think it would be time for a p_t:v2.5 proposal, where we take the >> innicial ideas of the v2, maybe refine a few small details (like is >> stop_position required, or just platforms, can relations of route-parts be >> used in route relations to save on redundancy…) and then put it forward for >> voting. If accepted, we would possibly now have more leverage to get the >> editor and render-programers to actually properly implement it this time >> around. >> >> Maybe I could find some time to write my suggestions into a document, and >> we could collect the ideas for those extra tags in there too. I think it >> would make more sense that way, than just the addition of a few tags to the >> current scheme, to then be ignored by the rest of OSM once again. >> >> Kind Regards >> Robin D. (emergency99) >> >> >> PS: The problem with bus_stop on platform: platforms can be nodes, lines, >> ways, even relations, highway=bus_stop can only be a node. This old tag >> should go the same way as the farm tag, which was (forcefully) abandoned a >> couple of years back. There it worked, why not for the „new“ p_t scheme? >> >> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves < >> gbragaal...@gmail.com>: >> > >> > I read your responses and I tend to agree that the opening_hours tag is >> enough to characterize services that are only operated during peak hours. >> > >> > On the other hand, it seems to me that there is also agreement on the >> relevance of having tags to differentiate bus services. >> > >> > How can we expand this debate and expand this discussion? It may be >> interesting for other members of the list to speak out, and then we can >> create or redeem a proposal for implementing new tags. >> > >> > P.S .: I don't know if this message will enter the reply queue
Re: [Talk-transit] Making bus lines more specific
Excuse me, I am a bit lost on how refining bus stop/station/platform tags will help resolving the issue of making bus route tagging more specific, and differentiate between different rype of bus services, which is the topic of this email thread? 在 2020年4月28日週二 15:45，Robin Däneke 寫道： > Hello everybody, > > I have lately been thinking about somehow reworking (or giving a new push > to) the current p_t:v2 scheme. > Especially for the fact, that, since it was first proposed and accepted, > not a lot has changed in which tags are rendered, how certain things are > hence mapped and the Wiki-Pages on the topic have also changed in the last > years without any visible going through another proposal process. > > When I started mapping in 2011, and first read the german and then the > english p:t:v2 wiki pages, it was: > - highway=bus_stop is a legacy tag that should eventually be completely > phased out > - stop positions and platforms are to be both mapped > and some other things I already forgot… > Now, iD has a rule in its verifyer, that requires highway=bus_stop on > platform nodes. The point of the public_transport tags is, among other > points, to replace less dedicated highway tags. > I think it would be time for a p_t:v2.5 proposal, where we take the > innicial ideas of the v2, maybe refine a few small details (like is > stop_position required, or just platforms, can relations of route-parts be > used in route relations to save on redundancy…) and then put it forward for > voting. If accepted, we would possibly now have more leverage to get the > editor and render-programers to actually properly implement it this time > around. > > Maybe I could find some time to write my suggestions into a document, and > we could collect the ideas for those extra tags in there too. I think it > would make more sense that way, than just the addition of a few tags to the > current scheme, to then be ignored by the rest of OSM once again. > > Kind Regards > Robin D. (emergency99) > > > PS: The problem with bus_stop on platform: platforms can be nodes, lines, > ways, even relations, highway=bus_stop can only be a node. This old tag > should go the same way as the farm tag, which was (forcefully) abandoned a > couple of years back. There it worked, why not for the „new“ p_t scheme? > > > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves < > gbragaal...@gmail.com>: > > > > I read your responses and I tend to agree that the opening_hours tag is > enough to characterize services that are only operated during peak hours. > > > > On the other hand, it seems to me that there is also agreement on the > relevance of having tags to differentiate bus services. > > > > How can we expand this debate and expand this discussion? It may be > interesting for other members of the list to speak out, and then we can > create or redeem a proposal for implementing new tags. > > > > P.S .: I don't know if this message will enter the reply queue > correctly; I hope I'm not opening a new topic. I apologize for my > inexperience with maillists. > > ___ > > Talk-transit mailing list > > Talk-transit@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-transit > > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit > ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Making bus lines more specific
1. As far as I understand, tourist_bus=* is specifically used for facilities that take buses carrying tourists like tour group and operate according to travel agencies needs instead of services that are on scheduled routes for public to use, so I thinl they shouldn't be mixed into this discussion. There are other scheduled bus services that are designed to serve tourists but they are not covered by existing tags and could also be included in an expanded tagging proposal. 2. For the "residential service" buses in Hong Kong, despite some operators are now transforming their service into a way that is similar to franchised bus operation, it is still very clearly stated on the government website that: *The role of NFBs is to supplement the mass carriers. The supplementary role of NFBs include:* *(a) relieving heavy demand on the franchised bus and green minibus services primarily during the peak hours; and* *(b) filling gaps of passenger demand which cannot be met viably by the regular public transport services.* *Based on the above criteria, NFBs are to provide tailor-made service to specific groups of passengers.* 3. The key here is not the service quality inside vehicle cabin, but the product differentiation proclaimed by service provider or transit regulators, which separate them from other regular services. Different operators or regulators in different parts of the world might differentiate their products differently, but as most of them share some similar characteristics I believe it is not a bad idea to group them into same category in openstreetmap tagging. 在 2020年4月27日週一 20:38，Ken Lee 寫道： > Another big user would be Singapore. Japan also has very limited ones. > > There are say 3 elements here: > 1. On the vehicle itself, whether `coach=`, `tourist_bus=` (in use now) > should be considered a sub-type of "bus", such that `bus=` becomes a new > super-type. In that case, we may have to conceive a new value for the > specifying "city-bus", with it as the default of `bus=` for backwards > compatibility, reflecting current usage, and ease of tagging. This is > important for access restriction. > 2. On the market served, some "residential coach" service, and community > buses in general, operate standard city-bus (or mini-bus) vehicles, instead > of a coach bus, passenger van, or any other specialized vehicle. Mixing 1 > and 2 up will likely cause problems for access restrictions and specifying > service type. > 3. On the service quality inside the cabin, including comfort and fare. I > want to consider this separately, because the cabin of an ordinary city-bus > can be modified into a more luxurious interior for service on such routes. > (A city-bus may also have luggage racks added, but otherwise remains the > same, for non-premium airport and cross-border routes, etc; however this > seems to fall under vehicle equipment, similar to low-floor vehicle, > electrical sockets, wi-fi and other amenities) > > "Peak" routes shouldn't get a new value - this falls into `opening_hours=` > and `interval=`. "Commuter" won't really be very useful either, as > "regional" routes can be commuter-like as well, and "commuter" could have a > peak-only or otherwise limited service implication in for example USA. > Afterall, `service=` for passenger train service is "in use" only, still > not formally "approved". `passenger=` tagging the service range is at least > better, though it could be further elaborated, and source of it is not > clear. > > Aside the mainstay of commuting and essential trips, there are also > services for leisure and tourist . Maybe they can simply be handled by > `leisure=yes` and `tourism=yes`? > > When I look at one such particular proposal > https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport, > aside from the ambiguity of "=commuter" mentioned above, the choice of a > `*:type=` prefix is just no-good and error-prone. A more specific word > should be used. Indeed, the current draft mixed a bunch of values of > different natures (that can coincide) under one such key. So maybe we can > compile and compare existing proposals first, then you can adopt one for > now, or try to work upon them to create a new proposal. > > On Mon, Apr 27, 2020 at 5:31 PM Phake Nick wrote: > >> Such sort of bus service seems to be very similar to the premium "M-bus" >>> servive in Seoul, or residential coach services in Hong Kong. They are >>> designed to alleviate commuting pressure and provide a more comfortable >>> journey. Similar service should also exists in rest of the world but I have >>> found no way to specifically tag them. >>> Likewise there are also
