Hi John, & talk-transit I didn't actually see that text file with all the transitID tag codes until now. I'll include them in my master tagging chart im working on. >From what i can see, all the keys look unique,so it should work out.
Thanks, I'll post the results when i have them. Sam On 6/30/10, john whelan <jwhelan0...@gmail.com> wrote: > I'm currently looking at Bus stops in Ottawa in OSM and finding similar > issues with the existing bus_stops. I'm seriously wondering where > stop_codes exist if one approach might be to import bus_stops using GTFS > data and use the GTFS tags such as stop_code etc from stops.txt > http://code.google.com/transit/spec/transit_feed_specification.html#stops_txt___Field_Definitions > > Tools such as JOSM have a search facility so we should be able to search for > bus_stops without a stop_code then reconcile them with the ones that have a > stop_code tag. If the GTFS data is wrong then we should be able to send a > report somewhere probably the transit authority saying we think this stop is > incorrect. > > My personal view is while we should respect work done already adding extra > tags in this way doesn't remove this work and it is up to the rendering > rules to either omit or include a particular bus_stop for display. This can > be selected by the presence or absence of a stop_code tag, certainly in > Maperitive. > > If we were to do this we would probably need some sort of wiki write up and > a standard way to label bus_stops. Currently in Ottawa I've seen at least > four different ways the ones with the bus route on being the least useful as > they tend to be out of date. > > I don't think mapping routes works at all well. Certainly in Ottawa the bus > stops and stop_codes stay in the same physical place but the bus routes can > be modified three or four times a year. Some changes are greater than > others and the transit route planning system that can be accessed from the > web or by phone includes school buses which are not listed in the stop but > do sometimes provide a useful and quicker way to get from point A to point > B. > > Cheerio John > > > On 30 June 2010 09:25, Hillsman, Edward <hills...@cutr.usf.edu> wrote: > >> Our center has a project to explore the use of OSM as a repository and >> tool >> for supporting multimodal trip planners (for example, bike to transit, >> ride >> the bus, walk or bike to final destination). We are keenly interested in >> the >> current discussion of transit and GTFS in OSM, because one of our tasks is >> to develop software to import from GTFS into OSM, and then update the >> import >> as a transit agency modifies its routes or stops, taking into account that >> OSM mappers may have found and corrected errors in what was uploaded (or >> may >> have introduced errors). I'm writing to share some of our experience and >> get >> your suggestions. We will make the software we develop in this project >> (for >> uploading, matching, and updating GTFS data in OSM) publicly available. >> >> We think it should be relatively easy to upload a set of GTFS stops into >> an >> area where no one has mapped bus stops into OSM. Generating the route >> relations will be harder and we may not accomplish that as part of this >> project. And we think that updating such data will be relatively simple, >> because it can rely on tags identifying and cross-referencing the stops; >> software would look for changes, and manual work would be needed to >> reconcile them. The hard part is going to be designing the initial upload >> process to work in areas where OSM already includes some bus stops, but >> not >> all of them. In the state of Florida, where we are working, there are >> about >> 450 stops already in OSM, many in areas served by transit agencies with >> GTFS >> data. Obviously, we want to respect what has been mapped. Things that >> complicate the initial upload include: >> >> (1) Locational errors in the GTFS data. These are not systematic, and some >> are surprisingly large. One is more than 200 meters from its actual >> location, and only about 10 meters from another stop that GTFS has within >> 10 >> meters of its actual location (and that is mapped accurately in OSM). We >> came into this project knowing that there is locational error in GTFS. Now >> we are trying to figure out how to deal with it. The GTFS locations do >> match >> those appearing in Google Transit, by the way. >> (2) Locational errors in the OSM data. These aren't systematic either but >> tend to be much smaller, except that in a few cases the stop has been >> recorded on the wrong side of the street, and a mapper in one city has >> recorded stops as nodes defining the street way rather than as points to >> the >> sides of the street. >> (3) Incomplete and inconsistent tagging of the OSM stops. >> (4) The presence in an area of stops for multiple agencies, only one of >> which has GTFS data. Our campus has a shuttle bus circulator system with >> no >> GTFS data (they operate without a set schedule but with a target 10-minute >> headway, and frequency changes during the day and with the university >> class >> schedule). The area's main public transportation agency has several routes >> that pass through the campus, and has GTFS data. Most of the public-agency >> stops on campus, but not all, are also campus shuttle stops, and there are >> many more shuttle stops on campus than there are public-agency stops. >> (5) Incomplete mapping of stops for each agency in OSM. >> >> At the moment, we are rethinking the whole idea of trying to match the >> GTFS >> stops to the OSM stops for the initial upload. One idea would be to screen >> all stops in a GTFS area to look for tags indicating the operator (or no >> operator), tag all of them with a FIXME describing that an upload has >> occurred and may produce duplicates, but otherwise leave them alone, and >> then upload the GTFS ones. I see problems with that, and in any case it >> should be done only if there is a commitment by the uploader to work >> quickly >> to reconcile the two data sets in OSM. Given the surprisingly large >> locational errors in GTFS, I'm also uncomfortable with simply uploading >> it, >> because putting bad data into the system will create confusion. I suspect >> this is a problem with all uploads. We've certainly seen it with the TIGER >> street data. >> >> But we are still in the thinking-about-this stage, haven't made any >> decisions, and are looking for suggestions and comments (hence this >> posting). Until we get a much better handle on the initial upload >> problems, >> any actual uploading we do as part of the project will be limited to the >> area of our campus, where we know what is actually on the ground and can >> clean up anything we do. We'd definitely enjoy sharing work and ideas. >> >> Ed Hillsman >> >> Edward L. Hillsman, Ph.D. >> Senior Research Associate >> Center for Urban Transportation Research >> University of South Florida >> 4202 Fowler Ave., CUT100 >> Tampa, FL 33620-5375 >> 813-974-2977 (tel) >> 813-974-5168 (fax) >> hills...@cutr.usf.edu >> http://www.cutr.usf.edu >> >> >> >> On Tue, 29 Jun 2010 15:26:07 +0100 Joe Hughes <j...@headwayblog.com> wrote: >> >I agree that it would be helpful to end up with something that allows >> >straightforward conversions to and from the GTFS format. GTFS is a >> >CC-licensed specification [1] which is evolved by an open community >> >process [2]. Also, the great majority of U.S. and Canadian transport >> >data is already available to developers in GTFS format [3], which has >> >led to a community of developers creating apps which can consume and >> >produce it [4]. >> > >> >Incidentally, as someone who's been deeply involved in the development >> >of the format, I'm happy to answer any questions, and generally help >> >to get this substantial mass of transport data into OSM. >> > >> >Cheers, >> >Joe >> > >> >Links: >> >[1] http://code.google.com/transit/spec/transit_feed_specification.html >> >[2] http://groups.google.com/group/gtfs-changes/ >> >[3] http://www.gtfs-data-exchange.com/ >> >[4] http://groups.google.com/group/transit-developers >> >> _______________________________________________ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-transit >> > -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit