Feature Proposal - RFC - Public Transport v3

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - RFC - Public Transport v3

John Doe

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/Simpler_public_transport_route_relations



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Andrew Harvey-3
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 be completed via the way members.

A bit like how most things can be initially mapped as a node but then are usually expanded out into an area.

Secondly I don't quite understand the no way member rule of your proposal, since railways platforms should be a way https://wiki.openstreetmap.org/wiki/Tag:railway=platform then including the platform in the relation means you need to include ways as relation members.

On Fri, 6 Mar 2020 at 21:08, John Doe <[hidden email]> 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.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Peter Elderson
In reply to this post by John Doe
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 mrt. 2020 om 11:08 schreef John Doe <[hidden email]>:

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/Simpler_public_transport_route_relations



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

John Doe
In reply to this post by Andrew Harvey-3

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 relation via waypoints only if you prefer as a starting point, but then still allow it to be completed via the way members.
> A bit like how most things can be initially mapped as a node but then are usually expanded out into an area.

I'm afraid I'm against that idea, personally. I've mapped nearly 70 bus routes in my city (and counting); I'm still their lone maintainer; I have also dabbled with mapping railway routes. So many relations with so many ways - especially highways, which are the first things newbies edit and thus are the most likely to break a relation - are an enormous maintenance bomb waiting to go off. (And sometimes it does go off, and the fallout goes on for months.)

Besides - while I have never written a router or a renderer - I imagine that having to support both types of relations (PTv3 as well as v2) would create additional technical debt for routers and renderers.

> Secondly I don't quite understand the no way member rule of your proposal, since railways platforms should be a way https://wiki.openstreetmap.org/wiki/Tag:railway=platform [https://wiki.openstreetmap.org/wiki/Tag:railway=platform] then including the platform in the relation means you need to include ways as relation members.

Thank you for pointing that out. The ways it referred to were highways and railways - it has, of course, no objection to platforms as ways or areas. I have reworded the section, hopefully it is clearer.

> On Fri, 6 Mar 2020 at 21:08, John Doe < [hidden email] [mailto:[hidden email]] > 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.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations]
> >
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email] [mailto:[hidden email]]
> > https://lists.openstreetmap.org/listinfo/tagging [https://lists.openstreetmap.org/listinfo/tagging]
> >
>



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

John Doe
In reply to this post by Peter Elderson


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 render instead of just render the route from OSM?

Seems so. Is it a significant burden to include a router with a renderer?

> Vr gr Peter Elderson
>
> Op vr 6 mrt. 2020 om 11:08 schreef John Doe < [hidden email] [mailto:[hidden email]] >:
>
> >
> > 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/Simpler_public_transport_route_relations [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations]
> >
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email] [mailto:[hidden email]]
> > https://lists.openstreetmap.org/listinfo/tagging [https://lists.openstreetmap.org/listinfo/tagging]
> >
>



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Peter Elderson
> 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 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 PT map.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 that is defined by the operator? Keeping as an example the city PT map.

That is something that mappers/maintainers would have to test, as they already do. The difference is that the time and effort required to create and maintain the relation is greatly reduced.

Tangentially, something that might help would be a validator for editors that checks if a route (whether defined by ways or as deduced by a router as we propose) matches user-specified GPS traces.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Peter Elderson
John Doe <[hidden email]>:
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 by the operator? Keeping as an example the city PT map.

That is something that mappers/maintainers would have to test, as they already do. The difference is that the time and effort required to create and maintain the relation is greatly reduced.

Tangentially, something that might help would be a validator for editors that checks if a route (whether defined by ways or as deduced by a router as we propose) matches user-specified GPS traces.

That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? I may be out of my depth, but I think a route for the map is observed and registered, not computed between A, B, C etcetera. A route on the fly is a different thing. 

Would it be an idea to make the route itself (the observed chain of ways) an optional member relation of the PT routing relation? With member role=route?

Of course I would like to have a routing routine built into the relation editor,  which can convert a survey gpx-trace to a route relation containing the closest chain of already mapped ways, that would make route maintenance much easier. (All kinds of routes, not just PT).

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Tagging mailing list
In reply to this post by John Doe

