Max Speed limit values in miles per hour. This data is an extract from the Geospatial Roadway Inventory Databse (GRID), which is TxDOT's system for managing roadway assets in Texas.Note: Extracts from GRID are made on a regular basis and reflect the state of the data at that moment. Assets on routes that are in the process of being edited may be affected.Update Frequency: 1 MonthsSource: Geospatial Roadway Inventory Database (GRID)Security Level: PublicOwned by TxDOT: TrueRelated LinksData Dictionary PDF [Generated 2025/04/24]

Speed limit information for most of Queensland's roads. Includes state and locally controlled roads. Point-in-time data as per date of collection in dataset.

Speed limits for state maintained roads in North Carolina as designated by ordinances and the TEAAS (Traffic Engineering Accident Analysis System) database. Speed limits are controlled by general statutes and local and state ordinances. Within incorporated municipalities, the statutory speed limit is 35 miles per hour unless otherwise ordinanced and posted. The statutory speed limit on roads outside the incorporated municipalities is 55 miles per hour unless otherwise ordinanced and posted. Some highways have speed limits of up to 70 miles per hour on certain sections. However, the speed limit along these routes may drop to 55 miles per hour when they pass through certain areas. Speed limits for P5 were pulled Prioritization 5.0 (P5) and from Road Characteristics (TEAAS). The primary routes were edited throughout the other iterations of Prioritizations and therefore these were used for P6.0 and then overlaid with what was in Road Characteristics for Q1 2019. These changes were made manually by the GIS Department.For the purpose of the Strategic Planning Office of Transportation Prioritization 6.0 project (P6), speed limit data is not updated after July 2019. For the P6 application, speed limit data is helpful in aiding the user in selecting a project speed limit, calculating the travel time savings, and helping to calculate congestion criteria.

Esri ArcGIS Online (AGOL) Hosted, View Feature Layer which provides access to the MDOT SHA Roadway Posted Speed Limit Signs data product.MDOT SHA Roadway Posted Speed Limit Signs data consists of point geometric features which represent the geographic locations of posted speed limit signs along MDOT SHA-maintained roadways throughout the State of Maryland. This layer is a hosted, view layer showing only Posted Speed Limit signage from the comprehensive MDOT SHA Roadway Sign Inventory. Roadway signs that share a sign support structure will be represented as stacked geometry.MDOT SHA Roadway Sign Inventory data is owned by the MDOT SHA Office of Traffic & Safety (OOTS). This data is currently updated on an annual basis. This is the latest version of the data, which was last updated in November 2019 (11/04/2019).MDOT SHA Roadway Sign Inventory data is published on ArcGIS Online for Maryland as a publicly available Hosted Feature Layer with Non-Restricted Access. Download / Export of the data is available in a variety of formats.For additional information, contact MDOT SHA OIT Enterprise Information Services:GIS@mdot.maryland.gov

This map provides information on speed limits that are posted on state-maintained roadways in Virginia. Cities and towns set their own speed limits and these are not available to show on the map. Zoom in on the map to display the speed limits. Speed limits exist for all roads however; where this information is not available for mapping, they are not displayed. Most roads where speed limits are not shown are either rural, secondary roads (routes numbered 600 or greater) where a statutory 55 mph speed limit typically applies, or subdivision streets where a statutory 25 mph speed limit usually applies. These statutory speed limits are often are not posted on these roads. Click on any roadway to display the speed limit information.

Displays Speed Limit Ordinances for the City of Tucson. Created by copying features from stnetall.PurposeLine Layer that shows the speed limits of streets in Tucson.Dataset ClassificationLevel 0 - OpenKnown UsesUsed in Various Web MapsKnown ErrorsUrban streets from 12000 scale & rural streets from 100000 scale; 1/3 streets rectified to parcel base. 10/2013: While this layer is maintained as a Shapefile, the coverage format is still required for certain nightly processing. Data ContactDepartment of Transportation and MobilityUpdate FrequencyUpdated as needed

This dataset contains information relating to ACT Speed Zones.

DATASET DISCLAIMER: This dataset shall be used for general reference only. Because of the complexity in processing to generate this dataset, we cannot be liable for omissions and inaccuracies. Users of this dataset are encouraged to check with related agencies if you have any concerns about the data displayed. Please be aware that new data are added and changed periodically, and data may become out-of-date quickly due to change in business processes and data processing time. TCCS disclaims liability to any person/entity who acts in reliance on the information provided on this dataset. This dataset does not have any legal status, and it may not correspond with the actual speed limit since the date of publication.

Speed zones are set to enable drivers travelling at a speed limit to safely respond to potential risks in the road environment. This dataset contains data for NSW speed zones that are categorised as: Ordinary Permanent Shared High Pedestrian School Variable Local Traffic Truck & bus Wet Weather School Bus Toll Plaza

