[Tagging] Feature Proposal - RFC - Public Transport v3
pelderson at gmail.com
Mon Mar 9 13:18:08 UTC 2020
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
best serves their purpose.
Best, Peter Elderson
Op ma 9 mrt. 2020 om 12:50 schreef Paul Allen <pla16021 at gmail.com>:
> On Mon, 9 Mar 2020 at 00:18, Joseph Eisenberg <joseph.eisenberg at gmail.com>
>> > 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 make changes lightly.
> Given that iD still seems to scramble sorted routes in some circumstances,
> should not assume that editors will correctly handle any changes we make.
> 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.
>> But this should not prevent us from making a change which would make
>> things easier for mappers and might better represent reality.
> Given recent comments on the proposal's talk page, I doubt it will better
> represent reality because it's the router that determines the fine details.
> Maybe it will go for shortest path, or fastest path, or something else.
> Maybe at some future date it will switch from shortest path to fastest
> path. Yes, there are vias, but read on.
> For a long-distance inter-city route where the bus only stops at official
> this might be good enough for many people. The router may or may not
> guess the exact route between two stops, but it's close enough for some
> people. Not for me, because I worry when a bus I'm on isn't following
> the route I thought it would. Maybe I'm on the wrong bus. Maybe the
> route has changed and it's not going to stop where I want to get off. I
> want to see exact routes, not close approximations.
> The county I live in is the second-most sparsely populated county in
> Wales and has an area of 1,795 square km (693 sq mi). Just about
> every route is hail and ride. Even the routes in the towns (and the
> one city) are hail and ride except in small sections where the road
> configuration would make it unsafe to stop. In these cases,
> knowing the exact route is vital: otherwise you'll be waiting
> for a bus where the router thinks it goes instead of where it
> actually goes. Yes, there are vias, but read on.
>> Greater ease of mapping is a strong reason to consider changes to
>> editor applications.
> Is it actually easier? For the "long-distance, few official stops, only
> at official stops" routes, maybe. For any route in my county I'll have
> to insert vias to make sure hail and ride buses (almost all of them) are
> mapped as going where they actually go. It means I have to spend time
> thinking like a router, anticipating alternate routes between any adjacent
> junctions and insert a via where a router might possibly come up with
> the non-factual answer. Sorting additional vias into place is going to
> be almost as tedious as re-sorting existing relations of ways that
> get scrambled.
> However carefully I place the vias (and check the calculated route to see
> it's right, some change to the roads which doesn't affect the route the bus
> actually takes may cause the mapped route to be wrong until one or more
> new vias are inserted. A new housing estate with two connections to
> the existing road system could cause the bus to be re-routed. Fine if
> the person adding the estate takes care to check nearby bus routes.
> A change to the speed limit on a way may cause the router to decide
> on a different route. Etc.
> Adding ways to create a relation is mechanical and tedious but requires
> little thought. Guessing where one might have to insert vias that will
> not only with whatever router is used to generate the carto but all future
> algorithms that router might use requires a lot of thoughtful
> consideration of
> potential alternative routes. Or I can avoid thought by placing a via at
> every node along the route, which is more tedious than just adding ways.
> In some cases this proposal might be easier, in others (the ones I deal
> with) a
> lot harder. 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
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging