[Tagging] Feature Proposal - RFC - Public Transport v3

Guillaume Rischard openstreetmap at stereo.lu
Wed Mar 11 16:55:11 UTC 2020


Paul,

You talk a lot about ‘thinking like a router’. Of course you’d have the route shown in your editor. Try this demo <https://webertest.fix.lu/?hl=en&alt=0&srv=0&loc=49.5165995,6.1020931&loc=49.5195552,6.1100109&loc=49.520066,6.114699&loc=49.5241325,6.1299225&loc=49.5274712,6.1328087&loc=49.5353465,6.1455211&loc=49.5372618,6.1452036&loc=49.541159,6.1454689&loc=49.5451328,6.1499193&loc=49.5483431,6.1510445&loc=49.5649046,6.1620726&loc=49.5677726,6.1610153&loc=49.5716992,6.1598965&loc=49.5734203,6.1573573&loc=49.5773809,6.153793&loc=49.5818253,6.148601&loc=49.5859825,6.1438605&loc=49.5914094,6.1405085&loc=49.5935995,6.1387638&loc=49.5951199,6.1355301&loc=49.5999267,6.133256&loc=49.6117728,6.1259301&loc=49.6156404,6.1268042&loc=49.6183457,6.1360131&loc=49.6212951,6.1396874&loc=49.6248014,6.1460285&loc=49.6272599,6.1518127&loc=49.629436,6.1571237&loc=49.6325723,6.1614057&loc=49.6357697,6.16923&loc=49.6359979,6.1759964&loc=49.6157549,6.209491&loc=49.6170374,6.2159632&loc=49.6161134,6.2200392&loc=49.615585,6.2223808&loc=49.6147628,6.2170908&loc=49.6131148,6.2115943> to get a rough idea. It even has a ‘create relation in josm’ button at the bottom left.

You also accuse John of not having mapped bus routes. While the conversation should be about the tagging scheme itself, it’s worth noting that he’s mapped most of Delhi, and I’ve mapped most of Luxembourg, supported mappers and turned the data into maps for bus companies. We have intimate familiarity with production and consumption of PTv2, and are not tagging astronauts who comment from very far away.

Guillaume