Maryland Bicycle Level of Traffic Stress (LTS) An overview of the methodology and attribute data is provided below. For a detailed full report of the methodology, please view the PDF published by the Maryland Department of Transportation here. The Maryland Department of Transportation is transitioning from using the Bicycle Level of Comfort (BLOC) to using the Level of Traffic Stress (LTS) for measuring the “bikeability” of the roadway network. This transition is in coordination with the implementation of MDOT SHA’s Context Driven Design Guidelines and other national and departmental initiatives. LTS is preferred over BLOC as LTS requires fewer variables to calculate including:Presence and type of bicycle facilitySpeed limitNumber of Through Lanes/Traffic VolumeTraditionally, the Level of Traffic Stress (LTS) (scale “1” to “4”) is a measure for assessing the quality of the roadway network for its comfort with various bicycle users. The lower the LTS score, the more inviting the bicycle facility is for more audiences.LTS Methodology (Overview) MDOT’s LTS methodology is based on the metrics established by the Mineta Transportation Institute (MTI) Report 11-19 “Low-Stress Bicycling and Network Connectivity (May 2012) - additional criteria refined by Dr. Peter G. Furth (June 2017) below and Montgomery County's Revised Level of Traffic Stress. Shared-use Path Data Development and Complimentary Road Separated Bike Routes DatasetA complimentary dataset – Road Separated Bike Routes, was completed prior to this roadway dataset. It has been provided to the public via (https://maryland.maps.arcgis.com/home/item.html?id=1e12f2996e76447aba89099f41b14359). This first dataset is an inventory of all shared-use paths open to public, two-way bicycle access which contribute to the bicycle transportation network. Shared-use paths and sidepaths were assigned an LTS score of “0” to indicate minimal interaction with motor vehicle traffic. Many paved loop trails entirely within parks, which had no connection to the adjacent roadway network, were not included but may be included in future iterations. Sidepaths, where a shared-use path runs parallel to an adjacent roadway, are included in this complimentary Road Separated Bike Routes Dataset. Sidepaths do not have as an inviting biking environment as shared-use paths with an independent alignment due to the proximity of motor vehicle traffic in addition to greater likelihood of intersections with more roadways and driveways. Future iterations of the LTS will assign an LTS score of “1” to sidepaths. On-street Bicycle Facility Data Development This second dataset includes all on-road bicycle facilities which have a designated roadway space for bicycle travel including bike lanes and protected bike lanes. Marked shared lanes in which bicycle and motor vehicle traffic share travel lanes were not included. Shared lanes, whether sharrows, bike boulevards or signed routes were inventoried but treated as mixed traffic for LTS analysis. The bicycle facilities included in the analysis include:

Standard Bike Lanes – A roadway lane designated for bicycle travel at least 5-feet-wide. Bike lanes may be located against the curb or between a parking lane and a motor vehicle travel lane. Buffered bike lanes without vertical separation from motor vehicle traffic are included in this category. Following AASHTO and MDOT SHA design standards, bike lanes are assumed to be at least 5-feet-wide even through some existing bike lanes are less than 5-feet-wide.
Protected Bike Lanes – lanes located within the street but are separated from motor vehicle travel lanes by a vertical buffer, whether by a row of parked cars, flex posts or concrete planters. Shoulders – Roadway shoulders are commonly used by bicycle traffic. As such, roadways with shoulders open to bicycle traffic were identified and rated for LTS in relation to adjacent traffic speeds and volumes as well as the shoulder width. Shoulders less than 5-feet-wide, the standard bike lane width, were excluded from analysis and these roadway segments were treated as mixed traffic.

The Office of Highway Development at MDOT SHA provided the on-street bicycle facility inventory data for state roadways. The shared-use path inventory and on-street bicycle facility inventory was compiled from local jurisdiction’s open-source download or shared form the GIS/IT departments. Before integrating into OMOC, these datasets were verified by conducting desktop surveys and site visits, and by consulting with local officials and residents.
Data UsesThe 2022 LTS data produced through this process can be used in a variety of planning exercises. The consistent metrics applied across the state will help inform bicycle mobility and accessibility decisions at state and local levels. Primarily, the LTS analysis illustrates how bikeable Maryland roads are where the greatest barriers lie. While most roads in the state are an LTS 1, the main roadways which link residential areas with community services are typically LTS 4. In the coming months, MDOT will use the LTS in variety of way including:

Conducting a bicycle network analysis to develop accessibility measures and potential performance metrics. Cross-referencing with state crash location data; Performing gap analysis to help inform project prioritization.

Data Limitations A principle of data governance MDOT strives to provide the best possible data products. While the initial LTS analysis of Maryland’s bicycle network has many uses, it should be used with a clear understanding of the current limitations the data presents.

Assumptions - As noted earlier in this document, some of the metrics used to determine LTS score were estimated. Speed limits for many local roadways were not included in the original data and were assigned based on the functional classification of the roadway. Speed limits are also based on the posted speed limit, not the prevailing operating vehicle speeds which can vary greatly. Such discrepancies between actual and assumed conditions could introduce margins of error in some cases. As data quality improves with future iterations, the LTS scoring accuracy will also improve. Generalizations - MDOT’s LTS methodology follows industry standards but needs to account for varying roadway conditions and data reliability from various sources. The LTS methodology aims to accurately capture Maryland’s bicycle conditions and infrastructure but must consider data maintenance requirements. To limit data maintenance generalizations were made in the methodology so that a score could be assigned. Specifically, factors such as intersections, intersection approaches and bike lane blockages are not included in this initial analysis. LTS scores may be adjusted in the future based on MDOT review, updated industry standards, and additional LTS metrics being included in OMOC such as parking and buffer widths.
Timestamped - As the LTS score is derived from a dynamic linear referencing system (LRS), any LTS analysis performed reflects the data available in OMOC. Each analysis must be considered ‘timestamped’ and becoming less reliable with age. As variables within OMOC change, whether through documented roadway construction, bikeway improvements or a speed limit reduction, LTS scores will also change. Fortunately, as this data is updated in the linear referencing system, the data becomes more reliable and LTS scores become more accurate. --------------------------------------------------------------------------------------------------------------------------------------------------------------------Level of Traffic Stress (LTS) Attribute Metadata OBJECTID | GIS Object IDState ID (ID) | Unique identification number provided by Maryland State Highway Administration (MDOT SHA)Route ID (ROUTEID) | Unique identification number for the roadway segment/record as determined by Maryland State Highway Administration (MDOT SHA) From Measure (FROMMEASURE) | The mileage along the roadway record that the specific roadway conditions change and maintain the same conditions until To MeasureTo Measure (TOMEASURE) | The mileage along the roadway record that the specific roadway conditions change and maintain the same conditions since From MeasureRoadway Functional Class (FUNCTIONAL_CLASS) | The functional classification of the roadway as determined by the Federal Highway Administration in coordination with the Maryland Department of Transportation State Highway Administration (MDOT SHA). All roadway records have a functional classification value. The following values represent the functional classification:

