In NaPTAN each direction of travel must be modelled with a separate stop - so even though you may have a sign which says "stops in both directions" (but the sign is only on one side of the road) ... there are two NaPTAN records, one showing a marked stop, and the other an unmarked one (what we call "custom and practice").
Where one stop serves both directions of travel, then it is one NaPTAN record and both directions of travel have the same "bearing" - that is the direction in which the bus is pointing when at the stop. This reinforces what Peter said before that the bearing is NOT the direction towards the next stop or the ultimate stop, it is just the local bearing of the bus when it is stopped. For bus stations NaPTAN has a separate type of stoppoint - and these do not have "bearing" values associated with them because they would be very artificial. Roger From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter Miller Sent: 16 July 2010 8:15 AM To: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Proposed additional tags for bus stops and animport of San Fracisco data On 15 Jul 2010, at 11:21, Joe Hughes wrote: Peter, I think it would be helpful to look at GTFS data from a few diverse providers when testing ideas about imports, as data tends to reflect the historical practices of the particular agency in ways like naming patterns, which details are present, etc. There's a great deal of GTFS data on gtfs-data-exchange.com, but I'd recommend, say, TriMet and Port Authority of Allegheny County in addition to the SFMTA data that you're already examining. As you mentioned, the street and directional information should be optional, as there are boundary cases like stops in shopping centre parking lots, large station complexes, and underground private ways which might make it difficult to provide reasonable street/direction values. By and large I could see how that information would be useful for snapping stop points to varying road network data sets (setting aside the issue of how to deal with stop points on traffic islands in the centre of the road). In general, though, we should be careful not to depend too much on things which are likely to be available from source data in only some parts of the world. (Consider places where not all roads have agreed-upon names.) Thanks for your continued efforts on this issue! Thanks Joe, We are going taking a look at Chicago data next as I am going to be there shortly and we will then look at the others you recommend to see what will work in different places. Btw, if anyone has any contacts in Chicago then do let me know. In general in osm there should nearly always be a highway way associated with on-street stops which is used by the vehicle and there should also be a node where people wait for the vehicle by the way. Where the highway doesn't have a name, or has a name that is not unique then I would suggest that a relation is used to bind the stop to the way. Some bus bays don't usefully have a direction - if they are reverse out bus bays for example, and also in some other situations but these are generally not considered to be 'on-street'. With reference to the proposal to define the use of the bus stop by the services that use it I think one is in danger of getting into circular definitions which get confusing when mistakes are make. Which is wrong, the stop, or the service? In the UK it has been very useful to first settle which side of the road the bus stops are on using the bearing and then to ensure that the correct services are connected to them and sort them out any cross wiring which might mean moving some services to the other stop of the pair. Re stops in the middle of the road, the rule at the ordnance survey in the UK is that a road should be represented as two parallel ways where there is a central barrier, divider or structure such as a bus stop in the middle. I am not sure how a bus stop would be described in NaPTAN, possibly there would be two nodes, one for each direction or possibly just one with no bearing. As you say Joe, lets review many different systems and see what will work in different places. Regards, Peter Cheers, Joe On Thu, Jul 15, 2010 at 8:53 AM, Peter Miller <peter.mil...@itoworld.com> wrote: I have been looking at the GTFS data for San Francisco over the past few days and considering how one could do a bus stops/tram stop import for the place and more generally for the GTFS data. However... in the process I want to be be 100% clear which road the stop serves and in which direction to improve the quality of map rendering which is not possible with the current bus stop tagging. Here is the general bus stop positioning problem for bus stops in osm as I see it. The osm community has agreed to place the bus stop beside the road at the place where people wait which is good, however if that stop is close to a junction or to two roads that run parallel then it is not clear which road it serves. This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. 'Street' tag: to indicate the name of the associated street 'Bearing' tag: to indicate the direction in which vehicles leave the stop, to be clear this is the immediate direction taken, not a sight-light to the next bus stop. NaPTAN uses compass points N, NE E etc'. Here are some examples of where the addition tags are useful. In the first case it is not clear without the street tag which of two parallel streets are served, and in the second it is not clear which of three nearby streets are served. http://www.openstreetmap.org/browse/node/816289382 http://www.openstreetmap.org/browse/node/817535874 With these tags we should then be able to do an automatically import. Here are some initial observations on the data. In general the data is good except for a few places where there appear to be duplicates for some stops in similar but not identical locations. This would require a manual clean-up of some busy streets following the import. Stops on either side of the road have the same name. This is not a problem if the bearing field is set correctly from the schedule data - setting the bearing is non-trivial but can be done. The stop naming is 'street & street' where the first street name is for the street that the stop serves. This will allow the stops to have the 'street' field set. Sometimes the location of the stop is wrong and places the stop on the other side of the road. This can be sorted manually afterwards given that the bearing field and street fields will show what is actually required. There is a licensing issue for the SF data which is currently only available on a 'limited, and revocable license' which 'does not include any right to sublicense'. http://www.sfmta.com/cms/asite/transitdata.htm Clearly this is not sufficient as it stands and we would need to get approval for what we wanted prior to doing the actual work. Any thoughts on the tagging proposal? Regards, Peter _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
