Appendix F

Appendix F: SDOT Information Infrastructure Backlog

We used an Agile approach in developing this plan. Agile project management “is an iterative development methodology that values human communication and feedback, adapting to changes, and producing working results.”[7]

In Agile project management, the “backlog” is a list of all tasks needed to complete the product. In this case, this is a list of key components of the information infrastructure that SDOT must build to fulfill the requirements of this plan. Each project is followed by a description or user requirements.

Following the Agile approach, this is a partial list. It is meant to be a starting point and a driver for discussion. It also needs to be broken down into smaller chunks of work for agile delivery.

As SDOT implements this plan, it will continue to revise this list, in order to prioritize what can be achieved quickly. Rather than setting out to deliver massive projects, the focus should be on delivering working components as quickly as possible.

Real-Time Right of Way Conditions Map

To manage the transportation network, the Real-time Right of Way Conditions Map should allow SDOT to:

Show real-time traffic flow, and road, curb and sidewalk use

  • Real-time traffic flow and volumes
    • Pedestrian aggregate volumes and flow  (at crosswalks and for specific routes)
    • Real-time locations of high-capacity transit (buses and rail)
    • Real-time routes cleared for emergency vehicles
    • Volume of shared vehicles while moving on arterials
    • Volumes of shared vehicles while moving in urban centers
    • Locations of urban delivery vehicles while moving on arterials
    • Real-time volume of delivery vehicles by block face
    • Real-time volume of shared-vehicle loading and unloading (at block face level)
    • Locations and availability of shared vehicles when not in use
      • Locations of available shared vehicles (car-share, bike-share, scooters)
      • Parking status of micro-mobility units (safe/not safe, correctly/incorrectly parked)
  • Status of lights and bridges
    • Real-time directional status (green or red lights, closed or open bascule bridges)
  • Real-time flow and status data from other government agencies (WSDOT, Seattle Port, Washington Ferries)
  • Clearly delineated arterials so that a user (on foot or in a vehicle) can locate themselves or know that they are on an arterial
    • Geolocated starts and ends (entries and exits)
    • Identified by Bluetooth beacons or similar wireless technology
  • Show accurate location of fixed signs
    • Geolocated with type; e.g., STOP or speed limit signs
  • Show locations of infrastructure that users need
    • Transit stations and bus waiting areas
    • Ride-hail pickup zone
    • Publicly accessible restrooms
    • Wheelchair-accessible facilities
    • ADA ramps and elevators
    • Load zones
    • Delivery docks and zones
    • Parking locations
    • Pay stations
    • Charging stations
    • Bike and scooter parking
    • Drone docks or parking

SHOW REAL-TIME ROAD CLOSURES

    • Deliver advance and real-time information on road work and road closures
      • Show scheduled closures (with a time of day/day of the week function)
        • Look ahead for advance route planning purposes
        • Look back for predictive planning purposes
      • Show emergency or unscheduled closures
    • Real-time snowplow routes and locations, and other incident response
    • Locations of issues reported by travelers (complaints, reports, etc.)
      • In real-time after a certain threshold
        • Example: 20 calls about the same problem over a period of 30 minutes
        • Example: 50 calls about the same problem spread over one week

SHOW REAL-TIME ROUTES AND ROUTING

        • Deliver information on routes: routes to avoid, routes/re-routes to use, route fees
          • Plan routes based on slope and disability access (including ADA ramps and sidewalk conditions)
          • Routes, including directions and passenger volume, of high-capacity transit (rail and bus)
          • Inform mobility providers and users of routes to avoid in order to clear the way for emergency responders
          • Prioritize routes in real-time including routes for emergency vehicles
          • Determine best routes (routing algorithms with adjustable variables)
          • Provide real-time route charges or fees, incentives or disincentives (e.g., congestion fees or credits)
          • Direct providers and users to recommended routes (or route charges) in real-time

SHOW REAL-TIME URBAN GOODS DELIVERY

        • Show aggregated volumes of delivery vehicles along arterials and in urban centers
          • Look ahead for advance route planning purposes
          • Look back for predictive planning purposes

Show real-time curb use

        • Show curb use conditions
          • Real-time parking locations, counts and availability
          • Real-time parking and loading rules (allow SDOT to change conditions in real-time)
          • Real-time parking or loading fees
        • Allow SDOT to geofence areas to particular services in real-time for safety and security reasons
          • Restricting shared micro-mobility from certain routes and/or at certain times
          • Restricting shared-vehicle pick-ups and/or drop-offs from certain areas and/or at certain times

The Real-time Right of Way Conditions Map should integrate, and pull and send data to other maps as needed.