Mar 6, 2020, 15:22 by [hidden email]:

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 relation via waypoints only if you prefer as a starting point, but then still allow it to be completed via the way members.
A bit like how most things can be initially mapped as a node but then are usually expanded out into an area.

I'm afraid I'm against that idea, personally. I've mapped nearly 70 bus routes in my city (and counting); I'm still their lone maintainer; I have also dabbled with mapping railway routes. So many relations with so many ways - especially highways, which are the first things newbies edit and thus are the most likely to break a relation - are an enormous maintenance bomb waiting to go off. (And sometimes it does go off, and the fallout goes on for months.)
And it affects not only people mapping public transport routes. I would gladly put burden on data
users
(assuming that burden for data users is not significantly greater than burden removed from mappers).

I was really happy when some bus routes become invalid and I was able to delete them.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Fernando Trebien
In reply to this post by John Doe
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 limits, surface values) may change
independently, affecting the computed route without changing the PTv3
relation with via points only. Sometimes this would be desirable, I
can imagine that often it would not be.

Perhaps it would make sense to write an editor or a plugin that can
compute route members from a set of via points, which the mapper can
check and sometimes correct before submitting a changeset.

Also, if the PTv3 relation allows including both the route and some
via points, then we'd have a new situation to validate: the existence
of via points outside the route.

On Fri, Mar 6, 2020 at 7:08 AM John Doe <[hidden email]> 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.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging



--
Fernando Trebien

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Tagging mailing list
In reply to this post by Peter Elderson
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.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Phake Nick
In reply to this post by John Doe
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 transit information from around the world into the platform for navigation and suggestion purpose by letting users first pick stop.m locations on a map, then try to automatically display the routing and finally let users correct the routing to complete the public transit route record in thdir database, I would say it's easier said than done to expect a software being able to auto-generate the ways based on station location, even with additional waypoints.
First of all, I don't think there are any existing routing engines for trains on rail or bus or minibuses on street, so they will need to be developed first for renderer to be able to visualize these routes, especially for roads that regular vehicles cannot use. And then, 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 OSM that can be used to represent multiple localized types of transportation, but also because of things like mechanical restrictions of bus models that would not be available in any public document and cannot be verified outside of the public transit company.
Second, when a user map a public transit relation using waypoints to handle a special case, how can they know when a waypoints would be needed? Even if such renderer is built into editor to show which route it would take and let users add waypoints when that's incorrect, different routers used by different renderers might route a route differently, what doesn't need a waypoint on one router maybe different on another router, how can editors know when it is necessary to add a waypoint to show a route correctly? If a new road is being built next to existing road which doesn't affect existing public transit routes, how to preemptively make sure routing engines won't automatically redirected a route to the new road?
Third, way points are more transient than ways. It's more easy for a node to be deleted or replaced when editing geometry than ways. How to maintain integrity of a route geometry when others edit road geometry?

At 2020-03-06 Fri 18:08, John Doe <[hidden email]> 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.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Warin
In reply to this post by Tagging mailing list
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 router.


Why routing is a good idea.


Let us say a route uses 4 ways in sequence.


If those ways are sequentially inside the route then things are fine.


It breaks when


a mapper enters a turn restriction, breaking one of the ways


a mapper enters some road works that close a section of one of the ways


a mapper enters some speed limits that change alone one of the ways


All of these break the route.


If the route is entered as nodes on the intersection of each of the 4
ways then any of the above mapper changes will not brake the route.

The routing engine may not pick the actual replacement route .. but it
should be a reasonable approximation.


----------------------------------------------------------------------------

The above could be the best way forward - it relies on the nodes used
connecting continuous ways together thus leaving the routing engine
little work to do.

When (not if) that rule is broken then it indicates that the route needs
to be checked, but in the mean time the routing engine will maintain the
route in a usable fashion.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Andrew Harvey-3
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.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Peter Elderson
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 waypoints the route itself will be much easier to maintain. If no route member is present, the renderer can approximate using what's in the routing relation.
Same goes for routers. They could use the route as present in the route member, or choose to ignore that and recreate a fresh route along the stops and other waypoints.

