Proposal - RIPTA Import

RIPTA Import

Hello, I am proposing to import the RIPTA GTFS dataset, sourced from RIPTA (Rhode Island Public Transit Authority).


This is the wiki page for my import:
This is the source dataset’s website:
The data download is available here:
This is a file I have prepared which shows the data after it was translated to OSM schema:
(NOTE: I use route 60 all the time so I felt confident in adding this one specifically, though I still want help on the format.)


I have checked that this data is compatible with the ODbL.
This data is distributed under public domain. I emailed RIPTA to ask if it is, they have said so. The email is linked in the wiki.


This dataset contains the Rhode Island bus routes and stops.
I live in Rhode Island and OSM does not contain any bus stops. I propose adding these bus stops.
This dataset contains 3629 bus stops in Rhode Island.
I will use GTFS-OSM-Validator → JOSM.
I have a python script written in the wiki proposal that adds in OSM schema tags for bus routes based on the OSM bus route wiki help page.
I will use JOSM to manually validate bus stops. The GTFS-OSM-Validator does this automatically, but it is not consistent. There are only 3629 stops, so I will do this manually.

This is my first attempt at importing a dataset, so please let me know if I’m missing anything, thanks!

1 Like

Thanks for this, when you’re working on this import, I would ask that you do a manual review of the bus routes and stops that are going through the Pell Bridge Ramps reconstruction project in Newport. The road pattern has been completely changed and I suspect all of the bus routes that run through that area are currently in a broken state.

1 Like

Thanks, you are definitely correct. The routes around here have not been updated either. I can do that manually before I start the import so the import goes more smoothly! The RIPTA GTFS dataset already contains these changes.

1 Like

Hi, thanks for taking the time to import this data to OSM! I think this plan looks mostly good, but I had a couple of comments:

  • I think what you have as ref should be route_ref, since it’s the bus line that serves the stop. ref is for the stop’s ID number in the system (this is printed on the sign in some systems and can be used to look up the stop)

  • Relatedly, it looks like you have two items in your GTFS files, which you’re importing as gtfs_stop_code and gtfs_id, that are exactly the same for all the stops, except that the stop code has leading zeros added to it to get to six digits. Are both necessary? My suspicion is that this is in fact what is usually mapped as ref, but I lack the local knowledge to confirm this.

  • I think in the proposal you’ve missed public_transport=platform in your table of tags you’re adding, though it seems like you included it in the test changeset.

  • The naming scheme for the bus stops seems quite unusual to me (mostly the use of “before” and “after” for stops at intersections), but clearly that’s what’s in the GTFS files so I suppose there’s no clear alternative.

  • Just as an aside, I find JOSM to be much easier to edit bus routes in than iD (the default editor on the website), but it takes some learning.

1 Like

Thank you!

  1. No problem changing ref to ref_route, thanks. I chose to use ref because other bus stops in Rhode Island were ref, e.g., Node: ‪Kennedy Plaza Stop W‬ (‪5288439208‬) | OpenStreetMap These are what I based my bus stops on. The only number on the bus stop signs are the phone number to RIPTA customer service, so I wouldn’t hedge bets that there’s a ref. Do you suppose I should change those to ref_route or since those are endpoints, would they be better off as a ref?

  2. I believe just having one of gtfs_stop_code or gtfs_id would be nice. This would help future OSM editors know that this is the bus stop that the GTFS team at RIPTA have adjusted. I’ll remove gtfs_id.

  3. Sorry, I missed public_transport somehow, I have no idea how. This has been added.

  4. Yes, that’s the GTFS file, I definitely did not touch those names. When riding route 60, at least, these bus stops are never named, so they are not really a thing I notice.

  5. I can try working with JOSM, but I’ve got this planned out and I’m fine popping on a TV show, and just clicking and dragging for a few afternoons until it’s done.