1 - Local 2 - Minor collector 3 - Major collector 4 - Minor arterial 5 - Principal Arterial (other) 6 - Principal Arterial (other Freeways and Expressways) 7 - Interstate

Annual Average Daily Traffic (AADT) | The Annual Average Daily Traffic (AADT) represents the average number of motor vehicles that pass along a roadway segment during a 24-hour period. The value is derived from MDOT SHA’s Traffic Monitoring System (TMS), the state’s clearinghouse for all traffic volume records. Roadway Speed Limit (SPEED_LIMIT) | The posted speed limit for a roadway segment as assigned by the MDOT SHA for state roadways and the local jurisdiction’s transportation management agency. Values for SPEED_LIMIT are measured in miles per hour (mph) in 5 mph increments from 5 mph through 70 mph. Roadway Access Control (ACCESS_CONTROL) | The access control indicates the types of entry points along the roadway segment, ranging from full to no access control. Interstates and other state roadways with no at-grade crossings are full access control, whereas a neighborhood street open to all modes of traffic represents a roadway with no access control. The values in

This dataset includes a multimodal assessment of the Cleveland Transportation Network, conducted as part of the Cleveland Moves initiative. It assesses need and comfort levels as we work to improve safety and mobility on Cleveland streets.The Pedestrian Crossing Level of Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, and the presence of a pedestrian island to calculate how stressful a crossing is for someone crossing. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The Bicycle Level of Traffic Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, the type of bikeway, and more to calculate the level of stress for someone riding a bicycle on a given street. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The ODOT Active Transportation Need layer was created by the Ohio Department of transportation, and uses several factors to determine need including access to a vehicle, poverty rates, and more.Update FrequencyThis dataset will be updated with additional analysis from the Cleveland Moves planning process by early 2025. After that point, it will be updated annually to reflect changes to Cleveland streets geared towards improving safety and mobility. Related ApplicationsA summary of this dataset can be found in the Cleveland Moves Network Assessment Dashboard.Data GlossaryThe ODOT Active Transportation Need dataset was developed by the Ohio Department of Transportation. More information about this dataset is available on their website: https://gis.dot.state.oh.us/tims_classic/Glossary ContactSarah Davis, Active Transportation Senior Plannersdavis2@clevelandohio.gov

