Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 20/03/2020 15:26, Janko Mihelić wrote: the order of platforms and ways I'm unsure what you mean. Could you expand please? Is there a wiki page? DaveF ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tag

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Fri, Mar 20, 2020, 15:21 Dave F via Tagging wrote: > True. There is no requirement for public_transport tags. PTv2 adds > nothing new. Maybe for tags, but relations with the order of platforms and ways was new if I recall correctly, and we should still use that (well, the platforms, maybe no

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:16, Jo wrote: But if the originally, more common tag highway=bus_stop is already used, there is no need to add bus=yes. OK, but if we have to keep highway=bus_stop anyway, then one could also say that it's not needed to add public_transport=platform to such nodes anymore.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:07, Joseph Eisenberg wrote: I notice that they also refer to adding bus=yes etc to platforms representing bus stops, which was not part of the PTv2 proposal, but I guess tries to deal with one of the issues that led people to prefer highway=bus_stop. Yes, that is a rather silly

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:12, Jo wrote: That stop_position nodes became optional is probably because of my influence. Sorry. but In the beginning they were definitely part of how PTv2. railway=stop was, I believe, around before PTv2 concept. I disliked this very much because all of a sudden

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Hi all, It is good to see active conversations on improving mapping of public transport. Many thanks for your proposal John and Stereo! Reading through it, I appreciate it being quite short. And I like the idea of optional route ways. However, I disagree on deprecating them entirely. There are go

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

This is how I would map a solitary tram stop: https://www.openstreetmap.org/node/611673223 Disregard the public_transport=platform, tram=yes. If I were mapping it fresh today, I might not add those tags anymore. Also note the pt=stop_position

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Thu, Mar 12, 2020 at 4:20 AM Jarek Piórkowski wrote: > On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg > wrote: > > > In inclement weather, passengers may well be found waiting in > > the transit shelter 8 metres to west, and the tram will stop for them > > if they are waiting in the shelter.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg wrote: > > In inclement weather, passengers may well be found waiting in > the transit shelter 8 metres to west, and the tram will stop for them > if they are waiting in the shelter. It might also stop if you are > waiting a little bit beyond the she

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> In inclement weather, passengers may well be found waiting in the transit shelter 8 metres to west, and the tram will stop for them if they are waiting in the shelter. It might also stop if you are waiting a little bit beyond the shelter In this case it sounds like the tram operators are allowe

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Wed, 11 Mar 2020 at 22:22, Joseph Eisenberg wrote: > > I am thinking of cases like streetside stops for 30 m or 45 m long > trams. There might be a shelter, which is the most prominent physical > feature of the tram stop. There is no explicit platform. The tram stop > sign might be 10 metres aw

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> I am thinking of cases like streetside stops for 30 m or 45 m long trams. There might be a shelter, which is the most prominent physical feature of the tram stop. There is no explicit platform. The tram stop sign might be 10 metres away from the shelter, and the farthest possible boarding point a

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Wed, 11 Mar 2020 at 08:12, Jo wrote: > That stop_position nodes became optional is probably because of my influence. > In the beginning they were definitely part of how PTv2. I disliked this very > much because all of a sudden we were using 2 objects to define a single stop, > duplicating de

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Wed, 11 Mar 2020 at 16:56, Guillaume Rischard wrote: > > You talk a lot about ‘thinking like a router’. > Actually, thinking like EVERY router used by every renderer that chooses to show bus/rail routes. And then adding vias to ensure they ALL give the right result (tagging for the routers a

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Paul, You talk a lot about ‘thinking like a router’. Of course you’d have the route shown in your editor. Try this demo

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> if we have to keep highway=bus_stop anyway, then one could also say that > it's not needed to add public_transport=platform to such nodes anymore. Yes, that's right. It doesn't make sense to add 2 tags or 3 tags when 1 will do. On 3/11/20, Jo wrote: >> >> >> But if the originally, more commo

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> > > But if the originally, more common > tag highway=bus_stop is already used, there is no need to add bus=yes. > > OK, but if we have to keep highway=bus_stop anyway, then one could also say that it's not needed to add public_transport=platform to such nodes anymore. And if we do that, then th

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

That stop_position nodes became optional is probably because of my influence. In the beginning they were definitely part of how PTv2. I disliked this very much because all of a sudden we were using 2 objects to define a single stop, duplicating details, which seemed like a very bad idea. And it was

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> I notice that they also refer to adding bus=yes etc to platforms representing bus stops, which was not part of the PTv2 proposal, but I guess tries to deal with one of the issues that led people to prefer highway=bus_stop. Yes, that is a rather silly thing that has been added, since it was notic

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I get the impression that consensus and general adoption will not be reached during my lifetime. Good luck with it, I'm out! Vr gr Peter Elderson Op wo 11 mrt. 2020 om 12:13 schreef alan_gr : > John Doe wrote > > I don't understand why the critics of PTv2 seem to think stop positions > > are s

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

John Doe wrote > I don't understand why the critics of PTv2 seem to think stop positions > are such a big deal - they are optional! My memory of starting to map bus stops a few years ago is that it wasn't clear from the documentation that stop positions are optional. I certainly formed the impress

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Richard Z. wrote > Is the route "defined"? I would say "yes" for urban buses in the three cities nearest to me in Spain (Malaga, Seville, Granada). In all three cities the routes (not just stops) are quite prominently displayed on the relevant websites - see a random example here: http://www.gran

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 2020-03-11 Wed 03:20，Richard wrote: > On Fri, Mar 06, 2020 at 04:07:02PM +0100, Peter Elderson wrote: > > > I wouldn't know. It seems strange to me that established routes have to > be > > re-routed to display or use them. How can you be sure the re-created > route > > is the one that is defin

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Almost all PT routes over here are fixed, yes. It's not the driver's decision where to drive. Of course, blocking events may force the driver to go around, after reporting to/consulting with the operator. I'm not so sure it's a good idea to replace fixed and published routes with computed routes.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Fri, Mar 06, 2020 at 10:07:08AM +, John Doe wrote: > > Stereo and I have been working on a schema that makes it easier to create and > maintain public transport route relations. We would like to invite feedback, > questions, and suggestions, so it can mature and hopefully gain widespread

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Tue, 10 Mar 2020 at 19:20, Richard wrote: > > Is the route "defined"? Yes. I would think the operator only defines stops and schedules Timetables rarely show all of the stops on an urban route. You have to figure out the times for stops not listed on the timetable by interpolation. I did

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Sat, Mar 07, 2020 at 11:29:02AM +0900, Joseph Eisenberg wrote: > I appreciate the proposal authors for helping to simplify mapping bus > routes. > > I agree that in many cases it would be correct to only include the bus > stops or train platforms in the relation, especial for longer-distance >

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Fri, Mar 06, 2020 at 04:07:02PM +0100, Peter Elderson wrote: > I wouldn't know. It seems strange to me that established routes have to be > re-routed to display or use them. How can you be sure the re-created route > is the one that is defined by the operator? Keeping as an example the city > P

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Tue, 10 Mar 2020 at 07:55, John Doe wrote: > > > > > Given that iD still seems to scramble sorted routes in some > circumstances, one should not assume that editors will correctly handle any > changes we make. I might be being unfair to iD here, I didn't check the > route was still sorted befo

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 09/03/2020 22:26, Jarek Piórkowski wrote: Separate relations per each route variant If you mean bidirectional, they've been mapped since the inception of route relations. - verifying that the highway ways are continuous in the relation. Which PTv2 tags allows that? DaveF __

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Tue, 10 Mar 2020 at 07:55, John Doe wrote: > > A new housing estate with two connections to the existing road system > could cause the bus to be re-routed. > > Sounds a little odd - would a router really route a bus on a > highway=residential or highway=service? > I should hope so, many bus s

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> > Given that iD still seems to scramble sorted routes in some circumstances, > one should not assume that editors will correctly handle any changes we make. > I might be being unfair to iD here, I didn't check the route was still sorted > before I added a spur, so maybe somebody else doing s

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> > I suggest again: Make the route a separate route relation and include it as > an optional member of the PTv3 routing relation as proposed. Everybody happy > (routing lobby AND route lobby), all bases covered including backward > compatibility. > > Thank you for that suggestion, apologi

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Mon, 9 Mar 2020 at 13:07, Dave F via Tagging wrote: > On 09/03/2020 13:21, Jarek Piórkowski wrote: > > PTv2 is fine for people who want to handle routes that have variants > > and branches and who want computer validators to be able to spot > > potential errors in these branches. > > I'm intrig

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Hello, On 20-03-06 11:07, John Doe wrote: Stereo and I have been working on a schema that makes it easier to create and maintain public transport route relations. We would like to invite feedback, questions, and suggestions, so it can mature and hopefully gain widespread use. https://wiki.ope

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

As an avid public transportation mapper, I welcome the PTv3. It has all the features I need, and it will reduce maintenance by a lot. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Ptv2 uses a different relation for every possible direction, variant and whim and rolls them up into a routemaster relation. So you can theoretically check whether each bit is continuous. On Mon, 9 Mar 2020, 17:09 Dave F via Tagging, wrote: > On 09/03/2020 13:21, Jarek Piórkowski wrote: > > > >

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 09/03/2020 13:21, Jarek Piórkowski wrote: PTv2 is fine for people who want to handle routes that have variants and branches and who want computer validators to be able to spot potential errors in these branches. I'm intrigued: What Ptv2 tags enable those? DaveF __

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Mon, 9 Mar 2020 at 13:45, Phake Nick wrote: > > In PTv2 one can simply select all the ways and then add them into > relation, unlike this proposal where I woild need to try and see where I > needs to add waypoint, and identify if there are any way that can be > rendered differently on differen

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

At 2020-03-09 Mon 16:04, John Doe wrote: > > Hey, thanks for sharing your views 🙂 > > 07-Mar-2020 03:01:41 Phake Nick : > > > [...] for such renderer to work, access restriction for public transit > vehicle need to be complete, which is rather difficult not just because of > the work it take or

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Mon, 9 Mar 2020 at 07:29, John Doe wrote: > This is quite off-topic, but I can't bear to read more completely unfounded > criticism of PTv2. highway=bus_stop ("PTv1") is fine for people who survey bus stops and who want to approximately map a route of a simple bus. PTv2 is fine for people wh

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I suggest again: Make the route a separate route relation and include it as an optional member of the PTv3 routing relation as proposed. Everybody happy (routing lobby AND route lobby), all bases covered including backward compatibility. Data users, renderers and tools can make up their mind what b

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Mon, 9 Mar 2020 at 00:18, Joseph Eisenberg wrote: > > editors would have to take similar precautions with nodes. Not > impossible, but it would take time to appear. Your scheme will be more > fragile than the existing one, at least for a while. > > Well yes, any change will take some work by

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

This is quite off-topic, but I can't bear to read more completely unfounded criticism of PTv2. I hereby declare that I find the old tags to be a complete abomination (Is it on the way? Is it beside the way? Is it a stop, a platform, a halt, a station? Why is a platform or a bus stop a railway

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

sent from a phone > On 9. Mar 2020, at 09:04, John Doe wrote: > > What I have in mind is the case of Delhi's NH9, in which a road was changed > from two to four carriageways. In such a situation, with the constraint of > the existing stops, routers would have to ignore the new inner carriage

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, wrote: > This proposal by Stereo is nothing really new. Just a alternative to > routing which has been around since relations were introduced. > Definitely not 'PTv3'. The 'via' option appears almost as difficult to > maintain as including ways. > >

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Hey, thanks for sharing your views 🙂 07-Mar-2020 03:01:41 Phake Nick : > [...] for such renderer to work, access restriction for public transit > vehicle need to be complete, which is rather difficult not just because of > the work it take or the current incompleteness of the amount of keys in

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> editors would have to take similar precautions with nodes. Not impossible, > but it would take time to appear. Your scheme will be more fragile than the > existing one, at least for a while. Well yes, any change will take some work by the maintainers of editor applications, so we should not

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

This proposal by Stereo is nothing really new.  Just a alternative to routing which has been around since relations were introduced. Definitely not 'PTv3'. The 'via' option appears almost as difficult to maintain as including ways. On 08/03/2020 01:41, John Doe wrote: That would be tempti

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Sun, 8 Mar 2020 at 11:45, Guillaume Rischard wrote: > > On ride_and_hail: in my experience, those are unambiguously definable by > points such as intersections or POIs. Drivers connect the dots with the > only possible path. If it’s ambiguous, you tell the drivers they always > have to go via

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Hi Joseph and everyone, On deprecation: we’re just at the comment stage for now; I think it would be premature to call for deprecation. I’d like it to, of course. Do note that all existing PTv2 relations would already be valid PTv3 relations. On ride_and_hail: in my experience, those are unam

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> 2. People with a preference for the old tags see that as an excuse to keep > using them It's openstreetmap, "any tags you like" etc. - you have to reach local consensus to change tags. Voting on a proposal does not avoid this step, you will have to convince people that the new way is better.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

08-Mar-2020 03:56:45 Joseph Eisenberg : > > > routes without fixed stops can easily be represented using only via points > > and stop positions > > > > I think you mean "bus stops" (or railway platforms), not > "public_transport=stop_position", since those nodes are usually > unnecessary, and a

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> routes without fixed stops can easily be represented using only via points > and stop positions I think you mean "bus stops" (or railway platforms), not "public_transport=stop_position", since those nodes are usually unnecessary, and are not added by most mappers for bus routes. Routing apps ca

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

As mentioned in the Caveats section of the proposal, hail and ride _has_ been in our thoughts. 🙂 (Buses operated by NMRTC in Noida are all hail and ride, and so are all share autos in Delhi, making it quite important for me personally.) My idea, initially, was to have this proposal serve as an

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg wrote: However, there are also public transit services where the bus can stop > anywhere along the route. This is the most common type of bus here in > Indonesia. In this case there are no fixed stops except for the 2 end > points, but the minibus fol

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Phake Nick wrote: > First of all, I don't think there are any existing routing engines > for trains on rail or bus or minibuses on street Sure there are. https://github.com/geofabrik/OpenRailRouting https://github.com/railnova/osrm-train-profile https://signal.eu.org/osm/ https://github.com/Proj

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I appreciate the proposal authors for helping to simplify mapping bus routes. I agree that in many cases it would be correct to only include the bus stops or train platforms in the relation, especial for longer-distance routes, where the bus or train might take several different routes depending o

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

So, what about the idea to store the route in a separate route relation, then add it as a optional member with role "route" to the PT relation? You will have simplicity at the routing level and completeness at the route level, without interference. Without all the platforms, stops and waypoin

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I think if people want to save the full route with way members, that should be allowed. If someone wants to do a first pass with just using waypoint nodes or just the stop_positions, I think that's fine too. So I'm against the proposal in the current form for this reason.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 7/3/20 8:18 am, Paul Norman via Tagging wrote: On 2020-03-06 9:22 a.m., Peter Elderson wrote: That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? No. There is no one true route between two points, so there can't be an authoritative r

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

As my personal biggest use of the public transportation relationship is to visualize the ways that public transit route would take, I must say I am personally against the idea. >From my personal experience of using a non-OSM website "wikiroutes", which is a website that let public enter public tran

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 2020-03-06 9:22 a.m., Peter Elderson wrote: That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? No. There is no one true route between two points, so there can't be an authoritative router. _

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

It looks like it would save a lot of mapping work. While it avoids some problems, such as the relation becoming invalid due to mapper error, it may create new problems. Routers use different algorithms and routing profiles, and the data that may affect route generation (turn restrictions, speed lim

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Mar 6, 2020, 15:22 by music.kash...@gmail.com: > > Thank you for sharing your thoughts 🙂 > > 06-Mar-2020 17:40:23 Andrew Harvey : > >> I think including the actual route is useful and makes life easier for >> downstream users (they don't need a routing engine to show the route), could >> this b

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

John Doe : > 06-Mar-2020 20:39:30 Peter Elderson : > > > > [...] Is it a significant burden to include a router with a renderer? > > I wouldn't know. It seems strange to me that established routes have to > be re-routed to display or use them. How can you be sure the re-created > route is the one

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

06-Mar-2020 20:39:30 Peter Elderson : > > [...] Is it a significant burden to include a router with a renderer? > I wouldn't know. It seems strange to me that established routes have to be > re-routed to display or use them. How can you be sure the re-created route is > the one that is defined

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

> Wouldn't that imply that a chart of PT lines in, say, a city, region or country would need to route everything first, then render instead of just render the route from OSM? > > Seems so. Is it a significant burden to include a router with a renderer? > I wouldn't know. It seems strange to me th

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

06-Mar-2020 18:08:22 Peter Elderson : > If I understand this correctly, your proposal turns route relations into > routing relations. That's a clever way to put it 😄 > Wouldn't that imply that a chart of PT lines in, say, a city, region or > country would need to route everything first, then

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

Thank you for sharing your thoughts 🙂 06-Mar-2020 17:40:23 Andrew Harvey : > I think including the actual route is useful and makes life easier for > downstream users (they don't need a routing engine to show the route), could > this be optional so you can create a public transport route relat

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

If I understand this correctly, your proposal turns route relations into routing relations. Wouldn't that imply that a chart of PT lines in, say, a city, region or country would need to route everything first, then render instead of just render the route from OSM? Vr gr Peter Elderson Op vr 6 m

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

I think including the actual route is useful and makes life easier for downstream users (they don't need a routing engine to show the route), could this be optional so you can create a public transport route relation via waypoints only if you prefer as a starting point, but then still allow it to b

[Tagging] Feature Proposal - RFC - Public Transport v3

Stereo and I have been working on a schema that makes it easier to create and maintain public transport route relations. We would like to invite feedback, questions, and suggestions, so it can mature and hopefully gain widespread use. https://wiki.openstreetmap.org/wiki/Proposed_features/Simple