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


_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit

Reply via email to