[Talk-transit] Summary of Public Transport Proposal Criticism

Richard Mann richard.mann.westoxford at gmail.com
Mon Jan 24 13:09:24 GMT 2011


On Mon, Jan 24, 2011 at 11:40 AM, Christian <christian at balticfinance.com> wrote:
> but it also includes people ... who would like to map also
> physical path a bus takes on the street.

I think there's a logic in encouraging the use of ordered relations to
show the paths of bus/etc routes - because this makes the data more
browsable/maintainable. I think there's also a logic in putting
branches in separate relations, for the same reason. If there are lots
of branches that share a ref (or don't have refs), it's probably
easier however to leave them bundled together.

You'd hope that data users might make reasonable sense of data with
errors/gaps in it, but it's good to harness the mapper's ability to
look at maps/diagrams, spot the error and fix it.

So I'd go for a little more order than Michal is proposing, but I'd
agree that we need to keep it as simple as we can, with the "advanced"
stuff used strictly only when necessary, and only to the extent that
is necessary.

On the general issue of when to use stop areas - if the raw distance
is sometimes inappropriate, then we should mark these as exceptions,
not mark everything. You don't even really need to group all the
objects on either side of the "barrier", as long as there are
different names (+?network) on each side of the barrier - simply link
one object on each side, and let the data user join up the rest using
the name tag. So for instance, there might be a relation linking the
Charing Cross station node to the Embankment station node, giving a
minimum walking time. Contrariwise, you might have another relation
linking Bank and Monument, advising that a penalty for going via
surface level is inappropriate. (With apologies to those of you
unfamiliar with the intricacies of the London Underground)

Richard



More information about the Talk-transit mailing list