[Talk-transit] NEW Proposed Feature

ant antofosm at gmail.com
Fri Jan 14 11:46:44 GMT 2011


Hi,

On 14.01.2011 09:58, Michał Borsuk wrote:
> How about you, and the few of us who understand why the proposal is a
> mere nonsense, develop a better proposal? We seem to share the
> understanding of the flaws; a new proposal may lead to a secession,
> which is the ugliest thing possible, but I am not sure we can continue
> to improve the current proposal.

Finally, that sounds much more like positive criticism :)
By the way, thanks Michał, for pointing out details of the routing 
techniques that I obviously got wrong. Now let's see how we can tackle 
the issues we have.

Main Problem with the existing Schema (these are copied from the proposal)

     * Inconsistent handling of railway=tram_stop / railway=halt (node 
on the way) and highway=bus_stop (node beside the way).

One suggestion here is to focus on the platform/pole and to scrape the 
on-way nodes completely (e.g. Richard's last post). Are there other 
suggestions? I agree that the platforms are more crucial than anything 
else (because of pedestrian routing), but how to integrate the widely 
used tram stop centroids into the proposal?

     * highway=bus_stop beside the way causes extra preprocessing for 
routing software.

True, but something the data collectors don't have to deal with? I think 
it depends. Example: If a housenumber is located exactly on the corner 
of two streets (and no street name attached to it), an algorithm could 
only guess which street it belongs to. Probably similar ambiguities are 
possible for bus stops as well (even if only in a very few cases). My 
opinion: we should require no stop position nodes neither stop area 
relations for simple and clear cases. But we should have a solid scheme 
at hand just in case we need them.

     * No separate tags for stop position and platform / pole.

Have been proposed.

     * Insufficient possibility for line variants for bus lines.

Mapping variants of PT lines is indeed close to impossible if people 
still enforce the "one relation for one line" mantra. Even invariant 
lines become challenging for beginners, because the concept of forward 
and backward roles is really difficult to grasp. What's wrong with 
multiple, non-nested relations? - I'm not saying we need a route master.

Opinions please...

cheers
ant



More information about the Talk-transit mailing list