Re: [Talk-transit] simplified relations for transit
Taking this a bit further there is a blog that talks about displaying routes on a map, the last example on the page has a route number on it which might be useful. www.gravitystorm.co.uk/shine/archives/2008/05/29/look-ma-no-hands/ Cheerio John On 16 August 2010 14:52, Hillsman, Edward hills...@cutr.usf.edu wrote: During the past month or so, the members of this listserv have had some discussion of importing bus stops in GTFS format into OSM and the use of relations to group such data. Several members have expressed reluctance to get involved in creating a full set of route relations (i.e., bus stops plus street paths for the actual travel path of the bus) and maintaining those relations in OSM when large public transportation agencies change routes with a fair amount of frequency. And our experience and that of others on the listserv is that these GTFS bus stop datasets contain some locational errors and ambiguities that complicate creating the street path portions of the relations, especially by automated means.. It seems there are several possible uses of the stop and route information in OSM, and these need different types of data: 1) Electronic Map - The visual electronic equivalent of a paper map, which someone can consult to see where the bus routes go, or find which bus route might serve a destination. This probably would be most effective if the map could display the linear route (including the direction of travel) for the reader, rather than just the bus stops. Lines order the stop data, even if the stops are not displayed. 2) Generating trip information - Finding “trip paths” between an origin and a destination, using only OSM data for streets, sidewalks, transit routes, etc., and then displaying the resulting path of the trip overlaid on the map. Most likely, the algorithm that identifies the pathway for the journey would benefit from knowing the sequence as well as the locations of the stops, and again the linear route through the street network would be valuable for this. 3) Generating trip information, with transit exception - Similar to the second application above, it stores bus stop locations in OSM and uses OSM data for walking and biking directions, but it uses route and schedule data contained in the GTFS file (and not stored within OSM), for transit directions. The two sets of trips then are linked using bus stop location information from the GTFS dataset. This is the approach taken by OpenTripPlanner.org. OpenTripPlanner uses OSM sidewalk, street, etc. data to generate biking and walking trips, but uses GTFS datasets to generate transit trips. Ultimately, because OSM is not designed to store the detailed timetable data needed to plan trips at different times on different days, some reference to timetable and route data outside of OSM will be necessary for cases #1 and #2 above, even if OSM is perfectly good for the supporting infrastructure (which I believe it generally is). While it would certainly be good to have the stop sequence (i.e., route path) recorded in OSM, to support all three of these uses, creating and maintaining this is potentially a lot of work, and for some applications it is not necessary. Plus, there is the problem that route path relations seem to be easy to break and hard for beginning mappers to maintain. On the other hand, it is actually pretty simple and straightforward to create a relation for each of a transit agency’s routes, and to put just the stops into the proper relations when importing or updating them. So, would there be anything wrong with putting only the stops into route relations, without trying to figure out and code route paths as part of that relation? The only negative we can see is that the route path part of the relation would not exist, and so the data would not support the use cases #1 and #2 for transit. OpenTripPlanner appears to be a very popular routing engine which is available in many geographic areas. Thus, for a software tool we’re developing we’re leaning towards not including transit route information within OSM per case #3. As with anything in OSM, individuals map what they know or are interested in, and may ignore or omit features that they are not interested in. Someone who comes along later and decides that the route paths are really important could code them into the route relations. Are there other applications that might require a representation of the path for use cases #1 and #2 above, that we should be considering? 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org
[Talk-transit] simplified relations for transit
During the past month or so, the members of this listserv have had some discussion of importing bus stops in GTFS format into OSM and the use of relations to group such data. Several members have expressed reluctance to get involved in creating a full set of route relations (i.e., bus stops plus street paths for the actual travel path of the bus) and maintaining those relations in OSM when large public transportation agencies change routes with a fair amount of frequency. And our experience and that of others on the listserv is that these GTFS bus stop datasets contain some locational errors and ambiguities that complicate creating the street path portions of the relations, especially by automated means.. It seems there are several possible uses of the stop and route information in OSM, and these need different types of data: 1) Electronic Map - The visual electronic equivalent of a paper map, which someone can consult to see where the bus routes go, or find which bus route might serve a destination. This probably would be most effective if the map could display the linear route (including the direction of travel) for the reader, rather than just the bus stops. Lines order the stop data, even if the stops are not displayed. 2) Generating trip information - Finding trip paths between an origin and a destination, using only OSM data for streets, sidewalks, transit routes, etc., and then displaying the resulting path of the trip overlaid on the map. Most likely, the algorithm that identifies the pathway for the journey would benefit from knowing the sequence as well as the locations of the stops, and again the linear route through the street network would be valuable for this. 3) Generating trip information, with transit exception - Similar to the second application above, it stores bus stop locations in OSM and uses OSM data for walking and biking directions, but it uses route and schedule data contained in the GTFS file (and not stored within OSM), for transit directions. The two sets of trips then are linked using bus stop location information from the GTFS dataset. This is the approach taken by OpenTripPlanner.org. OpenTripPlanner uses OSM sidewalk, street, etc. data to generate biking and walking trips, but uses GTFS datasets to generate transit trips. Ultimately, because OSM is not designed to store the detailed timetable data needed to plan trips at different times on different days, some reference to timetable and route data outside of OSM will be necessary for cases #1 and #2 above, even if OSM is perfectly good for the supporting infrastructure (which I believe it generally is). While it would certainly be good to have the stop sequence (i.e., route path) recorded in OSM, to support all three of these uses, creating and maintaining this is potentially a lot of work, and for some applications it is not necessary. Plus, there is the problem that route path relations seem to be easy to break and hard for beginning mappers to maintain. On the other hand, it is actually pretty simple and straightforward to create a relation for each of a transit agency's routes, and to put just the stops into the proper relations when importing or updating them. So, would there be anything wrong with putting only the stops into route relations, without trying to figure out and code route paths as part of that relation? The only negative we can see is that the route path part of the relation would not exist, and so the data would not support the use cases #1 and #2 for transit. OpenTripPlanner appears to be a very popular routing engine which is available in many geographic areas. Thus, for a software tool we're developing we're leaning towards not including transit route information within OSM per case #3. As with anything in OSM, individuals map what they know or are interested in, and may ignore or omit features that they are not interested in. Someone who comes along later and decides that the route paths are really important could code them into the route relations. Are there other applications that might require a representation of the path for use cases #1 and #2 above, that we should be considering? 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.edublocked::http://www.cutr.usf.edu/ ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] simplified relations for transit
I've been playing with editing an OSM file in Visual Basic, you save the .OSM file from JOSM or grab it in some other way then edit the XML file, putting a modify tag on anything changed, load it into JOSM then upload the changes. I actually wanted an automated way to generate a name:fr tag on a street name and add it to the local street names in Ottawa, its possible to work out an algorithm to do most of these in an automated way. So it's a sort of mini bot. I can forward you a copy of the program source but wouldn't like it to spread around too far as it is very easy to do a lot of damage very quickly with this sort of tool. If you have a stop_code on the bus stop then the local mapper can correctly position the bus stop. Now given the route is just a collection of bus stops you can pick out the bus stops in the OSM file and update the bus route numbers using Visual Basic, then feed the updates back with JOSM. In theory you should even be able to set a relationship of bus stops or way for the route that could display the particular route when rendered. I think the colour can be suggested in the GTFS file. Maperitive would you lots of control over rendering, possibly let a student lose on it as a project? Cheerio John On 16 August 2010 14:52, Hillsman, Edward hills...@cutr.usf.edu wrote: During the past month or so, the members of this listserv have had some discussion of importing bus stops in GTFS format into OSM and the use of relations to group such data. Several members have expressed reluctance to get involved in creating a full set of route relations (i.e., bus stops plus street paths for the actual travel path of the bus) and maintaining those relations in OSM when large public transportation agencies change routes with a fair amount of frequency. And our experience and that of others on the listserv is that these GTFS bus stop datasets contain some locational errors and ambiguities that complicate creating the street path portions of the relations, especially by automated means.. It seems there are several possible uses of the stop and route information in OSM, and these need different types of data: 1) Electronic Map - The visual electronic equivalent of a paper map, which someone can consult to see where the bus routes go, or find which bus route might serve a destination. This probably would be most effective if the map could display the linear route (including the direction of travel) for the reader, rather than just the bus stops. Lines order the stop data, even if the stops are not displayed. 2) Generating trip information - Finding “trip paths” between an origin and a destination, using only OSM data for streets, sidewalks, transit routes, etc., and then displaying the resulting path of the trip overlaid on the map. Most likely, the algorithm that identifies the pathway for the journey would benefit from knowing the sequence as well as the locations of the stops, and again the linear route through the street network would be valuable for this. 3) Generating trip information, with transit exception - Similar to the second application above, it stores bus stop locations in OSM and uses OSM data for walking and biking directions, but it uses route and schedule data contained in the GTFS file (and not stored within OSM), for transit directions. The two sets of trips then are linked using bus stop location information from the GTFS dataset. This is the approach taken by OpenTripPlanner.org. OpenTripPlanner uses OSM sidewalk, street, etc. data to generate biking and walking trips, but uses GTFS datasets to generate transit trips. Ultimately, because OSM is not designed to store the detailed timetable data needed to plan trips at different times on different days, some reference to timetable and route data outside of OSM will be necessary for cases #1 and #2 above, even if OSM is perfectly good for the supporting infrastructure (which I believe it generally is). While it would certainly be good to have the stop sequence (i.e., route path) recorded in OSM, to support all three of these uses, creating and maintaining this is potentially a lot of work, and for some applications it is not necessary. Plus, there is the problem that route path relations seem to be easy to break and hard for beginning mappers to maintain. On the other hand, it is actually pretty simple and straightforward to create a relation for each of a transit agency’s routes, and to put just the stops into the proper relations when importing or updating them. So, would there be anything wrong with putting only the stops into route relations, without trying to figure out and code route paths as part of that relation? The only negative we can see is that the route path part of the relation would not exist, and so the data would not support the use cases #1 and #2 for transit. OpenTripPlanner appears to be a very popular routing engine
