Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
I would love to see GTFS data imported into OSM, especially the SF data if you can convince them to change the license. I think the street= tag is a good idea. I'm unsure of the bearing tag. If we know which street the stop is on and where the stop is the direction the bus is going follows from that. Could you provide an example of where and how that would come in useful? Or is it something that we need to know only if the imported location of the stop is not precise enough to show which side of the street it is on? How are you planning to deal with existing data? Many stops are already mapped and have more data than is in the GTFS feed. For example, does the stop have a shelter, or a ticker to show when the next bus is coming or a bench, etc. Cheers, Greg ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
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
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
On 15.07.2010 09:53, Peter Miller wrote: 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. As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
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! Cheers, Joe On Thu, Jul 15, 2010 at 8:53 AM, Peter Miller peter.mil...@itoworld.comwrote: 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
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
So you change the associated bus stops. Can be done. Greetings, LMB On 15.07.2010 14:50, john whelan wrote: I don't think this is a good idea as Ottawa certainly changes the bus routes or lines four times a year. Some lines are stable for many years but many are not. The stops themselves remain in the same place its just the buses that serve them change their numbers and routes. Cheerio John As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ 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 -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
You are talking about verifying 10,000 bus stops four times a year. Are you assuming that this would be done through GTFS? Currently in Ottawa there is no way to tie the physical bus stop to GTFS and the GTFS locations are not always accurate. Not all bus stops are included in the file. At one local junction I still haven't worked out which bus stops are included and which ones are not. We do have a stop_id on the bus stop, its just not included in the GTFS file and the other issue we have is licensing. Cheerio John 2010/7/15 Michał Borsuk michal.bor...@gmail.com: So you change the associated bus stops. Can be done. Greetings, LMB On 15.07.2010 14:50, john whelan wrote: I don't think this is a good idea as Ottawa certainly changes the bus routes or lines four times a year. Some lines are stable for many years but many are not. The stops themselves remain in the same place its just the buses that serve them change their numbers and routes. Cheerio John As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ 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 -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ 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
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
On 15.07.2010 15:02, john whelan wrote: You are talking about verifying 10,000 bus stops four times a year. No, I'm talking about changing those when the bus lines change. Not all bus stops have to be reviewed. Greetings, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
