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