<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Paul,<div class=""><br class=""></div><div class="">You talk a lot about ‘thinking like a router’. Of course you’d have the route shown in your editor. Try <a href="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" class="">this demo</a> to get a rough idea. It even has a ‘create relation in josm’ button at the bottom left.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Guillaume<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 10 Mar 2020, at 15:24, Paul Allen <<a href="mailto:pla16021@gmail.com" class="">pla16021@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">On Tue, 10 Mar 2020 at 07:55, John Doe <<a href="mailto:music.kashish@gmail.com" class="">music.kashish@gmail.com</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
> <br class="">
> 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.<br class="">
> <br class="">
<br class="">
<br class="">
Could you please try to replicate that and report it to the iD developers? Sounds like a pretty serious bug, if it is that.<br class=""></blockquote><div class=""><br class=""></div><div class="">To replicate it I'd have to remove the spur, then sort the route (very, very slow</div><div class="">and tedious) then add the spur back. And then get nowhere because I appear</div><div class="">to be on the iD developer ignore list (I know others are on such a list because</div><div class="">iD developers proudly stated it). It was only a year or two ago that iD</div><div class="">developers stated that it was impossible to keep the order of ways in a</div><div class="">relation when retrieving it from the server, at a time when JOSM had no</div><div class="">problem doing so. Now iD protects route relations if you try to break the</div><div class="">relation and doesn't scramble them as much as it used to. Maybe in</div><div class="">another couple of years...<br class=""></div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">The fact that this scheme relies upon the decisions made by an arbitrary router</div><div class="">using algorithms that could change and weighting factors that could change, it</div><div class="">seems impossible to guarantee even a close approximation to canonical routes,</div><div class="">even with plentiful vias.<br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> A new housing estate with two connections to the existing road system could cause the bus to be re-routed.<br class="">
<br class="">
Sounds a little odd - would a router really route a bus on a highway=residential or highway=service?<br class=""></blockquote><div class=""><br class=""></div><div class="">As somebody else mentioned, bus routes in towns deliberately pass through</div><div class="">residential areas along highway=residential. I think a problem here is that you're</div><div class="">more familiar with long-distance routes than urban routes. What makes sense</div><div class="">for long-distance routes doesn't make much sense for urban routes.<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
But, be that as it may, your response helped me see two things -<br class="">
1. It will be helpful to have a route visualizer in editors that can preempt ambiguities.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yeah, but the editor will need its own router (not a trivial addition) which will</div><div class=""> almost certainly differ in the algorithm and weightings from the router used by the</div><div class="">renderer. It's likely that what the editor shows will not be what the renderer</div><div class="">shows.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Hail and ride routes longer than last-mile services really do suffer under this schema.<br class=""></blockquote><div class=""><br class=""></div><div class="">Urban routes suffer under this scheme, whether hail and ride or not. It's just that</div><div class="">not having the canonical route when there are hail and ride sections is a</div><div class="">serious problem. Being on an urban bus that isn't following the route the map</div><div class="">says it does is not as serious, but still a problem.<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
> 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.<br class="">
<br class="">
I reiterate that I initially wanted it to be just that - an additional way to map.</blockquote><div class=""><br class=""></div><div class="">I'll support the scheme if it is an alternative way to map. I probably won't use it</div><div class="">as the few longer routes around this mostly rural county are mainly hail and ride</div><div class="">outside the downs and often hail and ride within the towns. If it is proposed as</div><div class="">a replacement scheme I'll have to vote against it.<br class=""></div><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Which gives me the following idea - would it help you if only routes with hail_and_ride=yes were permitted to have ways?</blockquote><div class=""><br class=""></div><div class="">Nope. Because that is still undesirable for urban routes in general. If I get on a</div><div class="">bus for the first time and compare where it is to the route shown on a map then</div><div class="">I get seriously worried if the two do not match and start wondering if I'm on the</div><div class="">wrong bus. Actually, I'd be just as worried if I were on a long-distance route,</div><div class="">but have to live with the fact that those are said to be hard to map with existing</div><div class=""> schemes.<br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br class=""></blockquote><div class=""><br class=""></div><div class="">For urban routes, vias ARE the nuisance. Because you force me to think like</div><div class="">a router. In fact, not just one router but several routers, each using different</div><div class="">algorithms and weightings. I have to anticipate where any of those routers</div><div class="">MIGHT get it wrong and insert vias to prevent that. Until somebody adds a</div><div class="">housing estate with a through road, or the speed limit changes on an existing</div><div class="">road, or something else changes that causes the router to decide on a different</div><div class="">route.<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
(Routes with hail_and_ride=yes could still opt to omit ways and use points, which would be better for shorter routes.)<br class=""></blockquote><div class=""><br class=""></div><div class="">Nope. Points aren't (in my opinion) better for short routes. Ways are actually</div><div class="">easier for me to add (it's slow, and tedious, but I don't have to think like a router</div><div class="">and anticipate where things might go wrong if I don't insert a via).<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">Actually, some passengers DO care about the intricacies of a long-distance route.</div><div class=""> If the map shows a route from a stop at A to a stop at E, passing through (but not</div><div class="">stopping at) B then I get damned worried if the bus avoids B and instead passes</div><div class="">through C. Am I on the wrong bus? Has the route changed and, if so, does it</div><div class="">still stop at E? From my perspective, having the wrong (non-canonical) route</div><div class="">on a map is worse than not having the route on the map.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">That sounds like the confident opinion of somebody who has never mapped such a</div><div class="">route. One who has never encountered two towns which have two routes between</div><div class="">them: one shorter and one faster. One who has supreme confidence that a router</div><div class="">is going to guess right.</div><div class=""><br class=""></div><div class="">Here's a thought for you, since editors would have to build in a routeing module</div><div class="">for verifiability. Don't adopt this new proposal. Instead, come up with editor</div><div class="">modules that can be fed a series of stops and vias, propose a route connecting</div><div class="">them and, if the mapper agrees, automatically add all the necessary ways to</div><div class="">a PTV2 relation. In some cases ways would need to be split (as is the case</div><div class="">now) but the editor could flag up a "This route cannot be defined unless a</div><div class="">split is placed here" error.</div><div class=""><br class=""></div><div class="">-- <br class=""></div><div class="">Paul</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- <br class=""></div><div class="">Paul</div><div class=""><br class=""></div></div></div>
_______________________________________________<br class="">Tagging mailing list<br class=""><a href="mailto:Tagging@openstreetmap.org" class="">Tagging@openstreetmap.org</a><br class="">https://lists.openstreetmap.org/listinfo/tagging<br class=""></div></blockquote></div><br class=""></div></body></html>