Appendix F: SDOT Information Infrastructure Backlog

We used an Agile approach in developing this plan. Agile project management “is an iterative development methodology that values human communication and feedback, adapting to changes, and producing working results.”[7]

In Agile project management, the “backlog” is a list of all tasks needed to complete the product. In this case, this is a list of key components of the information infrastructure that SDOT must build to fulfill the requirements of this plan. Each project is followed by a description or user requirements.

Following the Agile approach, this is a partial list. It is meant to be a starting point and a driver for discussion. It also needs to be broken down into smaller chunks of work for agile delivery.

As SDOT implements this plan, it will continue to revise this list, in order to prioritize what can be achieved quickly. Rather than setting out to deliver massive projects, the focus should be on delivering working components as quickly as possible.

Real-Time Right of Way Conditions Map

To manage the transportation network, the Real-time Right of Way Conditions Map should allow SDOT to:

Show real-time traffic flow, and road, curb and sidewalk use

  • Real-time traffic flow and volumes
    • Pedestrian aggregate volumes and flow  (at crosswalks and for specific routes)
    • Real-time locations of high-capacity transit (buses and rail)
    • Real-time routes cleared for emergency vehicles
    • Volume of shared vehicles while moving on arterials
    • Volumes of shared vehicles while moving in urban centers
    • Locations of urban delivery vehicles while moving on arterials
    • Real-time volume of delivery vehicles by block face
    • Real-time volume of shared-vehicle loading and unloading (at block face level)
    • Locations and availability of shared vehicles when not in use
      • Locations of available shared vehicles (car-share, bike-share, scooters)
      • Parking status of micro-mobility units (safe/not safe, correctly/incorrectly parked)
  • Status of lights and bridges
    • Real-time directional status (green or red lights, closed or open bascule bridges)
  • Real-time flow and status data from other government agencies (WSDOT, Seattle Port, Washington Ferries)
  • Clearly delineated arterials so that a user (on foot or in a vehicle) can locate themselves or know that they are on an arterial
    • Geolocated starts and ends (entries and exits)
    • Identified by Bluetooth beacons or similar wireless technology
  • Show accurate location of fixed signs
    • Geolocated with type; e.g., STOP or speed limit signs
  • Show locations of infrastructure that users need
    • Transit stations and bus waiting areas
    • Ride-hail pickup zone
    • Publicly accessible restrooms
    • Wheelchair-accessible facilities
    • ADA ramps and elevators
    • Load zones
    • Delivery docks and zones
    • Parking locations
    • Pay stations
    • Charging stations
    • Bike and scooter parking
    • Drone docks or parking

SHOW REAL-TIME ROAD CLOSURES

    • Deliver advance and real-time information on road work and road closures
      • Show scheduled closures (with a time of day/day of the week function)
        • Look ahead for advance route planning purposes
        • Look back for predictive planning purposes
      • Show emergency or unscheduled closures
    • Real-time snowplow routes and locations, and other incident response
    • Locations of issues reported by travelers (complaints, reports, etc.)
      • In real-time after a certain threshold
        • Example: 20 calls about the same problem over a period of 30 minutes
        • Example: 50 calls about the same problem spread over one week

SHOW REAL-TIME ROUTES AND ROUTING

        • Deliver information on routes: routes to avoid, routes/re-routes to use, route fees
          • Plan routes based on slope and disability access (including ADA ramps and sidewalk conditions)
          • Routes, including directions and passenger volume, of high-capacity transit (rail and bus)
          • Inform mobility providers and users of routes to avoid in order to clear the way for emergency responders
          • Prioritize routes in real-time including routes for emergency vehicles
          • Determine best routes (routing algorithms with adjustable variables)
          • Provide real-time route charges or fees, incentives or disincentives (e.g., congestion fees or credits)
          • Direct providers and users to recommended routes (or route charges) in real-time

SHOW REAL-TIME URBAN GOODS DELIVERY

        • Show aggregated volumes of delivery vehicles along arterials and in urban centers
          • Look ahead for advance route planning purposes
          • Look back for predictive planning purposes

Show real-time curb use

        • Show curb use conditions
          • Real-time parking locations, counts and availability
          • Real-time parking and loading rules (allow SDOT to change conditions in real-time)
          • Real-time parking or loading fees
        • Allow SDOT to geofence areas to particular services in real-time for safety and security reasons
          • Restricting shared micro-mobility from certain routes and/or at certain times
          • Restricting shared-vehicle pick-ups and/or drop-offs from certain areas and/or at certain times

The Real-time Right of Way Conditions Map should integrate, and pull and send data to other maps as needed.

