On Mon, Jan 24, 2011 at 11:40 AM, Christian <[email protected]> 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 _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
