Appendix C

Appendix C: On types of data, file formats, feeds and APIs

On types of data, file formats, feeds and APIs

Since 2010, the City of Seattle has openly published data it generates and collects for public use, and  encourages sharing of city data proactively “for the purposes of increasing transparency, accountability, and comparability; promoting economic development and research; and improving internal performance management.”[1] The open data platform is the primary means of pushing out transportation data; SDOT has published nearly 100 datasets, including bike counters, permits, collisions, parking transactions, and nearly all of the physical assets owned and managed by the department.

Varying systems, data formats, and file types in the ecosystem means that information does not flow freely through the system. The availability of the information is often not enough to assure the smooth flow of information.

For example, SDOT records parking rates and rules as GIS so it is related to the street or district. SDOT transmits the same information to parking payment companies as GIS files and it takes the payment company about six months to validate the information on parking spaces and rates from SDOT and deploy it into their systems. This constrains SDOT from a more active, real-time management of curb uses. Releasing the data by making the GIS files available is probably not enough to make the information flow smoother.

Most public transit agencies publish their schedules and route data as data feeds[2], which are usually one-way flows of information. The agency publishes the feed and updates it automatically and regularly, and the actors subscribe to the feed and pull data from it to inform their users, through apps, of how soon before the next train or bus arrives.

Private actors, particularly information service and the mobility service providers, usually exchange data through application program interfaces or APIs. An API is “a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API.”[3] APIs allow both parties the ability to interact with each other’s data. APIs provide a machine-readable, request-response interchange, with the information flowing from one party changing the response or information from the other party.

The actors gather information from the users themselves through APIs that interact with sensor data. For example, ride-hailing apps get real-time information about the exact location of their customers and their drivers (and the vehicles) by pulling information from the phones’ GPS chips. Map and navigation services crowdsource information about traffic incidents and road closures from data received from their users, either voluntarily or by sensing the movement and speed of hundreds and thousands of mobile devices simultaneously using their map apps.

More advanced DOTs are experimenting with APIs. Los Angeles’ DOT, in cooperation with other cities including Seattle, published the mobility data specification or MDS. MDS is essentially a shared data specification between jurisdictions and private service providers. As of now, MDS is built on two APIs–one that allows the mobility service provider to request, in real-time, information from the DOT (for example, variable parking rates by time of day), and one that allows the DOT in turn to request information about the origin and destination of vehicles and their current location and direction.

APIs could allow users to be more aware of the system conditions (e.g., where parking is not allowed) and system managers to know the volume of traffic and the preferences of the users and to make decisions accordingly (e.g., building bike lanes where micro-mobility users tend to travel).

The form the information takes when it is transmitted is shaped by how often the information needs to be refreshed. Large GIS and database files are good for transmitting information that does not change very often, while data feeds and APIs allow access to up-to-date versions of information that changes frequently.


[1] City of Seattle Open Data Policy OD-1 V1.0. Feb.1, 2016.

[2] “A data feed is a way of sending structured, current, and up-to-date information. Usually for use on a website, app, or another online tool.”


Need More Information?

This is a draft plan. It was developed by Benjamin de la Pena, Mary Alyce Eugene, Alex Hagenah, and Sam Marshall along with their colleagues from across the Seattle Department of Transportation (SDOT).

If you have questions about this plan, please send us email via

If you have questions about SDOT, please visit our website at

Designed by Story 2 Designs

Privacy Policy