[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