Ah thanks for the example. It looks like on that stop, the previous editor did use route_ref for the routes that serve the stop (27 and 28), but used ref for the reference letter of the stop within the bus station (W). Based on what came up on google for what the situation on the ground is, I think the route_ref tag is correct, but the latter should actually be local_ref=W, which is for reference numbers within a station like platform numbers (there are a lot of different ref keys! It’s a bit confusing). These kinds of things are described on the highway=bus_stop wiki page as well as the local_ref one. So I would use route_ref to encode the routes that serve a stop, and local_ref for any bus bay designations like the one you linked to in Kennedy Plaza (they’re probably rare).

Just ref alone refers to the stop’s code in a network-wide scheme, but if it’s not marked on the stops by RIPTA, I think your proposal of leaving it as gtfs_stop_code makes sense. That’s pretty easy for someone to go in and edit in bulk later anyways.

Other than that, sounds good!

1 Like

I might prioritize setting gtfs:stop_id or ref to the stop ID, rather than gtfs_stop_code, this is the value that will likely be more useful to and expected by consumers, especially if the stop code isn’t actually displayed to riders within the system (see GTFS docs for distinction). Most other agencies have ref set to the stop id value, and that’s what the consumer I’m most familiar with (OTP) expects by default. I’m not sure if this is best practice, but I prefer to set both ref and gtfs:stop_id to the stop id for clarity.

Here’s an example of a nicely tagged MBTA bus stop. Shout out to @KevinMapsThings! I know @JesseFTW has also been working on a lot of MBTA bus stop changes and might have some input.


In general the plan you’ve put forward looks good, I just have a few small recommendations (around tagging). As far as the “stop id” vs “stop code” discussion goes, I would recommend making use of the “stop id” given that the “stop code” is only a left-padded variation on it.

I have submitted a request to get RIPTA added to PTNA, which we already have configured for the major MA RTAs. I would recommend setting the following tags (in addition to the ones already mentioned in the wiki) for the highest chance of compatibility across tooling.


Public Transportation:

Additionally your Wiki mentions adding ref_route as a tag, I suspect you meant to add route_ref instead.

1 Like

Yep, received it. I think I can find some time on 23rd to configure that.

Done now, see PTNA: news for Public Transport Network Analysis #100

@KevinMapsThings Could you please check for the license stuff of the GTFS data? I could not find any links.

Hi ToniE, I asked for permission via e-mail, User:Sjwhitak/RIPTA Import Plan - OpenStreetMap Wiki but I’m afraid of giving out the email of my contact for fear of spamming her. The one line I removed since it didn’t seem too important was:

Hi Steven,

Awesome that you want to put RIPTA data into OpenStreetMaps! Yes, this data is publicly available and you’re welcome to use it. If I was slightly more on top of things, I’d use our GTFS to update the datasets in RIGIS… well, it’s a goal for the new year.

In case you’re not aware, RIPTA makes planned service changes generally three times a year (January, June, and August/September) and when we make those changes we also update the GTFS data on our website. Most of these changes are not drastic – adding or removing a bus stop, small route deviations, retiming of schedules, etc. – but to be most accurate you may need to occasionally update the data or at least note the publish date.

Unfortunately, we don’t have any kind of data use policy at this time.


If you would like to get her information, let me know! I just don’t want to sour her mood with thousands of spam emails.

I will update these changes that KevinMapsThings did after Christmas, thanks!

Hi sjwithak, that’s absolutely sufficient.

I would like to quote

Awesome that you want to put RIPTA data into OpenStreetMaps! Yes, this data is publicly available and you’re welcome to use it.

Using the link to the OSM wiki page: “User:Sjwhitak/RIPTA Import Plan - OpenStreetMap Wiki”. But this would expose your user name in the GTFS data provided by PTNA.

If you’re not OK with this, would you copy & paste the section from your user page to Permissions North America (currently empty). You could refer there to a new wiki page for the USA similar to the one for Ireland and add the statement details there.

Thanks, Toni

Hi, I have no problem with this being linked to the PTNA. Whatever I have posted on the OSM Wiki page and on this forum post, you have full permission to publish it anywhere else. I was already under the assumption that anything I post on here would be copied elsewhere.