SDOT API strategy (SDOT I/O)

To deliver on the information needs of the Real-time Right of Way Conditions Map above and to deliver information that can be ingested in real-time by transportation information and mobility service providers, SDOT needs to build a coherent strategy of pushing data out and taking data in via APIs and data feeds.

SDOT needs to push out:

  • Status of lights and bridges
  • Location of fixed signs (particularly regulatory signs) and digital mobile signs
  • Real-time information on road work and road closures
    • Scheduled closures
    • Emergency or unscheduled closures
    • Status of work (estimated time to restoration of traffic flow)
  • Routes to avoid, routes/re-routes to use, route fees
    • Routes to avoid to clear the way for emergency responders
    • Prioritized routes for emergency responders
    • Prioritized or recommended routes in real-time (for all users)
    • Route charges or fees (e.g., congestion fees)
    • Real-time routing algorithms – e.g., find the best route
    • Real-time incentives or disincentives, e.g., fees or credits
  • Locations of infrastructure that users need (see above)
  • Curb use conditions
    • Real-time parking locations, counts and availability
    • Real-time loading locations for urban goods delivery
    • Real-time parking and loading rules (allow SDOT to change conditions in real-time)
    • Real-time parking or loading fees
    • Real-time ride-hail pickup or drop-off areas
  • Real-time traffic flow and volumes by arterials
  • Geofenced areas to particular services in real-time for safety and security reasons
  • Geolocated arterials (starts and ends, entries and exits)
  • Locations of issues of concern (non-closure, non-emergency); e.g., potholes, unsafe intersections
  • Advisories (emergencies, etc.) to all transportation app users

