[Talk-transit] All about bus stops
list.osm at hughbris.com
Fri Jan 9 13:11:24 GMT 2009
On Fri, 9 Jan 2009 09:12:01 +0000
Shaun McDonald <shaun at shaunmcdonald.me.uk> wrote:
> On 9 Jan 2009, at 00:59, Corey Burger wrote:
> > Hey all,
> > * Beside way or in way
> > The current consensus seems to be to put it on the side. Make
> > routing difficult, but I suppose if we make all sidewalks footways,
> > then that would solve the issue.
> They should be beside the way, like post boxes, phones, atms and
> bicycle parking. If you do the routing right, it shouldn't be a
Beside is the only logical way. I make the way and the bus stops
members of the route relation. I have never done routing algorithms,
but I imagine this is enough to go on. If relations aren't ordered, we
are in trouble. I really disliked that stop_1 nonsense suggested on the
Worst case, a relation could be used to help snap the stop to the road
> > * Shelters, benches and schedules
> > All of these things are amenities that may exist at a bus stop.
> > Should we adopt the namespacing that the piste mapping people are
> > using? This would mean that we would have things like
> > bus_stop:shelter=yes and bus_stop:bench=yes. Schedules can also
> > just show the list of times, a map or even an electronic sign. How
> > do we want to tag each?
I have been experimenting with this scheme, completely on my own:
I'm not wedded to the key names (or even namespacing, though I see no
problem with it) or the value literals, it's just about the concepts
and meaning. The keys and values can all be globally replaced if need
> I have seen some people tagging the shelter as shelter=yes
Yes, and it's been pointed out to me that I should use conventional OSM
tags where available. Others are lit=*, amenity=rubbish_bin,
It was actually suggested I should tag these as separate nodes, but I
don't agree. I figure the bin/light/bench/shelter is there because the
stop is there most times. If they remove the stop, those features will
go with it. Sometimes rubbish bins just happen to be nearby, which is
when I should probably create a separate node.
Aren't we going to run into a problem with the no duplicate keys rule
if we apply more than one amenity=* tag? (I keep saying that constraint
is a dud).
> I think that we could put the schedule frequencies into the route
I think Corey meant just tagging the presence of a schedule at the
> > * Bus routes that stop at the stop
> > We can either tag them on the stop or add them to the route
> > relation. I favour the latter, as it makes it easier to change
> > stops.
> I also favour the later as you can then find out exactly which
> streets that the bus goes along. In 0.6 relations become ordered,
> which means that you will be able to determine the order of the roads.
> > Anything else?
I did up a datasheet in ODF for recording these features. I thought it
would speed up my note taking (sometimes I do this from buses).
Unfortunately, it isn't proving very efficient, but it does show me
what I did and didn't remember to note. My old system used symbols. I
continue to do that when I am without my datasheets. If I ever have
success with the datasheet, I'll be sure to share it.
More information about the Talk-transit