Road segments representing centerlines of all roadways or carriageways in a local government. Typically, this information is compiled from orthoimagery or other aerial photography sources. This representation of the road centerlines support address geocoding and mapping. It also serves as a source for public works and other agencies that are responsible for the active management of the road network. (From ESRI Local Government Model "RoadCenterline" Feature)**This dataset was significantly revised in August of 2014 to correct for street segments that were not properly split at intersections. There may be issues with using data based off of the original centerline file. ** The column Speed Limit was updated in November 2014 by the Transportation Intern and is believed to be accurate** The column One Way was updated in November of 2014 by core GIS and is believed to be accurate.[MAXIMOID] A unique id field used in a work order management software called Maximo by IBM. Maximo uses GIS CL data to assign locations to work orders using this field. This field is maintained by the Transportation GIS specialists and is auto incremented when new streets are digitized. For example, if the latest digitized street segment MAXIMOID = 999, the next digitized line will receive MAXIMOID = 1000, and so on. STREET NAMING IS BROKEN INTO THREE FIELDS FOR GEOCODING:PREFIX This field is attributed if a street name has a prefix such as W, N, E, or S.NAME Domain with all street names. The name of the street without prefix or suffix.ROAD_TYPE (Text,4) Describes the type of road aka suffix, if applicable. CAPCOG Addressing Guidelines Sec 504 U. states, “Every road shall have corresponding standard street suffix…” standard street suffix abbreviations comply with USPS Pub 28 Appendix C Street Abbreviations. Examples include, but are not limited to, Rd, Dr, St, Trl, Ln, Gln, Lp, CT. LEFT_LOW The minimum numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 101.LEFT_HIGH The largest numeric address on the left side of the CL segment. Left side of CL is defined as the left side of the line segment in the From-To direction. For example, if a line has addresses starting at 101 and ending at 201 on its left side, this column will be attributed 201.LOW The minimum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 100.HIGHThe maximum numeric address on the RIGHT side of the CL segment. Right side of CL is defined as the right side of the line segment in the From-To direction. For example, if a line has addresses starting at 100 and ending at 200 on its right side, this column will be attributed 200.ALIAS Alternative names for roads if known. This field is useful for geocode re-matching. CLASSThe functional classification of the centerline. For example, Minor (Minor Arterial), Major (Major Arterial). THIS FIELD IS NOT CONSISTENTLY FILLED OUT, NEEDS AN AUDIT. FULLSTREET The full name of the street concatenating the [PREFIX], [NAME], and [SUFFIX] fields. For example, "W San Antonio St."ROWWIDTH Width of right-of-way along the CL segment. Data entry from Plat by Planning GIS Or from Engineering PICPs/ CIPs.NUMLANES Number of striped vehicular driving lanes, including turn lanes if present along majority of segment. Does not inlcude bicycle lanes. LANEMILES Describes the total length of lanes for that segment in miles. It is manually field calculated as follows (( [ShapeLength] / 5280) * [NUMLANES]) and maintained by Transportation GIS.SPEEDLIMIT Speed limit of CL segment if known. If not, assume 30 mph for local and minor arterial streets. If speed limit changes are enacted by city council they will be recorded in the Traffic Register dataset, and this field will be updating accordingly. Initial data entry made by CIP/Planning GIS and maintained by Transportation GIS.[YRBUILT] replaced by [DateBuilt] See below. Will be deleted. 4/21/2017LASTYRRECON (Text,10) Is the last four-digit year a major reconstruction occurred. Most streets have not been reconstructed since orignal construction, and will have values. The Transportation GIS Specialist will update this field. OWNER Describes the governing body or private entity that owns/maintains the CL. It is possible that some streets are owned by other entities but maintained by CoSM. Possible attributes include, CoSM, Hays Owned/City Maintained, TxDOT Owned/City Maintained, TxDOT, one of four counties (Hays, Caldwell, Guadalupe, and Comal), TxState, and Private.ST_FROM Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the From- direction. Should be edited when new CL segments that cause splits are added. ST_TO Centerline segments are split at their intersections with other CL segments. This field names the nearest cross-street in the To- direction. Should be edited when new CL segments that cause splits are added. PAV_WID Pavement width of street in feet from back-of-curb to back-of-curb. This data is entered from as-built by CIP GIS. In January 2017 Transportation Dept. field staff surveyed all streets and measured width from face-of-curb to face-of-curb where curb was present, and edge of pavement to edge of pavement where it was not. This data was used to field calculate pavement width where we had values. A value of 1 foot was added to the field calculation if curb and gutter or stand up curb were present (the face-of-curb to back-of-curb is 6 in, multiple that by 2 to find 1 foot). If no curb was present, the value enter in by the field staff was directly copied over. If values were already present, and entered from asbuilt, they were left alone. ONEWAY Field describes direction of travel along CL in relation to digitized direction. If a street allows bi-directional travel it is attributed "B", a street that is one-way in the From_To direction is attributed "F", a street that is one-way in the To_From direction is attributed "T", and a street that does not allow travel in any direction is attibuted "N". ROADLEVEL Field will be aliased to [MINUTES] and be used to calculate travel time along CL segments in minutes using shape length and [SPEEDLIMIT]. Field calculate using the following expression: [MINUTES] = ( ([SHAPE_LENGTH] / 5280) / ( [SPEEDLIMIT] / 60 ))ROWSTATUS Values include "Open" or "Closed". Describes whether a right-of-way is open or closed. If a street is constructed within ROW it is "Open". If a street has not yet been constructed, and there is ROW, it is "Cosed". UPDATE: This feature class only has CL geometries for "Open" rights-of-way. This field should be deleted or re-purposed. ASBUILT field used to hyper link as-built documents detailing construction of the CL. Field was added in Dec. 2016. DateBuilt Date field used to record month and year a road was constructed from Asbuilt. Data was collected previously without month information. Data without a known month is entered as "1/1/YYYY". When month and year are known enter as "M/1/YYYY". Month and Year from asbuilt. Added by Engineering/CIP. ACCEPTED Date field used to record the month, day, and year that a roadway was officially accepted by the City of San Marcos. Engineering signs off on acceptance letters and stores these documents. This field was added in May of 2018. Due to a lack of data, the date built field was copied into this field for older roadways. Going forward, all new roadways will have this date. . This field will typically be populated well after a road has been drawn into GIS. Entered by Engineering/CIP. ****In an effort to make summarizing the data more efficient in Operations Dashboard, a generic date of "1/1/1900" was assigned to all COSM owned or maintained roads that had NULL values. These were roads that either have not been accepted yet, or roads that were expcepted a long time ago and their accepted date is not known. WARRANTY_EXP Date field used to record the expiration date of a newly accepted roadway. Typically this is one year from acceptance date, but can be greater. This field was added in May of 2018, so only roadways that have been excepted since and older roadways with valid warranty dates within this time frame have been populated.

This dataset includes a multimodal assessment of the Cleveland Transportation Network, conducted as part of the Cleveland Moves initiative. It assesses need and comfort levels as we work to improve safety and mobility on Cleveland streets.The Pedestrian Crossing Level of Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, and the presence of a pedestrian island to calculate how stressful a crossing is for someone crossing. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The Bicycle Level of Traffic Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, the type of bikeway, and more to calculate the level of stress for someone riding a bicycle on a given street. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The ODOT Active Transportation Need layer was created by the Ohio Department of transportation, and uses several factors to determine need including access to a vehicle, poverty rates, and more.Update FrequencyThis dataset will be updated with additional analysis from the Cleveland Moves planning process by early 2025. After that point, it will be updated annually to reflect changes to Cleveland streets geared towards improving safety and mobility. Related ApplicationsA summary of this dataset can be found in the Cleveland Moves Network Assessment Dashboard.Data GlossaryThe ODOT Active Transportation Need dataset was developed by the Ohio Department of Transportation. More information about this dataset is available on their website: https://gis.dot.state.oh.us/tims_classic/Glossary ContactSarah Davis, Active Transportation Senior Plannersdavis2@clevelandohio.gov

Helsinki Region Travel Time Matrix contains travel time and distance information for routes between all 250 m x 250 m grid cell centroids (n = 13231) in the Helsinki Region, Finland by walking, cycling, public transportation and car. The grid cells are compatible with the statistical grid cells used by Statistics Finland and the YKR (yhdyskuntarakenteen seurantajärjestelmä) data set. The Helsinki Region Travel Time Matrix is available for three different years:

• 2018
• 2015
• 2013

The data consists of travel time and distance information of the routes that have been calculated between all statistical grid cell centroids (n = 13231) by walking, cycling, public transportation and car.

The data have been calculated for two different times of the day: 1) midday and 2) rush hour.

The data may be used freely (under Creative Commons 4.0 licence). We do not take any responsibility for any mistakes, errors or other deficiencies in the data.

Organization of data

The data have been divided into 13231 text files according to destinations of the routes. The data files have been organized into sub-folders that contain multiple (approx. 4-150) Travel Time Matrix result files. Individual folders consist of all the Travel Time Matrices that have same first four digits in their filename (e.g. 5785xxx).

