On 23 Apr 2008, at 17:45, Peter Miller wrote: > The EU standard Transmodel defines a Stop Point as 'A POINT where > passengers > can board or alight from vehicles'. For bus stops this means a > single pole, > shelter etc and for a place where there are three poles for different > services close together then there would be three entries. > > There are also places where buses stop where there is no physical > infrastructure but where buses stop which also need Stop Points. In > rural > areas there might be a pole on one side of the road but buses stop > in both > directions, or in some places there is not infrastructure on either > side of > the road. > > For there are a number of Stop Points close to each other then these > can be > grouped into Stop Areas that are 'A group of STOP POINTs close to each > other'. I suggest that we achieve this with a relationship call a > 'Stop > Area' is people are keen to model it. >
I know that Google models the bus stops as being on either side of the road. Personally, I believe that it is better to have one node per bus stop, even if they are close together in each direction. There is also a hailer zone, where there are no bus stops specifically. The driver just stops where it is safe to do so and passengers need to get on and off. > For railway stations it can get more complicated as a platform can > be made > up of sub platforms (long trains stop at platform 4 and two short > ones can > stop at 4A and 4B etc). In this case I believe there should be a > Stop Point > for 4, 4A and 4B. > http://www.transmodel.org/en/transmodel/gloss/s.htm > Train platforms are so long that I think that they should be modeled as a way parallel to the railway line as rail=platform. I have done this for Stirling Station, and Edinburgh Park in West Edinburgh, if I remember correctly. This also means that you can model how you get on to and from the station platforms. It's all very well seeing a station there as a dot, but at high zoom you need to know how to get there from the surrounding roads. > This interpretation is now being discussed as ISO level so is > probably the > one to go with. > > Are we agreed that this is the appropriate interpretation for the > feature > going forward. In which case shall I add this clarification and > interpretation to the relevant OSM tag page? > > Btw, Someone might like to ask the DfT in the UK at some point for a > copy of > the DB they have with the location of over 350,000 bus stops with > their > names and the name of the associated street. I know the people but > it might > be better if it came from someone else, possibly from the foundation? > Go ahead and ask. Watch though as the data might be tainted, as it may be derived from ordanance survey data. > > > Regards, > > > > > Peter > > >> Date: Wed, 23 Apr 2008 20:03:14 +0900 >> From: "Jeffrey Martin" <[EMAIL PROTECTED]> >> Subject: Re: [OSM-talk] Bus Stops >> To: "Mike Collinson" <[EMAIL PROTECTED]> >> Cc: talk@openstreetmap.org >> Message-ID: >> <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> How am I supposed to do bus stops? >> If two bus stops are on opposite sides of the road then I think >> maybe they >> can share a node? >> >> I found in some email that you can make little short service links. I >> don't >> like that. The bus >> pulls over to the side of the road where I'm at. >> >> Sometimes they aren't exactly across the street from each other. >> >> Where I'm at there are lots of wood and concrete bus shelters. >> >> On Sun, Aug 12, 2007 at 12:07 AM, Mike Collinson <[EMAIL PROTECTED]> >> wrote: >> >>> Excellent background information for basing our models. Thank you >> Peter. >>> >>> Mike >>> >>> >>> At 07:21 AM 11/08/2007, Peter Miller wrote: >>> >>> The conventional way of handling Bus Stops in the public transport >>> industry is to have a node for each individual point at which one >>> can >> get on >>> a vehicle, so if there are two bus stops on opposite sides of the >>> road >> then >>> they are represented as two nodes. If there are three bays in a >>> row on >> one >>> side of the road then they are represented a 3 nodes in a row. >>> Every Bus >>> Stop in the UK has a unique code, and this is sometimes printed on >>> the >> bus >>> stop itself. >>> >>> In the EU standards they are called 'Stop Points' (rather than Bus >> Stops) >>> so they can cover buses, tram, rail, ferry planes etc. >>> >>> In railway stations there is a Stop Point for each Platform (and >>> each >> bay >>> in a bus station, each Gate for an Airport and each quay in a Ferry >>> terminal). >>> >>> Groups of local Stop Points (as they are called) are then arranged >>> into >>> Stop Areas where they are very close to each other. >>> >>> These Stop Points are not within the road layer because Stop >>> Points are >> a >>> distinct dataset managed separately; they are then associated with a >> street, >>> sometimes using the Street Name and sometimes based on proximity. >>> >>> I recommend that we use 'Bus Stop' and 'Stop Point' for this low- >>> level >>> purpose and construct entities as we need them. >>> >>> The database of all these points in the UK is called >>> 'NaPTAN' (standing >>> for 'National Public Transport Access Nodes'), there are about >>> 350,000 >> of >>> them, and keen people can find additional information here: >>> http://www.naptan.org.uk/ >>> >>> >>> A new CEN standard is in the process of being ratified, called IFOPT >> which >>> can be used for describe much more complex transport interchanges, >>> such >> as >>> major airports and railways stations, detailing every corridor, >>> lift, >>> check-in desk escalator etc. CEN standards are used throughout the >>> EU >> and >>> beyond. >>> http://www.naptan.org.uk/ifopt/ >>> >>> >>> There is also a modelling standard for public transport in general >>> published by CEN called transmodel which covers the modelling in >>> general >> and >>> is used behind most professional transport products used in Europe. >>> www.transmodel.org >>> >>> Of course, I am not proposing that we 'implement' all of the >>> above, but >>> where we choose modelling approaches and terms for entities it >>> would be >>> sensible to choose the same names. >>> >>> >>> _______________________________________________ >>> talk mailing list >>> talk@openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk >>> >>> >> >> >> -- >> http://bowlad.com >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.openstreetmap.org/pipermail/talk/attachments/20080423/4dac212 >> 1/attachment.htm >> >> ------------------------------ >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk >> >> >> End of talk Digest, Vol 44, Issue 96 >> ************************************ > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
