[Talk-transit] Summary of Public Transport Proposal Criticism

[Michał Borsuk]

On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote:
> I try to seperate the criticism from the spam around my proposal:
>
> - stop_area is not needed/too complicated:
> [...]And it does not seam to be too complicated,

We have so many advanced issues in comparison to the total number of PT 
objects because we have a pitiful total number of PT objects on the map. 
If we keep, or even increase, the level of complication, then the map 
will not gain new mappers.

And as for "not needed": can we have a *separate discussion* on how 
routing works? There had already been voices that stop_area  isn't 
really necessary, and while I don't claim to be pro in routing software, 
I am pretty sure we don't need them. I could elaborate, but not in this 
thread. The problem is our admin is overwhelmed, and seemingly doesn't 
past new threads.

So why keep something that is essentially neither part of the map (map 
shows location of objects, not their relation), nor part of the routing 
algorithm?


> - route directions/variants is not needed:
> In urban regions it is common that a bus line has different routes for
> the both directions (often one way).


This doesn't matter as OSM itself is not routing software.

While coming up with an alternative I actually realized that roles are 
only needed on bus stops (in HAFAS system, and not at all in most North 
American systems), in order to make two bus stops with the same stop_id 
unique.


> The more exact the OSM map is, the
> more likely it is that the two directions do not share the same way for
> the both directions (the lines of one street are split up).

Again, this is not an argument as OSM is not a routing software, but a map.

> - route directions/variants is too complicated:
> My opinion is: The roles forward/backward in the current tagging schema
> is complicated and very, very error-prone.

Then let's drop them altogether. One relation for one timetable route, 
no matter how complicated it is. The rest will be (and can be) dealt 
with by the middle layer of software that will hopefully eventually deal 
with routing.


> Each of the three editors have their advantages and disadvantages. None
> of the editor is the reference implementation. The reference is the API.

The real reference is the use of editors. You can't simply produce 
something, and then count/expect that it will be implemented. That way 
you will create a beautiful piece of law, with horrible usability.

> If potlatch should be an editor for everything,the authors of potlatch
> should see it as an obligation to implement support for nested relations

What authors of Potlatch should see is immaterial here. We are their 
slaves, because Potlatch is used by entry-level users, who hopefully 
would do a large part of the work that is now done by pros, leaving the 
pros to do things that beginners cannot, or should not do.

Surely we do not have to shape the proposal towards 100% Potlatch 
compatibility, but let's finally talk about what is entry-level stuff, 
and what is not. I propose that the creation of bus, tram, trolleybus 
and S-Bahn/stadtbahn lines be considered entry-level, and so be the 
creation of bus stops.


LMB