In order to visualize the data on a map, the result tables can be joined with the MetropAccess YKR-grid shapefile (attached here). The data can be joined by using the field ‘from_id’ in the text files and the field ‘YKR_ID’ in MetropAccess-YKR-grid shapefile as a common key.

Data structure

The data have been divided into 13231 text files according to destinations of the routes. One file includes the routes from all statistical grid cells to a particular destination grid cell. All files have been named according to the destination grid cell code and each file includes 13231 rows.

NODATA values have been stored as value -1.

Each file consists of 17 attribute fields: 1) from_id, 2) to_id, 3) walk_t, 4) walk_d, 5) bike_f_t, 6) bike_s_t, 7) bike_d, 8) pt_r_tt, 9) pt_r_t, 10) pt_r_d, 11) pt_m_tt, 12) pt_m_t, 13) pt_m_d, 14) car_r_t, 15) car_r_d, 16) car_m_t, 17) car_m_d, 18) car_sl_t

The fields are separated by semicolon in the text files.

Attributes

• from_id: ID number of the origin grid cell
• to_id: ID number of the destination grid cell
• walk_t: Travel time in minutes from origin to destination by walking
• walk_d: Distance in meters of the walking route
• bike_f_t: Total travel time in minutes from origin to destination by fast cycling; Includes extra time (1 min) that it takes to take/return bike
• bike_s_t: Total travel time in minutes from origin to destination by slow cycling; Includes extra time (1 min) that it takes to take/return bike
• bike_d:Distance in meters of the cycling route
• pt_r_tt: Travel time in minutes from origin to destination by public transportation in rush hour traffic; whole travel chain has been taken into account including the waiting time at home
• pt_r_t: Travel time in minutes from origin to destination by public transportation in rush hour traffic; whole travel chain has been taken into account excluding the waiting time at home
• pt_r_d: Distance in meters of the public transportation route in rush hour traffic
• pt_m_tt: Travel time in minutes from origin to destination by public transportation in midday traffic; whole travel chain has been taken into account including the waiting time at home
• pt_m_t: Travel time in minutes from origin to destination by public transportation in midday traffic; whole travel chain has been taken into account excluding the waiting time at home
• pt_m_d: Distance in meters of the public transportation route in midday traffic
• car_r_t: Travel time in minutes from origin to destination by private car in rush hour traffic; the whole travel chain has been taken into account
• car_r_d: Distance in meters of the private car route in rush hour traffic
• car_m_t: Travel time in minutes from origin to destination by private car in midday traffic; the whole travel chain has been taken into account
• car_m_d: Distance in meters of the private car route in midday traffic
• car_sl_t: Travel time from origin to destination by private car following speed limits without any additional impedances; the whole travel chain has been taken into account

METHODS

For detailed documentation and how to reproduce the data, see HelsinkiRegionTravelTimeMatrix2018 GitHub repository.

THE ROUTE BY CAR have been calculated with a dedicated open source tool called DORA (DOor-to-door Routing Analyst) developed for this project. DORA uses PostgreSQL database with PostGIS extension and is based on the pgRouting toolkit. MetropAccess-Digiroad (modified from the original Digiroad data provided by Finnish Transport Agency) has been used as a street network in which the travel times of the road segments are made more realistic by adding crossroad impedances for different road classes.

The calculations have been repeated for two times of the day using 1) the “midday impedance” (i.e. travel times outside rush hour) and 2) the “rush hour impendance” as impedance in the calculations. Moreover, there is 3) the “speed limit impedance” calculated in the matrix (i.e. using speed limit without any additional impedances).

The whole travel chain (“door-to-door approach”) is taken into account in the calculations:
1) walking time from the real origin to the nearest network location (based on Euclidean distance),
2) average walking time from the origin to the parking lot,
3) travel time from parking lot to destination,
4) average time for searching a parking lot,
5) walking time from parking lot to nearest network location of the destination and
6) walking time from network location to the real destination (based on Euclidean distance).

THE ROUTES BY PUBLIC TRANSPORTATION have been calculated by using the MetropAccess-Reititin tool which also takes into account the whole travel chains from the origin to the destination:
1) possible waiting at home before leaving,
2) walking from home to the transit stop,
3) waiting at the transit stop,
4) travel time to next transit stop,
5) transport mode change,
6) travel time to next transit stop and
7) walking to the destination.

Travel times by public transportation have been optimized using 10 different departure times within the calculation hour using so called Golomb ruler. The fastest route from these calculations are selected for the final travel time matrix.

THE ROUTES BY CYCLING are also calculated using the DORA tool. The network dataset underneath is MetropAccess-CyclingNetwork, which is a modified version from the original Digiroad data provided by Finnish Transport Agency. In the dataset the travel times for the road segments have been modified to be more realistic based on Strava sports application data from the Helsinki region from 2016 and the bike sharing system data from Helsinki from 2017.

For each road segment a separate speed value was calculated for slow and fast cycling. The value for fast cycling is based on a percentual difference between segment specific Strava speed value and the average speed value for the whole Strava data. This same percentual difference has been applied to calculate the slower speed value for each road segment. The speed value is then the average speed value of bike sharing system users multiplied by the percentual difference value.

The reference value for faster cycling has been 19km/h, which is based on the average speed of Strava sports application users in the Helsinki region. The reference value for slower cycling has been 12km/, which has been the average travel speed of bike sharing system users in Helsinki. Additional 1 minute have been added to the travel time to consider the time for taking (30s) and returning (30s) bike on the origin/destination.

More information of the Strava dataset that was used can be found from the Cycling routes and fluency report, which was published by us and the city of Helsinki.

THE ROUTES BY WALKING were also calculated using the MetropAccess-Reititin by disabling all motorized transport modesin the calculation. Thus, all routes are based on the Open Street Map geometry.

The walking speed has been adjusted to 70 meters per minute, which is the default speed in the HSL Journey Planner (also in the calculations by public transportation).

