OpenStreetMap

I’m happy to announce that my company, DoubleMap which does GPS bus tracking, has switched all of our public web maps away from Google Maps to OpenStreetMap, with tiles rendered and served by MapBox.

Tens of thousands of transit riders across the US and internationally use DoubleMap’s GPS tracking to help them find out where the bus is at that exact second. Our public map is one of our main features, so the switch to OSM-based maps wasn’t a light decision.

DoubleMap + MapBox

The whole big write-up can be found on the DoubleMap engineering blog but overall it was a great experience.

TM2

We really took advantage of MapBox’s experimental TM2 map styler, since it would have been too much work for us to download and render all the coverage we needed. Instead of uploading gigs of map tiles, we just uploaded a compiled style to MapBox and everything else was taken care of.

Future work

As a company, we’re interested in possibly using OSM data for geocoding, reverse geocoding, routing, and more. We’re definitely happy to see MapBox offer its new routing API, and there may be things that we can do as a company (e.g. collect data and/or feedback for our clients’ cities) to improve OSM data as well.

Check out one of our live GPS bus-tracking maps!

Full article: Porting 600k map views to OpenStreetMap/MapBox

Location: Chatham-Arch, Indianapolis, Marion County, Indiana, 46204, United States

Discussion

Comment from RobJN on 30 April 2014 at 21:47

Looks great. Welcome to the OpenStreetMap community. Bus routes are quick a complex thing to map in OpenStreetMap and trying to keep track of changes to the route is equally difficult. Perhaps that’s one way in which you could feed back into the data??

The other way is to provide some thoughts on how you think bus stops should be mapped. We currently have two alternate schemes. The first simply recommends mapping the bus stop beside the road, the other is a bit more complex as it recommends mapping the bus stop beside the road and as a point on the road where the bus actually stops (then joining the 2 into a relation/grouping). The idea behind this is essentially that public transport routing has a point to route to that is on a road (rather than just next to it). As a potential user of this data, which approach works best for you, or are they both just as good?

Comment from RobJN on 30 April 2014 at 21:49

Obviously that should read “bus routes are quite a complex thing to map”. Long day.

Comment from erjiang on 1 May 2014 at 17:38

Personally, I’m not even sure if OSM should try to keep track of bus routes. Mapping bus shelters is easy, but routes constantly change and have all sorts of business rules that change by day. I admit I’m not familiar with the nuances of OSM’s public transit schema, but here are some obstacles.

The Public Transport page on the wiki says of service relations, “In particular, this makes it possible to provide public transport routing services.” You’d need a lot of metadata (an understatement) to understand bus routes enough to provide routing. Consider these (real) scenarios:

  • a stop that is only visited on weekends
  • a stop that is only visited before 7pm
  • a stop that is only visited on request
  • a route that changes paths for morning/evening rush hours
  • an express variant of a route that runs 3 trips each day at specific times in addition to the regular time
  • a stop that temporarily moves locations because of months-long construction
  • routes that might stop at any intersection if someone wants to board/alight there
  • a bus route that runs when the temperature outside is below a certain threshold

Fares are a whole ‘nother layer of complexity. Also, all of this changes annually, or sometimes multiple times per year. And most OSM contributors do not notice transit relations when editing.

You’d need a service that slurps published GTFS data from each agency every day to check for changes and import that into OSM. And I don’t think you’d get the community or DWG to approve an import cron job like that, especially when even GTFS data is full of problems and tricky cases.

Apologies if that was too much info! Even enterprise bus-routing software cannot always capture all the logic of bus routes.

Comment from erjiang on 1 May 2014 at 18:14

Also, not to avoid the question of placing stops… you’ll notice that we always show two separate stops on either side of the route if the bus goes both directions. This is partly to make clear where people actually wait for the bus, and also because of our internal data model. If it were up to me, I’d just put the bus stops besides the road line and call it a day instead of separately modeling where on the road line the bus stops, but there are probably OSM folk who have more thought-out opinions.

Comment from RobJN on 17 May 2014 at 13:58

I get the impression that Google only map the bus stops and not the full route (that’s why the public transport routing shows straight lines between places rather than following the route of the road). On the other had where we have a mapper who is able and willing to keep route data up to date, then I see no reason not to include it in OSM.

Anyway, thanks for your thoughts - in OSM it can be quite tricky to get an experts opinion at short notice when tagging schemes are being developed.

Comment from erjiang on 19 May 2014 at 03:09

Google Maps can have the full route with separate bus stops – it’s dependent on what the transit agency provides in their GTFS feed. Any public transportation effort in OSM should probably get familiarized with GTFS to understand how that data is modeled.

For example, a GTFS file can provide stop coordinates, the route polyline (for a visual overlay), as well as data on where each stop corresponds to on the polyline. But, these fields could be missing depending on whether the software exporting the GTFS feed (DoubleMap is only one example of transit software that has GTFS export) supports each feature and whether the agency even entered that data.

Log in to leave a comment