Best, Peter Elderson

> Op 6 mrt. 2020 om 23:52 heeft Andrew Harvey <[hidden email]> het volgende geschreven:
>
> 
> 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.
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Joseph Eisenberg
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 on traffic or other reasons

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 follows the same streets and passengers can wave their hand or request a stop anywhere along the route.

These routes, common in Asia, Africa and Latin America, should be mapped just as a set of ways.

So, I support the idea of allowing mappers to just add the bus stops to the relation when this is the most verifiable and easiest to maintain, but there are some cases where this will not work, so it should still be permitted to map the ways for non-fixed-stop services.

I believe the “Refined Public Transport” proposal has already suggested this (mapping route relations as either just stops or just ways) and in general that proposal has good ideas which might be considered: 


- Joseph Eisenberg

On Sat, Mar 7, 2020 at 8:23 AM Peter Elderson <[hidden email]> wrote:
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 waypoints the route itself will be much easier to maintain. If no route member is present, the renderer can approximate using what's in the routing relation.
Same goes for routers. They could use the route as present in the route member, or choose to ignore that and recreate a fresh route along the stops and other waypoints.

Best, Peter Elderson

> Op 6 mrt. 2020 om 23:52 heeft Andrew Harvey <[hidden email]> het volgende geschreven:
>
> 
> 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.
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Richard Fairhurst
In reply to this post by Phake Nick
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/Project-OSRM/osrm-profiles-contrib/blob/master/5/6/bus.lua
etc. etc. etc.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

Paul Allen
In reply to this post by Joseph Eisenberg
On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg <[hidden email]> 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 follows the same streets and passengers can wave their hand or request a stop anywhere along the route.

Rural routes in the UK are often similar, except there are designated stops
(sometimes with a shelter, sometimes just a sign, sometimes unmarked)
along the way.  Most (sometimes all) of the route is "hail and ride."  This
can even happen in small towns (well, at least one town I know of) where
much of the route is also "hail and ride."  In that particular town, some
of the new timetabled stops lack shelter and sign (but that's OK because
that part of the route operates as "hail and ride" anyway).

So, I support the idea of allowing mappers to just add the bus stops to the relation when this is the most verifiable and easiest to maintain, but there are some cases where this will not work, so it should still be permitted to map the ways for non-fixed-stop services.

+1

