Comments in line > -----Original Message----- > From: Shaun McDonald [mailto:[EMAIL PROTECTED] > Sent: 24 April 2008 00:22 > To: Peter Miller > Cc: talk@openstreetmap.org > Subject: Re: [OSM-talk] Bus Stops > > > 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. >
To be clear, are you saying that Google say that in the case of two bus stops nearly opposite each other on either sides of the road then these should be encoded as two separate entities? If so they are equivalent to a Transmodel Stop Point. Personally I didn't find Google's description too clear on the matter and I suspect that there may be some data suppliers who interpret the GT stop concept as a Stop Point (two separate entities) and other data suppliers who will interpret it as a Stop Area (one entity). http://code.google.com/transit/spec/transit_feed_specification.html There are debates on the GT email group at the moment about how to code station entrances and stop Points that are distant from the road etc so their data model is still evolving and is probably not as good a reference for us as the EU standards which worked this out 10 years ago. > 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. > Sure, it would make sense to define a Hail and Ride section as being part of a length of road as an attribute of the road, although one would need to allow for the case where it was only buses in one direction that stopped. Hail and Ride is always the delinquent 'awkward' child in the mix, and will require special attention. In the UK standards there would be one notional Stop Point for each direction for a hail-and-ride section. > > 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. > Agreed. In the EU model there is a distinction between the logical 'Stop Point' (a point feature) and the physical platform (an area) and the track (a line). There would be a logical Stop Points that would be used within the schedules (relating to platform 4, 4A and 4B in my example), and this will separately be associated with a physical bit of the world (a platform). One platform can of course also serve two separate 'tracks'. There may also be one or more Boarding Points associated with the platform associated with where to stand to enter the train through a particular door for one's booked seat. As I mentioned in an earlier post the physical design of the station is described in the IFOPT standard. Incidentally platforms are called Quays for ferry services and are similar to Gates in airports. In the EU standard they are all of these are called Quays. http://www.naptan.org.uk/ifopt/ I am interesting in the idea of how OSM might model larger transport interchanges, although I think walking round Kings Cross Station going systematically up and down all the escalators making notes and taking photos might get one escorted off the premises! > > 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. > Actually the UK stops data is not tainted with OS data. The DfT went out of its way to get a dataset that the OS had no control or influence over for the same reasons we are collecting a dataset we have control over! It was collected separately by GPS and local survey by the local authorities and is then collected together into a single national dataset. > > > > > > Regards, > > > > > > > > > > Peter > > > > > >> Date: Wed, 23 Apr 2008 20:03:14 +0900 > >> From: "Jeffrey Martin" <[EMAIL PROTECTED]> > >> Subject: Re: [OSM-talk] Bus Stops <snip> _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
