Update MDS / MDS-Provider to support multiple modes

[hunterowens]

Currently, the Mobility Data Specification only supports dockless bikeshare/scootershare by design. While it is possible to map some of the endpoints and datatypes onto other modes, such as docked bikeshare or carshare, the abstractions begin to breakdown pretty quickly and we will lose the ability to analyze or use the data if the current spec is used for many modes.

However, we do want to preserve common definitions of things such as timestamps, points and potentially even more complicated topics such as routes across all of MDS (or portions thereof).

JSON schema and the generate_schema program give us a way to make MDS endpoints easily composable into a uniform shared datatype when possible and separate when needed.

This PR adds documentation on how to support new modes and takes the existing provider spec, splits it apart into a generic component and a dockless-micromobility section specific to scooter share.

The new directory structure (see below) adds a CONTRIBUTING.md file, which fixes #176. It additionally requires that we have implementation agencies / providers for any new modes for the spec. Finally, specific to dockless-micromobility info is broken into subfolders, with generic provider info remaining in provider.

This PR fixes #170. It will allow #167 #95 #237 to move forward, along with a host of other issues. This, however, doesn't define how to handle new modes in agency. I will prepare a separate PR for that.

Pinging @sdrewdc @chursaner @oderby @karcass @FordSmartMobility who have expressed interest in this topic.

├── CONTRIBUTING.md
├── generate_schema
│   ├── common.json
│   ├── generate_provider_schema.py
│   ├── provider
│   │   └── dockless-micromobility
│   │       ├── status_changes.json
│   │       └── trips.json
│   └── requirements.txt
├── provider
│   ├── README.md
│   ├── auth.md
│   └── dockless-micromobility
│       ├── README.md
│       ├── status_changes.json
│       └── trips.json
└── providers.csv

[evansiroky]

I recently submitted a PR to the GBFS project (MobilityData/gbfs#136) in a brainstorming attempt on how to allow multiple vehicle types. Seems like there's some movement on their end to formally explore a large update to GBFS (MobilityData/gbfs#137) in coordination with this project?

[hunterowens]

@evansiroky +1 to expanding GBFS. I am going to put some comments on the GBFS issue as well.

[lionel-panhaleux]

Vehicle sharing services, ie. docked bikes or cars, could easily follow the same model as dockless shared mobility devices by making the docking station information "required if available".

I would advocate instead to separate the modes between "shared_device" (shared cars, bikes, scooters, docked or deckles) where the users are the drivers and "private_device" or "device_service" (tac, taxis, etc.) where the drivers own the device (or are contracted by the owner).

[marie-x]

I'm fine with all of this as-is. My one nit is that floating-style car services like car2go and Zipcar Flex fit entirely within the dockless-mobility concept, so I would advocate (1) add "car" as a vehicle type and (2) call this "dockless-mobility" instead of "dockless-micromobility". (1) would address @dbaty's #219.

[hunterowens]

@karcass I gave thought to that, but the various regulatory bodies have pretty strong differentiation between cars | not cars in the legal definition (for example, California Vehicle Code). This means that we have to have different data collection procedures for each mode. Micromobility, Transit + Cars seems be the three main categories that the vehicle codes have.

[toddapetersen]

Have we enumerated how these differences affect the APIs? If not, we need to put a working group together to get this figured out. It sounds like it has the potential to influence many endpoints in the future.

[L8-N8]

Looking forward to seeing how this conversation evolves.

[hunterowens]

@toddapetersen yes! @karcass @whereissean and I had a chat and I think the move was to go ahead and test this in provider and port to agency is if it works / maps on to the model, or adopt differences if needed as MDS continues to add modes, but by testing on one side of the API we reduce initial implementation and iteration complexity.

[hunterowens]

From the 4/4 call:

1. Need to add Clarity / Guide on how new modes are introduced
2. Questions how to standard shape of the API across modes given that they are different folder
3. Taxonomy Questions

[jfh01]

Additional notes from 4/4 call:

• Don’t want to shoehorn new modes into inappropriate endpoints, but are there a set of shared end-points that every mode should support?
• Not a clear taxonomy/hierarchy for modes.
• Could a hierarchy of modes push for a correspondingly hierarchal API spec?
• Are there shared concepts across mode (e.g. a trip or a stream of status events for things in the public right of way). Could we create endpoints that capture these concepts across multiple modes.
• What belongs as a data attribute on an endpoint (propulsion type, vehicle type) versus a new endpoint for a new mode?

[hunterowens]

Notes from 5/23 call

@hunterowens to refactor, per, @rf- suggestion to have the JSON schema break out and be mode specific, but not have specific directories / READMEs. This limits how wide the API might grow. It will probably make sense to do this PR after #281 is done.

[hunterowens]

This is now breaking, holding for 0.4.0

[hunterowens]

closing this in favor of #336

[schnuerle]

Working on this for 2.0 with #574