Not just permitted, but the documentation should explicitly state this.  Not just
for legacy routes (I don't see a mass upgrade happening) but also for new routes.
This must be an alternative, for use where the mapper feels it is easier and/or
gives better results.  Maybe even a preferred alternative, but still just an
alternative.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

John Doe

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 extension to PTv2, falling back to PTv2 (way-based relations) for hail and ride routes. However, Stereo leans towards it replacing PTv2 [1] - routes without fixed stops can easily be represented using only via points and stop positions. A single tag (say, hail_and_ride=yes) on the relation can establish it as such. Nice and simple - hail and ride with no icky way segments 🙂

Now that might suffice for most situations, but I for one liked the flexibility of marking specific sections of a route as hail and ride - I like to mark intersections, for instance, as places where hail and ride vehicles won't stop under normal conditions. To cater to this - _if_ the community considers it worth catering to, because I wouldn't be surprised if some consider it unnecessary micromapping - Stereo suggested making new roles for via points, e.g. begin_hail_and_ride and end_hail_and_ride. This I find somewhat inelegant.

What do you think?

[1] I'm personally quite undecided on this. There are numerous upsides and downsides to both approaches.

07-Mar-2020 19:44:34 Paul Allen <[hidden email]>:

> On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg < [hidden email] [mailto:[hidden email]] > 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 follows the same streets and passengers can wave their hand or request a stop anywhere along the route.
>
> Rural routes in the UK are often similar, except there are designated stops  (sometimes with a shelter, sometimes just a sign, sometimes unmarked)  along the way. Most (sometimes all) of the route is "hail and ride." This  can even happen in small towns (well, at least one town I know of) where  much of the route is also "hail and ride." In that particular town, some  of the new timetabled stops lack shelter and sign (but that's OK because  that part of the route operates as "hail and ride" anyway).
>
> >
> > So, I support the idea of allowing mappers to just add the bus stops to the relation when this is the most verifiable and easiest to maintain, but there are some cases where this will not work, so it should still be permitted to map the ways for non-fixed-stop services.
>
> +1  
> Not just permitted, but the documentation should explicitly state this. Not just  for legacy routes (I don't see a mass upgrade happening) but also for new routes.  This must be an alternative, for use where the mapper feels it is easier and/or  gives better results. Maybe even a preferred alternative, but still just an  alternative.
>
> --
> Paul  
>


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - RFC - Public Transport v3

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 are not added by most mappers for bus routes. Routing
apps can easily calculate the location where the bus stops based on
the location of the "highway=bus_stop" next to the way.

Creating "via points" seems more cumbersome than adding the highway
ways to the relation when the route is "hail-and-ride", especially
since a via point would not represent a real-world feature in that
case.

I understand why user Stereo would like a clean, simple solution. But
realistically, both mapping methods are going to co-exist (this is
already the case).

It is most likely to be accepted if the proposal does not attempt to
call anything "deprecated" or force anyone to use the new mapping
style.

It would be enough to say that "adding all the bus stops or platforms
and all the highway or rail ways to the relation is not necessary, one
or the other is enough", and for database users to be prepared for
handling both types of route.

- Joseph Eisenberg

On 3/8/20, John Doe <[hidden email]> wrote:

>
> 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 extension to PTv2,
> falling back to PTv2 (way-based relations) for hail and ride routes.
> However, Stereo leans towards it replacing PTv2 [1] - routes without fixed
> stops can easily be represented using only via points and stop positions. A
> single tag (say, hail_and_ride=yes) on the relation can establish it as
> such. Nice and simple - hail and ride with no icky way segments 🙂
>
> Now that might suffice for most situations, but I for one liked the
> flexibility of marking specific sections of a route as hail and ride - I
> like to mark intersections, for instance, as places where hail and ride
> vehicles won't stop under normal conditions. To cater to this - _if_ the
> community considers it worth catering to, because I wouldn't be surprised if
> some consider it unnecessary micromapping - Stereo suggested making new
> roles for via points, e.g. begin_hail_and_ride and end_hail_and_ride. This I
> find somewhat inelegant.
>
> What do you think?
>
> [1] I'm personally quite undecided on this. There are numerous upsides and
> downsides to both approaches.
>
> 07-Mar-2020 19:44:34 Paul Allen <[hidden email]>:
>
>> On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg < [hidden email]
>> [mailto:[hidden email]] > 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 follows the same streets and passengers can wave
>> > their hand or request a stop anywhere along the route.
>>
>> Rural routes in the UK are often similar, except there are designated
>> stops  (sometimes with a shelter, sometimes just a sign, sometimes
>> unmarked)  along the way. Most (sometimes all) of the route is "hail and
>> ride." This  can even happen in small towns (well, at least one town I
>> know of) where  much of the route is also "hail and ride." In that
>> particular town, some  of the new timetabled stops lack shelter and sign
>> (but that's OK because  that part of the route operates as "hail and ride"
>> anyway).
>>
>> >
>> > So, I support the idea of allowing mappers to just add the bus stops to
>> > the relation when this is the most verifiable and easiest to maintain,
>> > but there are some cases where this will not work, so it should still be
>> > permitted to map the ways for non-fixed-stop services.
>>
>> +1
>> Not just permitted, but the documentation should explicitly state this.
>> Not just  for legacy routes (I don't see a mass upgrade happening) but
>> also for new routes.  This must be an alternative, for use where the
>> mapper feels it is easier and/or  gives better results. Maybe even a
>> preferred alternative, but still just an  alternative.
>>
>> --
>> Paul
>>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12345