Photo by Let's Kick on Unsplash

In our previous post about MDS feed health and interpretation challenges, we discussed MDS feed health and challenges to interpreting your feed. Now we will take a look at when the data itself is problematic, and some things to consider when troubleshooting. 

Understanding when no data is a problem

There are times when Ride Report will make a request for trip and status change data for a given time period and receive a valid HTTP response that contains no events. This situation can become a bit of a guessing game: is there no data because of a bug in the feed, or because there was no real-world scooter activity during the time period that we requested? There may be an outside factor that we are not aware of - for example, a winter storm in Chicago or a hurricane in Miami may be impacting usage. 

Operators also come and go from cities, and if they are not recording these actions, there’s no way to know if the data is accurate. Extensive communication with both operators and city agencies is often required to understand when we can expect to see data in operator feeds and when there is an expected pause in service.

API downtime

Downtime is a reality of data systems. It’s important for our system to be resilient in situations where an operator’s feed is down for an extended period of time. We occasionally need to reach out to operators in situations like this, but try to constrain our outreach to situations where the downtime is significantly delaying our ingestion. 

MDS version changes

The MDS spec is alive and evolving. We have to make sure that our system can store and format data that was requested from multiple different versions of the standard. Different operators implement and support different versions of the spec. Operators upgrade their feeds to new versions of the standard over time, but each operator does this at a different pace depending on their engineering capacity. 

Operators change data

Sometimes operators will change data once Ride Report has already consumed it. There are a variety of reasons this would be done, for example if an operator discovered a bug and pushed a fix that altered the data. It can be difficult to know when the data in a feed can be treated as settled and stable.

MDS offers a powerful way for operators and cities to communicate, but it requires clear communication and ongoing work to ensure the data is useful. This concludes our three part series on MDS (explore parts 1 and 2).

To stay up to date on micromobility topics including MDS, sign up for our upcoming webinars.