All calculations were done using the computing resources of CSC-IT Center for Science (https://www.csc.fi/home).

Accident statistics on urban roads in Spain, municipal data for 2019 and 2022 Sheet 1. Raw Data. In order to calculate before-and-after effect exclude the 9 cities not impacted by the speed limit reduction. Sheet 2. Data of 50 cities for propensity score matching. Summary of differences in rows 53 and 54. Sheet 3. Data prepared for the Zero-inflated negative binomial and Poisson regressions with the appropiate format.

This interactive web application features both the on-road Maryland Level of Bicycle Stress (LTS) feature layer for all road centerlines in Maryland as well the Road-Separated feature layer of all road-separated bike routes throughout Maryland. An overview of the methodology and attribute data for the Maryland Level of Bicycle Stress (LTS) is provided below. For a detailed full report of the methodology, please view the PDF published by the Maryland Department of Transportation here. The Maryland Department of Transportation is transitioning from using the Bicycle Level of Comfort (BLOC) to using the Level of Traffic Stress (LTS) for measuring the “bikeability” of the roadway network. This transition is in coordination with the implementation of MDOT SHA’s Context Driven Design Guidelines and other national and departmental initiatives. LTS is preferred over BLOC as LTS requires fewer variables to calculate including: Average Annual Daily Traffic, Speed Limits, Presence of Bicycle Facilities, Shoulder, etc. Data LimitationsA principle of data governance MDOT strives to provide the best possible data products. While the initial LTS analysis of Maryland’s bicycle network has many uses, it should be used with a clear understanding of the current limitations the data presents.Assumptions - As noted earlier in this document, some of the metrics used to determine LTS score were estimated. Speed limits for many local roadways were not included in the original data and were assigned based on the functional classification of the roadway. Speed limits are also based on the posted speed limit, not the prevailing operating vehicle speeds which can vary greatly. Such discrepancies between actual and assumed conditions could introduce margins of error in some cases. As data quality improves with future iterations, the LTS scoring accuracy will also improve.Generalizations - MDOT’s LTS methodology follows industry standards but needs to account for varying roadway conditions and data reliability from various sources. The LTS methodology aims to accurately capture Maryland’s bicycle conditions and infrastructure but must consider data maintenance requirements. To limit data maintenance generalizations were made in the methodology so that a score could be assigned. Specifically, factors such as intersections, intersection approaches and bike lane blockages are not included in this initial analysis. LTS scores may be adjusted in the future based on MDOT review, updated industry standards, and additional LTS metrics being included in OMOC such as parking and buffer widths.Timestamped - As the LTS score is derived from a dynamic linear referencing system (LRS), any LTS analysis performed reflects the data available in OMOC. Each analysis must be considered ‘timestamped’ and becoming less reliable with age. As variables within OMOC change, whether through documented roadway construction, bikeway improvements or a speed limit reduction, LTS scores will also change. Fortunately, as this data is updated in the linear referencing system, the data becomes more reliable and LTS scores become more accurate.Presence and type of bicycle facilitySpeed limitNumber of Through Lanes/Traffic VolumeTraditionally, the Level of Traffic Stress (LTS) (scale “1” to “4”) is a measure for assessing the quality of the roadway network for its comfort with various bicycle users. The lower the LTS score, the more inviting the bicycle facility is for more audiences.LTS Methodology (Overview)MDOT’s LTS methodology is based on the metrics established by the Mineta Transportation Institute (MTI) Report 11-19 “Low-Stress Bicycling and Network Connectivity (May 2012) - additional criteria refined by Dr. Peter G. Furth (June 2017) below and Montgomery County's Revised Level of Traffic Stress.Shared-use Path Data Development and Complimentary Road Separated Bike Routes DatasetA complimentary dataset – Road Separated Bike Routes, was completed prior to the roadway dataset and is included in this application. It is also provided to the public via (https://maryland.maps.arcgis.com/home/item.html?id=1e12f2996e76447aba89099f41b14359). This first dataset is an inventory of all shared-use paths open to public, two-way bicycle access which contribute to the bicycle transportation network. Shared-use paths and sidepaths were assigned an LTS score of “0” to indicate minimal interaction with motor vehicle traffic. Many paved loop trails entirely within parks, which had no connection to the adjacent roadway network, were not included but may be included in future iterations. Sidepaths, where a shared-use path runs parallel to an adjacent roadway, are included in this complimentary Road Separated Bike Routes Dataset. Sidepaths do not have as an inviting biking environment as shared-use paths with an independent alignment due to the proximity of motor vehicle traffic in addition to greater likelihood of intersections with more roadways and driveways. Future iterations of the LTS will assign an LTS score of “1” to sidepaths. On-street Bicycle Facility Data DevelopmentThis second dataset includes all on-road bicycle facilities which have a designated roadway space for bicycle travel including bike lanes and protected bike lanes. Marked shared lanes in which bicycle and motor vehicle traffic share travel lanes were not included. Shared lanes, whether sharrows, bike boulevards or signed routes were inventoried but treated as mixed traffic for LTS analysis. The bicycle facilities included in the analysis include:Standard Bike Lanes – A roadway lane designated for bicycle travel at least 5-feet-wide. Bike lanes may be located against the curb or between a parking lane and a motor vehicle travel lane. Buffered bike lanes without vertical separation from motor vehicle traffic are included in this category. Following AASHTO and MDOT SHA design standards, bike lanes are assumed to be at least 5-feet-wide even through some existing bike lanes are less than 5-feet-wide.Protected Bike Lanes – lanes located within the street but are separated from motor vehicle travel lanes by a vertical buffer, whether by a row of parked cars, flex posts or concrete planters.Shoulders – Roadway shoulders are commonly used by bicycle traffic. As such, roadways with shoulders open to bicycle traffic were identified and rated for LTS in relation to adjacent traffic speeds and volumes as well as the shoulder width. Shoulders less than 5-feet-wide, the standard bike lane width, were excluded from analysis and these roadway segments were treated as mixed traffic.The Office of Highway Development at MDOT SHA provided the on-street bicycle facility inventory data for state roadways. The shared-use path inventory and on-street bicycle facility inventory was compiled from local jurisdiction’s open-source download or shared form the GIS/IT departments. Before integrating into OMOC, these datasets were verified by conducting desktop surveys and site visits, and by consulting with local officials and residents.-----------------------------------------------------------------------------------------------------------Inquiries? Contact Us!For Methodology: Contact Nate Evans (nevans1@mdot.maryland.gov)For GIS \ Data: Contact Andrew Bernish (abernish@mdot.maryland.gov)

Statewide Road Network including sealed and unsealed roads. The dataset represents navigable roads, including public and private access roads and tracks. A separate data layer stores 'unformed' DCDB centrelines which do not represent navigable roads. A limited number of associated features are stored separately as point features. Automatically updated when changes occur.

VITAL SIGNS INDICATOR Time Spent in Congestion (T7)

FULL MEASURE NAME Time Spent in Congestion

LAST UPDATED October 2018

DATA SOURCE MTC/Iteris Congestion Analysis No link available

CA Department of Finance Forms E-8 and E-5 http://www.dof.ca.gov/Forecasting/Demographics/Estimates/E-8/ http://www.dof.ca.gov/Forecasting/Demographics/Estimates/E-5/

CA Employment Division Department: Labor Market Information http://www.labormarketinfo.edd.ca.gov/

CONTACT INFORMATION vitalsigns.info@bayareametro.gov

METHODOLOGY NOTES (across all datasets for this indicator) Time spent in congestion measures the hours drivers are in congestion on freeway facilities based on traffic data. In recent years, data for the Bay Area comes from INRIX, a company that collects real-time traffic information from a variety of sources including mobile phone data and other GPS locator devices. The data provides traffic speed on the region’s highways. Using historical INRIX data (and similar internal datasets for some of the earlier years), MTC calculates an annual time series for vehicle hours spent in congestion in the Bay Area. Time spent in congestion is defined as the average daily hours spent in congestion on Tuesdays, Wednesdays and Thursdays during peak traffic months on freeway facilities. This indicator focuses on weekdays given that traffic congestion is generally greater on these days; this indicator does not capture traffic congestion on local streets due to data unavailability.

This congestion indicator emphasizes recurring delay (as opposed to also including non-recurring delay), capturing the extent of delay caused by routine traffic volumes (rather than congestion caused by unusual circumstances). Recurring delay is identified by setting a threshold of consistent delay greater than 15 minutes on a specific freeway segment from vehicle speeds less than 35 mph. This definition is consistent with longstanding practices by MTC, Caltrans and the U.S. Department of Transportation as speeds less than 35 mph result in significantly less efficient traffic operations. 35 mph is the threshold at which vehicle throughput is greatest; speeds that are either greater than or less than 35 mph result in reduced vehicle throughput. This methodology focuses on the extra travel time experienced based on a differential between the congested speed and 35 mph, rather than the posted speed limit.

To provide a mathematical example of how the indicator is calculated on a segment basis, when it comes to time spent in congestion, 1,000 vehicles traveling on a congested segment for a 1/4 hour (15 minutes) each, [1,000 vehicles x ¼ hour congestion per vehicle= 250 hours congestion], is equivalent to 100 vehicles traveling on a congested segment for 2.5 hours each, [100 vehicles x 2.5 hour congestion per vehicle = 250 hours congestion]. In this way, the measure captures the impacts of both slow speeds and heavy traffic volumes.

MTC calculates two measures of delay – congested delay, or delay that occurs when speeds are below 35 miles per hour, and total delay, or delay that occurs when speeds are below the posted speed limit. To illustrate, if 1,000 vehicles are traveling at 30 miles per hour on a one mile long segment, this would represent 4.76 vehicle hours of congested delay [(1,000 vehicles x 1 mile / 30 miles per hour) - (1,000 vehicles x 1 mile / 35 miles per hour) = 33.33 vehicle hours – 28.57 vehicle hours = 4.76 vehicle hours]. Considering that the posted speed limit on the segment is 60 miles per hour, total delay would be calculated as 16.67 vehicle hours [(1,000 vehicles x 1 mile / 30 miles per hour) - (1,000 vehicles x 1 mile / 60 miles per hour) = 33.33 vehicle hours – 16.67 vehicle hours = 16.67 vehicle hours].

Data sources listed above were used to calculate per-capita and per-worker statistics. Top congested corridors are ranked by total vehicle hours of delay, meaning that the highlighted corridors reflect a combination of slow speeds and heavy traffic volumes (consistent with longstanding regional methodologies used to generate the “top 10” list of congested segments). Historical Bay Area data was estimated by MTC Operations staff using a combination of internal datasets to develop an approximate trend back to 1998.

To explore how 2017 congestion trends compare to real-time congestion on the region’s freeways, visit 511.org.

This dataset includes a multimodal assessment of the Cleveland Transportation Network, conducted as part of the Cleveland Moves initiative. It assesses need and comfort levels as we work to improve safety and mobility on Cleveland streets.The Pedestrian Crossing Level of Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, and the presence of a pedestrian island to calculate how stressful a crossing is for someone crossing. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The Bicycle Level of Traffic Stress layer was created by our Cleveland Moves consultant, Toole Design. It uses information about the number of lanes, the speed limit, the type of bikeway, and more to calculate the level of stress for someone riding a bicycle on a given street. These attributes are provided by Ohio and City of Cleveland data about streets and intersections. This data was generated in 2024. The ODOT Active Transportation Need layer was created by the Ohio Department of transportation, and uses several factors to determine need including access to a vehicle, poverty rates, and more.Update FrequencyThis dataset will be updated with additional analysis from the Cleveland Moves planning process by early 2025. After that point, it will be updated annually to reflect changes to Cleveland streets geared towards improving safety and mobility. Related ApplicationsA summary of this dataset can be found in the Cleveland Moves Network Assessment Dashboard.Data GlossaryThe ODOT Active Transportation Need dataset was developed by the Ohio Department of Transportation. More information about this dataset is available on their website: https://gis.dot.state.oh.us/tims_classic/Glossary ContactSarah Davis, Active Transportation Senior Plannersdavis2@clevelandohio.gov

This data was prepared as input for the Selkie GIS-TE tool. This GIS tool aids site selection, logistics optimization and financial analysis of wave or tidal farms in the Irish and Welsh maritime areas. Read more here: https://www.selkie-project.eu/selkie-tools-gis-technoeconomic-model/

This research was funded by the Science Foundation Ireland (SFI) through MaREI, the SFI Research Centre for Energy, Climate and the Marine and by the Sustainable Energy Authority of Ireland (SEAI). Support was also received from the European Union's European Regional Development Fund through the Ireland Wales Cooperation Programme as part of the Selkie project.

File Formats

Results are presented in three file formats:

tif Can be imported into a GIS software (such as ARC GIS) csv Human-readable text format, which can also be opened in Excel png Image files that can be viewed in standard desktop software and give a spatial view of results

Input Data

All calculations use open-source data from the Copernicus store and the open-source software Python. The Python xarray library is used to read the data.

Hourly Data from 2000 to 2019

• Wind - Copernicus ERA5 dataset 17 by 27.5 km grid
  10m wind speed

• Wave - Copernicus Atlantic -Iberian Biscay Irish - Ocean Wave Reanalysis dataset 3 by 5 km grid

Accessibility

The maximum limits for Hs and wind speed are applied when mapping the accessibility of a site.
The Accessibility layer shows the percentage of time the Hs (Atlantic -Iberian Biscay Irish - Ocean Wave Reanalysis) and wind speed (ERA5) are below these limits for the month.

Input data is 20 years of hourly wave and wind data from 2000 to 2019, partitioned by month. At each timestep, the accessibility of the site was determined by checking if
the Hs and wind speed were below their respective limits. The percentage accessibility is the number of hours within limits divided by the total number of hours for the month.

Environmental data is from the Copernicus data store (https://cds.climate.copernicus.eu/). Wave hourly data is from the 'Atlantic -Iberian Biscay Irish - Ocean Wave Reanalysis' dataset.
Wind hourly data is from the ERA 5 dataset.

Availability

A device's availability to produce electricity depends on the device's reliability and the time to repair any failures. The repair time depends on weather
windows and other logistical factors (for example, the availability of repair vessels and personnel.). A 2013 study by O'Connor et al. determined the
relationship between the accessibility and availability of a wave energy device. The resulting graph (see Fig. 1 of their paper) shows the correlation between accessibility at Hs of 2m and wind speed of 15.0m/s and availability. This graph is used to calculate the availability layer from the accessibility layer.

The input value, accessibility, measures how accessible a site is for installation or operation and maintenance activities. It is the percentage time the
environmental conditions, i.e. the Hs (Atlantic -Iberian Biscay Irish - Ocean Wave Reanalysis) and wind speed (ERA5), are below operational limits.
Input data is 20 years of hourly wave and wind data from 2000 to 2019, partitioned by month. At each timestep, the accessibility of the site was determined
by checking if the Hs and wind speed were below their respective limits. The percentage accessibility is the number of hours within limits divided by the total
number of hours for the month. Once the accessibility was known, the percentage availability was calculated using the O'Connor et al. graph of the relationship between the two. A mature technology reliability was assumed.

Weather Window

The weather window availability is the percentage of possible x-duration windows where weather conditions (Hs, wind speed) are below maximum limits for the
given duration for the month.

The resolution of the wave dataset (0.05° × 0.05°) is higher than that of the wind dataset
(0.25° x 0.25°), so the nearest wind value is used for each wave data point. The weather window layer is at the resolution of the wave layer.

The first step in calculating the weather window for a particular set of inputs (Hs, wind speed and duration) is to calculate the accessibility at each timestep.
The accessibility is based on a simple boolean evaluation: are the wave and wind conditions within the required limits at the given timestep?

Once the time series of accessibility is calculated, the next step is to look for periods of sustained favourable environmental conditions, i.e. the weather
windows. Here all possible operating periods with a duration matching the required weather-window value are assessed to see if the weather conditions remain
suitable for the entire period. The percentage availability of the weather window is calculated based on the percentage of x-duration windows with suitable
weather conditions for their entire duration.The weather window availability can be considered as the probability of having the required weather window available
at any given point in the month.

Extreme Wind and Wave

The Extreme wave layers show the highest significant wave height expected to occur during the given return period. The Extreme wind layers show the highest wind speed expected to occur during the given return period.

To predict extreme values, we use Extreme Value Analysis (EVA). EVA focuses on the extreme part of the data and seeks to determine a model to fit this reduced
portion accurately. EVA consists of three main stages. The first stage is the selection of extreme values from a time series. The next step is to fit a model
that best approximates the selected extremes by determining the shape parameters for a suitable probability distribution. The model then predicts extreme values
for the selected return period. All calculations use the python pyextremes library. Two methods are used - Block Maxima and Peaks over threshold.

The Block Maxima methods selects the annual maxima and fits a GEVD probability distribution.

The peaks_over_threshold method has two variable calculation parameters. The first is the percentile above which values must be to be selected as extreme (0.9 or 0.998). The second input is the time difference between extreme values for them to be considered independent (3 days). A Generalised Pareto Distribution is fitted to the selected
extremes and used to calculate the extreme value for the selected return period.