[Talk-transit] NEW Proposed Feature

Michał Borsuk michal.borsuk at gmail.com
Fri Jan 14 12:30:01 GMT 2011


Am 14.01.2011 12:46, schrieb ant:
> 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 :)
So late because I tried to get others, who are valuable mappers for 
sure, to see that the proposal is going the wrong way.
> 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.
You're welcome.
> 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).
But is it really? I am stuck with the mapping of buses, so frankly I 
don't have the overview of how trams are mapped, but many issues raised 
here are really important.

But if this IS really an issue, how about treating tram where it doesn't 
have a right of was as a bus, and where it operates on separate track, 
as a train? This will be confusing to new users IF they don't read the 
manual (they will see two seemingly different systems for one tram 
line), but this has a valuable advantage: it fits the German Stadtbahn 
  - Karlsruhe mode anybody? Where a vehicle (not a train, not a tram) 
enters both the street network, and regular railway network? (this is 
not limited to Karlsruhe, this is indeed a big thing in Germany, the 
tram networks of many cities are connected by sections of old railways 
converted into this half-train-, half-tram). This would possibly also 
keep some sort of compatibility.

Disadvantage: messy to implement two standards on one line.

>
> One suggestion here is to focus on the platform/pole and to scrape the 
> on-way nodes completely (e.g. Richard's last post). 
I've implemented it before I knew of the entire mess with two competing 
standards. It wasn't my decision, somebody told me that "we map bus 
stops where they are physically". I also thought along these lines: OSM 
has a higher resolution than the existing maps, so a stop position in 
the centre of the street isn't representative enough.

>
>     * highway=bus_stop beside the way causes extra preprocessing for 
> routing software.
>
> True, but something the data collectors don't have to deal with?
True but unimportant. And besides, isn't it already a standard to add 
bus stops to the bus route? I've been doing so.
>
>     * 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.
Again, how about roles? Why don't we try to use them? it seems that they 
have been largely abandoned. But from the point of view of a non-geek 
roles are easier to grasp than separate routes. Again, how do you copy a 
route in Potlatch? Sorry to repeat myself, but how is it that Potlatch 
is universally ignored, whereas it's the entry-level tool that almost 
everybody uses?

> Even invariant lines become challenging for beginners, because the 
> concept of forward and backward roles is really difficult to grasp. 
I may have got it wrong, but on a simple line from A to B, with 
bus_stops serviced in both directions (a good majority of lines), I 
don't see any use of the roles. I have the information that "here, at 
this bus stops you have bus 105", and that's all I need now. I've used 
roles on lines that have different paths, and with the scarse 
information "out there", I managed to understand it, so again, we need

Actually, you made me just realize that by doing that (not 
adding "forward" and "backard" to stops) I ignored the direction 
iformation, which would be useful to the disabled, but indeed that's a 
lot of work.

> What's wrong with multiple, non-nested relations? - I'm not saying we 
> need a route master.
1. weak point in case of rerouting: a beginner may move only one route; 
more work
2. lack of the option to duplicate a route in the entry-level software
3. lack of the need in the majority of cases (other cases: roles should 
be enough*)
4. incompatibility with present mapping standards, I mean printed maps 
-> two routes per line may seem strange to beginners

As for roles vs. two relations (3.), I mean to introduce arbitrary roles 
for "legs" of strange bus/tram lines. Let the user call the "leg" where 
a bus calls on Sunday mornings "Sunday morning service only". This is 
pefectly enough for the rendering software, and as for routing software, 
I've expressed my doubts (but it should be also enough - those roles can 
be indexed).

HTH.

Greetings,

-- 

Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,

Michał Borsuk




More information about the Talk-transit mailing list