> On 10 Mar 2020, at 15:24, Paul Allen <pla16021 at gmail.com> wrote:
> 
> On Tue, 10 Mar 2020 at 07:55, John Doe <music.kashish at gmail.com <mailto:music.kashish at gmail.com>> 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 before I added a spur, so maybe somebody else doing something that didn't directly affect the route using another editor scrambled it.
> > 
> 
> 
> Could you please try to replicate that and report it to the iD developers? Sounds like a pretty serious bug, if it is that.
> 
> To replicate it I'd have to remove the spur, then sort the route (very, very slow
> and tedious) then add the spur back.  And then get nowhere because I appear
> to be on the iD developer ignore list (I know others are on such a list because
> iD developers proudly stated it).  It was only a year or two ago that iD
> developers stated that it was impossible to keep the order of ways in a
> relation when retrieving it from the server, at a time when JOSM had no
> problem doing so.  Now iD protects route relations if you try to break the
> relation and doesn't scramble them as much as it used to.  Maybe in
> another couple of years...
>  
> While many others have, in the process of this proposal, questioned the need to map exact routes at all (given the presence of platforms), I have always wanted to map canonical routes as closely as I can.
> 
> The fact that this scheme relies upon the decisions made by an arbitrary router
> using algorithms that could change and weighting factors that could change, it
> seems impossible to guarantee even a close approximation to canonical routes,
> even with plentiful vias.
> 
> > 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?
> 
> As somebody else mentioned, bus routes in towns deliberately pass through
> residential areas along highway=residential.  I think a problem here is that you're
> more familiar with long-distance routes than urban routes.  What makes sense
> for long-distance routes doesn't make much sense for urban routes.
> 
> But, be that as it may, your response helped me see two things -
> 1. It will be helpful to have a route visualizer in editors that can preempt ambiguities.
> 
> Yeah, but the editor will need its own router (not a trivial addition) which will
> almost certainly differ in the algorithm and weightings from the router used by the
> renderer.  It's likely that what the editor shows will not be what the renderer
> shows.
> 
> 2. Hail and ride routes longer than last-mile services really do suffer under this schema.
> 
> Urban routes suffer under this scheme, whether hail and ride or not.  It's just that
> not having the canonical route when there are hail and ride sections is a
> serious problem.  Being on an urban bus that isn't following the route the map
> says it does is not as serious, but still a problem.
> 
> > Which is fine if they're alternative ways of mapping bus routes. But the proposers seem to want to make this the one and only way of doing things.
> 
> I reiterate that I initially wanted it to be just that - an additional way to map.
> 
> I'll support the scheme if it is an alternative way to map.  I probably won't use it
> as the few longer routes around this mostly rural county are mainly hail and ride
> outside the downs and often hail and ride within the towns.  If it is proposed as
> a replacement scheme I'll have to vote against it.
> 
> Which gives me the following idea - would it help you if only routes with hail_and_ride=yes were permitted to have ways?
> 
> Nope.  Because that is still undesirable for urban routes in general.  If I get on a
> bus for the first time and compare where it is to the route shown on a map then
> I get seriously worried if the two do not match and start wondering if I'm on the
> wrong bus.  Actually, I'd be just as worried if I were on a long-distance route,
> but have to live with the fact that those are said to be hard to map with existing
> schemes.
>  
> For selective hail and ride, we can use the via roles as currently written in the proposal. That lets you use ways where they are most important (longer, completely hail and ride routes), and keeps them out of where they're a nuisance.
> 
> For urban routes, vias ARE the nuisance.  Because you force me to think like
> a router.  In fact, not just one router but several routers, each using different
> algorithms and weightings.  I have to anticipate where any of those routers
> MIGHT get it wrong and insert vias to prevent that.  Until somebody adds a
> housing estate with a through road, or the speed limit changes on an existing
> road, or something else changes that causes the router to decide on a different
> route.
> 
> (Routes with hail_and_ride=yes could still opt to omit ways and use points, which would be better for shorter routes.)
> 
> Nope.  Points aren't (in my opinion) better for short routes.  Ways are actually
> easier for me to add (it's slow, and tedious, but I don't have to think like a router
> and anticipate where things might go wrong if I don't insert a via).
> 
> 1. "long-distance [interstate?], few official stops, only stops at official stops" - this proposal doesn't merely 'work' for them, it is absolutely essential for them - one only has to try creating a route relation for a national train to know why 😄 I agree with you that passengers in those situations don't care about the intricacies of the route as long as the stops are being served and the ETAs are more or less accurate.
> 
> Actually, some passengers DO care about the intricacies of a long-distance route.
>   If the map shows a route from a stop at A to a stop at E, passing through (but not
> stopping at) B then I get damned worried if the bus avoids B and instead passes
> through C.  Am I on the wrong bus?  Has the route changed and, if so, does it
> still stop at E?  From my perspective, having the wrong (non-canonical) route
> on a map is worse than not having the route on the map.
> 
> 2. This also works well for "intra-city, many official stops, only stop at official stops". The stops are so frequent that you probably won't need to add any via points in most cases.
> 
> That sounds like the confident opinion of somebody who has never mapped such a
> route.  One who has never encountered two towns which have two routes between
> them: one shorter and one faster.  One who has supreme confidence that a router
> is going to guess right.
> 
> Here's a thought for you, since editors would have to build in a routeing module
> for verifiability.  Don't adopt this new proposal.  Instead, come up with editor
> modules that can be fed a series of stops and vias, propose a route connecting
> them and, if the mapper agrees, automatically add all the necessary ways to
> a PTV2 relation.  In some cases ways would need to be split (as is the case
> now) but the editor could flag up a "This route cannot be defined unless a
> split is placed here" error.
> 
> -- 
> Paul
> 
> 
> -- 
> Paul
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200311/0524bfc4/attachment-0001.htm>


More information about the Tagging mailing list