mapbox / mapbox/nepomuk

Consider OSM Relations / geometry

Open
#74 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Discussion
Dominant language
C++
Stars
24
Forks
7
PR merge metrics
No merged PRs in 30d

Description

Breaking out from https://github.com/mapbox/directions-transit/issues/73#issuecomment-291442153.

We should investigate in how far we can use OSM data to augment the GTFS feeds. Multiple possible improvements come to mind:

- stops and stations. Many stops are actually in close proximity, without them being considered as possible transfer locations. We could investigate OSM relations as a possible source of discovery
- geometry: not all routes might offer reasonable geometry. We could try and augment the geometry of a bus route with its OSM counterpart

Possible pitfalls would be outdated data in OSM, when transit authorities change routes. Especially for BUS routes there could be quite common changes. Train stations however are of a more permanent nature.

// cc @daniel-j-h

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Begin by mapping how the router consumes static GTFS data, then investigate whether OSM relations can identify transfer locations and whether OSM geometry can supplement routes; account for stale OSM data, especially for bus services.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend, data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.