But I did not ask for permission to have the email from RIPTA be published anywhere public, so I just don’t want to have that person’s work email out in the public to be spammed in the future.

Thanks, great!

It’s been 21 days now. I lost the wiki page that says how long I should wait, I don’t remember if it was 21 or 24, but if I have no complaints, I plan to do this tomorrow. Thanks!


Looks good to me. Go for it. I’ve done some bus mapping around baltimore though not directly importing GTFS per se. I always found it fun to try and match what the route map says vs the real route of the bus on the road network. I found looking for oil marks where the buses stop is a good indicator of where the real stop is. I also joined some secret bus driver Facebook groups to ask questions about peculiar stops.

As an update, I’ve got the nodes all added on changeset 146126196.. Next step is to manually add relations to the paths, since I couldn’t figure out how to do this.

Please note there are a few redundant nodes (noteably in Westerly, RI near the train station), but this is due to the fact that a few routes were laid out before and I cleaned up some. I clearly missed some, but I made sure the ones in Providence, RI and other major cities weren’t. I will be spending this week cleaning it up, removing redundant nodes, and adding relations to all the nodes that correspond to the route_ref value.

Additionally note the change in the Wiki signifies the code I had to modify to handle the code properly.

I found that the GTFS data for the Warwick Mall bus stop and Bayview Apartments bus stop had missing data, so I manually edited those.

Hi, I’m working my way through this all and I’ve got all the previously made routes updated and cleaned up. I’ve cleaned up almost all the bus routes. There are some missing entirely, like route 23 and some oddball ones like all the 200s, so I’m adding those still.

My question is: Adding individual bus stops along the way to the bus relation is very tedious. Does anyone have any recommendation on how to speed this up?

My current procedure is to click on one way on the route, pan around until I find the next bus stop, deselect the route, click the bus stop, insert it into the route, then re-click on the route again to know where to go next. It’s really tedious to have to reselect the bus route between every single bus stop selection. Is there a method where I can keep the entire relation highlighted without having it be selected? Thanks.

While researching this, I found no good video explaining how to map bus relations, so I made one for my friend to get started. It might be useful for others here too:

Finally, I see duplicate routes. For instance, if you zoom in here: OpenStreetMap I have removed all the RIPTA routes on that disconnected road to the right of the roundabout. The relation route 64 already exists under RIPTA 64, but there’s additionally a route 64. Can I delete this? I do not like deleting anything in case it’s required, so I always like to ask for permission first. Adding is easy since I can delete it after, but if I delete someone else’s work that ought to be there, I won’t know how to get it back.

Sorry, I might be a little late to the party.

Regarding stops, I would additionally use gtfs:name or gtfs:stop_name as name is for the otg name which often differs from the GTFS name.

Regarding routes:
I usually first add all the stops in the correct order and than I add the ways for the route. Using a filter to only have the stop nodes (maybe even only the stops with the correct route_ref) can help with the first part. The gpx file (first button below the map) from the single trip in PTNA’s GTFS loaded in JOSM helped me as reference in the background. Additionally, I recommend the plugin “pt_assistant” which also includes a map paint style, an extra layer and some validator rules.

Regarding re-selecting the route, I think the plugin “reltoolbox” offers the function.

Regarding route 64, please, update the existing route. I quick look into the history tells you that the road network around the roundabout was completely reconstructed and even the shape file in the GTFS is not up to date, see e.g. PTNA - GTFS Analysis.

1 Like

Hey @skyper sorry, route 64 is fully completed under route names “RIPTA 64 Newport/URI…” whereas the route I want removed is another route named “64 URI”. You can see the RIPTA 64 routes by clicking on the roundabout. I believe “64 URI” is an old route. Every updated bus route starts with “RIPTA…” and “64 URI” does not. I’m pretty confident I can delete this relation completely.

I just wanted to confirm that I can delete someone else’s stale relation without needing to go through any procedure. Thanks.