SDOT needs to take in:

  • Real-time vehicle location data from emergency responders
  • Real-time notifications of requests for help from users
  • Real-time emergency location and status from emergency responders
  • Real-time vehicle location data from high-capacity transit providers (bus and rail)
  • Real-time fee schedules for high-capacity transit
  • Real-time re-routes of high-capacity transit
  • Real-time passenger counts, wait times and locations from high-capacity transit providers
  • Real-time vehicle location of shared vehicles while on arterials
  • Real-time volumes of urban freight delivery vehicles while on arterials and while in in urban centers
  • Real-time volumes of loading and unloading of shared vehicles and urban freight delivery by blockface in urban centers
  • Real-time locations of available shared vehicles (including micro-mobility) while parked
  • Locations of emergency calls/panic button activations from transportation service users
  • Traffic volume and flow data from information service providers (e.g., Google, Waze, Apple)
  • Complaints from users about SDOT services or the transportation network
  • Relevant data feeds and APIs from other city agencies, including the Seattle Department of Construction and Inspections, Seattle Public Utilities, Seattle City Light
  • Real-time transactions for payments (in the use of data or physical infrastructure

All APIs and data feeds should be tested for accessibility using systems that serve the visually impaired or hearing impaired.

Information Delivery Unit (or Office)

The IDU should be a small team (no more than eight members) composed of:

  • Project managers with experience in Agile methods
  • Product managers who can shepherd components of the API and feeds plans
  • Team members conversant in the technology of APIs and data feeds, particularly as they are used in mapping, geolocation and geographic information systems
  • Team members who understand the current ecosystem and can understand data engineers and analysts

Mobile digital workforce and supply inventory

These two projects go hand in hand. The mobile digital workforce initiative should ensure that on-the-ground SDOT staff can use SDOT’s map systems and databases remotely. This would require:

  • Accurate vehicle location systems and/or accurate GPS-enabled gadgets (particularly while at a work site for emergency road closures)
  • Interfaces to SDOT’s systems designed to be mobile-first, for tablets or smartphones (current maps are web-based)
  • All interfaces designed to be available and accessible to systems that serve the visually impaired or the hearing impaired

The supply inventory should allow SDOT to barcode and geolocate materials meant for assets in the right of way. This should particularly focus on signage.

Both the mobile digital workforce initiative and the supply inventory should center on improving the flow of information for work orders.

Validated asset inventory

SDOT needs to update the database that stores an inventory of our right of way assets (pavement, sidewalks, ramps, trees, signals, signs, etc.). The information must be audited periodically (based on how critical the asset is) and systematically to assure validity and accuracy.

SDOT should pursue processes and invest the resources for gathering and storing right of way asset data automatically and expeditiously.  SDOT needs to ensure the trustworthiness of the asset inventory.

As the technology becomes available, SDOT should also pursue processes and methods to capture performance data on major assets and generate usage reports automatically on the same assets.

Future Right of Way Conditions Map

The Future Right of Way Conditions Map should:

  • Allow other map systems to ingest SDOT’s plans in digital map form
  • Be interactive and API-enabled so the data can be ported to other open-standards map platforms
  • For projects, show details of where major components or structures are going to be located

TCP on Map

SDOT should enable map-based submissions of permit requests and plans. In practice, this should allow permit applicants to locate the relevant streets and intersections on a map, select them, and launch a submission that includes database-ready information on the affected segments of the right of way.[8]

SDOT should be able to locate all TCPs (permitted or in process) on a map so as to compare easily the possible impacts to both schedules and roads of each TCP against other TCPs.

The TCP on Map project should allow SDOT staff to use the map to zoom in to the traffic configuration proposed. This functionality could be either an expansion or extension of dotMaps or a new platform.

The TCP on Map and dotMaps should have a protocol and an automatic process for moving TCP data to the Real-time Right of Way Conditions Map when the TCP becomes current/active.

Plans on Map

Segments and portions of SDOT’s modal plans are available via online GIS maps. The full maps of the plans themselves are released as part of the document and may available as standalone PDF files. The available segments are often in disparate map layers that are not available for superimposing on other maps.

SDOT should explore displaying the modal plan maps on interactive, web-accessible maps built on open platforms such as Open Street Maps and/or SharedStreets. This will facilitate layering the map on other information available to SDOT or other actors in the ecosystem and lead to better analysis.

Capital Projects on Map

Capital Projects, particularly if they have achieved final design, should be available on a map. The map should be detailed enough to show how the project affects the right of way and should indicate when the project is complete (and all digital assets related to the project have been submitted to and received by SDOT).

Putting the projects on a web-accessible map should be a required part of the submission of digital assets at the final turnover of the completed capital project.

 

Urban goods delivery

Building on the success of the Last 50 Feet project with the University of Washington’s Urban Freight Lab, SDOT should build systems and that can plug in to the ecosystem of logistics.

Package tracking is at the core of logistics and is critical to the supply chains of nearly every industry. It powers urban goods delivery systems.

SDOT’s system should allow it to see volumes and flows of vehicle movements but not receive any data about individual packages or the volume of packages. This information is particularly critical to managing arterials and traffic flows in Seattle’s urban centers and urban villages.

To help the logistics and urban goods delivery companies, SDOT should be able to push out real-time information on the availability of loading docks or loading curbs.

Embedded systems/sensors

SDOT should continue to build out its sensor network, in conformity to the city’s Surveillance Ordinance.

While current sensor systems (WiFi sensors, license-plate readers) gather data for SDOT, future components of the system should broadcast information, even static, locational information.

For example, beacons on arterials could help confirm the locations of vehicles and service providers. This will facilitate possible transactions (curb use fees or congestion fees).

SDOT should make particular efforts to improve its sensing methods for pedestrians and public life.

Open311 or similar systems

An Open311-compliant system will help SDOT improve service and create better information flow between the call center (684-ROAD and 684-TREE), the crews, and traffic operations.[9]

Information connectivity/information flow improvements

SDOT’s current systems have serious gaps in the flow of information. The department should continue to review all its processes to find ways to improve information flow.

It should pay particular attention to where there are non-digital handoffs of information that is already digitized – i.e., where digital information is manually processed and then turned back into digital information. For example, CAD information may be printed out and then re-entered by hand into databases, or digital records of road closure events must be aggregated individually into reports.

SDOT should strive for digital-to-digital information transmissions where possible. All documents should be machine-readable.

Machine learning and predictive AI

SDOT should expand its capacities in understanding and deploying machine language and AI, for two reasons:

  • To turn the information it is gathering into insight and intelligence
  • To have the capacity to evaluate, manage and regulate transportation systems that use machine learning and AI–particularly to ensure that these systems do not discriminate and instead can help to disassemble racist and discriminatory systems.

Footnotes:

[7] https://blog.capterra.com/definition-of-agile-project-management/

[8] There are currently two online maps that show part of this information: the Traffic Control Plans Map and Project and Construction Coordination Map. The Traffic Control Plans Map is not interactive and only shows users what the current lane configurations are. Applicants can use the map as a reference but there is no way to export the data. Applicants usually take a screenshot instead. The Project Construction and Coordination Map is dotMaps and displays the permitted projects, schedules and nature of work but currently does not carry traffic control configurations.

[9] SDOT needs to evaluate how its current system meets the needs of users.

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 draft_tiip@seattle.gov.

If you have questions about SDOT, please visit our website at www.seattle.gov/transporation.

Designed by Story 2 Designs

Privacy Policy