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.

Summary: This dataset contains an inventory of City of Los Angeles Sidewalks and related features (Access Ramps, Curbs, Driveways, and Parkways).Background: This inventory was performed throughout 2017 using a combination of G.I.S software, aerial imagery (2014 LARIAC), and a geographic dataset of property/right-of way lines. The dataset has not been updated since its creation.Description: The following provides more detail about the feature classes in this dataset. All features were digitized (“traced”) as observed in the orthophotography (digital aerial photos) and assigned the Parcel Identification Number (PIN) of their corresponding property:Sidewalk (polygon) – represents paved pedestrian walkways. Typical widths are between 3‐6 feet in residential areas and larger and more variable in commercial and high‐density traffic areas.Alley-Sidewalk (polygon) – represents the prevailing walkway or path of travel at the entrance/exit of an alley. Digitized as Sidewalk features but categorized as Alley Sidewalk and assigned a generic PIN value, ALLEY SIDEWALK.Corner Polygon (polygon) - feature created where sidewalks from two streets meet but do not intersect (i.e. at corner lots). There’s no standard shape/type and configurations vary widely. These are part of the Sidewalk feature class.In commercial and high‐density residential areas where there is only continuous sidewalk (no parkway strip), the sidewalk also functions as a Driveway.Driveway (polygon) – represents area that provides vehicular access to a property. Features are not split by extended parcel lot lines except when two adjacent properties are served by the same driveway approach (e.g. a common driveway), in which case they are and assigned a corresponding PIN.Parkway (polygon) – represents the strip of land behind the curb and in front of the sidewalk. Generally, they are landscaped with ground cover but they may also be filled in with decorative stone, pavers, decomposed granite, or concrete. They are created by offsetting lines, the Back of Curb (BOC) line and the Face of Walk (FOW). The distance between the BOC and FOW is measured off the aerial image and rounded to the nearest 0.5 foot, typically 6 – 10 feet.Curb (polygon) – represents the concrete edging built along the street to form part of the gutter. Features are always 6” wide strips and are digitized using the front of curb and back of curb digitized lines. They are the leading improvement polygon and are created for all corner, parkway, driveway and, sidewalk (if no parkway strip is present) features.Curb Ramp, aka Access Ramp (point) – represents the geographic center (centroid) of Corner Polygon features in the Sidewalk feature class. They have either a “Yes” or “No” attribute that indicates the presence or absence of a wheelchair access ramp, respectively.Fields: All features include the following fields...FeatureID – a unique feature identifier that is populated using the feature class’ OBJECTID fieldAssetID – a unique feature identifier populated by Los Angeles City staff for internal usePIND – a unique Parcel Identification Number (PIN) for all parcels within the City of L.A. All Sidewalk related features will be split, non-overlapping, and have one associated Parcel Identification Number (PIN). CreateDate – indicates date feature was createdModifiedDate – indicates date feature was revised/editedCalc_Width (excluding Access Ramps) – a generalized width of the feature calculated using spatial and mathematical algorithms on the feature. In almost all cases where features have variable widths, the minimum width is used. Widths are rounded to the nearest whole number. In cases where there is no value for the width, the applied algorithms were unable to calculate a reliable value.Calc_Length (excluding Access Ramps) – a generalized length of the feature calculated using spatial and mathematical algorithms on the feature. Lengths are rounded to the nearest whole number. In cases where there is no value for the length, the applied algorithms were unable to calculate a reliable value.Methodology: This dataset was digitized using a combination of G.I.S software, aerial imagery (2014 LARIAC), and a geographic dataset of property/right-of way lines.The general work flow is as follows:Create line work based on digital orthophotography, working from the face‐of‐curb (FOC) inward to the property right-of-way (ROW)Build sidewalk, parkway, driveway, and curb polygons from the digitized line workPopulate all polygons with the adjacent property PIN and classify all featuresCreate Curb Ramp pointsWarnings: This dataset has been provided to allow easy access and a visual display of Sidewalk and related features (Parkways, Driveway, Curb Ramps and Curbs). Every reasonable effort has been made to assure the accuracy of the data provided; nevertheless, some information may not be accurate. The City of Los Angeles assumes no responsibility arising from use of this information. THE MAPS AND ASSOCIATED DATA ARE PROVIDED WITHOUT WARRANTY OF ANY KIND, either expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Other things to keep in mind about this dataset are listed below:Obscured Features – The existence of dense tree canopy or dark shadows in the aerial imagery tend to obscure or make it difficult to discern the extent of certain features, such as Driveways. In these cases, they may have been inferred from the path in the corresponding parcel. If a feature and approach was completely obscured, it was not digitized. In certain instances the coloring of the sidewalk and adjacent pavement rendered it impossible to identify the curb line or that a sidewalk existed. Therefore a sidewalk may or may not be shown where one actually may or may not exist.Context: The following links provide information on the policy context surrounding the creation of this dataset. It includes links to City of L.A. websites:Willits v. City of Los Angeles Class Action Lawsuit Settlementhttps://www.lamayor.org/willits-v-city-la-sidewalk-settlement-announcedSafe Sidewalks LA – program implemented to repair broken sidewalks in the City of L.A., partly in response to the above class action lawsuit settlementhttps://sidewalks.lacity.org/Data Source: Bureau of EngineeringNotes: Please be aware that this dataset is not actively being maintainedLast Updated: 5/20/20215/20/2021 - Added Calc_Width and Calc_Length fieldsRefresh Rate: One-time deliverable. Dataset not actively being maintained.

A project by NYC Planning Labs, NYC Street Map is an ongoing effort to digitize official street records, bring them together with other street information, and make them easily accessible to the public. With this app, you can find the official mapped width, name, and status of specific streets and how they may relate to specific properties. You can also see how the street grid has changed over time in your area.NYC Street Map combines 8000+ components of the official City Map with other street information into a seamless Citywide map. However, NYC Street Map does not contain all the information on the City Map and may have inaccuracies. The information shown on NYC Street Map must be confirmed based on the official City Map records.Learn more about the official City Map

Roadway Access Control data consists of linear geometric features which showcase the types of control over vehicle access to public roadways in the State of Maryland. Roadway Access Control data is commonly classified by three (3) control types, which are Full Access Control, Partial Access Control, and No Access Control. Roadway Access Control data is primarily used for general planning purposes, investment requirements modeling to calculate capacity and estimate type of design, in truck size and weight studies, and for Federal Highway Administration (FHWA) Highway Performance Monitoring System (HPMS) annual submission & coordination. The Maryland Department of Transportation State Highway Administration (MDOT SHA) currently reports this data only on the inventory direction (generally North or East) side of the roadway. Roadway Access Control data is not a complete representation of all roadway geometry.Roadway Access Control data is developed as part of the Highway Performance Monitoring System (HPMS) which maintains and reports transportation related information to the Federal Highway Administration (FHWA) on an annual basis. HPMS is maintained by the Maryland Department of Transportation State Highway Administration (MDOT SHA), under the Office of Planning and Preliminary Engineering (OPPE) Data Services Division (DSD). Roadway Access Control data is used by various business units throughout MDOT, as well as many other Federal, State and local government agencies. Roadway Access Control data is key to understanding the types of control over vehicle access to public roadways in the State of Maryland.Roadway Access Control data is updated and published on an annual basis for the prior year. This data is for the year 2017.For additional information, contact the MDOT SHA Geospatial TechnologiesEmail: GIS@mdot.state.md.usFor additional information related to the Maryland Department of Transportation (MDOT):https://www.mdot.maryland.gov/For additional information related to the Maryland Department of Transportation State Highway Administration (MDOT SHA):https://roads.maryland.gov/Home.aspxMDOT SHA Geospatial Data Legal Disclaimer:The Maryland Department of Transportation State Highway Administration (MDOT SHA) makes no warranty, expressed or implied, as to the use or appropriateness of geospatial data, and there are no warranties of merchantability or fitness for a particular purpose or use. The information contained in geospatial data is from publicly available sources, but no representation is made as to the accuracy or completeness of geospatial data. MDOT SHA shall not be subject to liability for human error, error due to software conversion, defect, or failure of machines, or any material used in the connection with the machines, including tapes, disks, CD-ROMs or DVD-ROMs and energy. MDOT SHA shall not be liable for any lost profits, consequential damages, or claims against MDOT SHA by third parties.This is a MD iMAP hosted service layer. Find more information at https://imap.maryland.gov.Map Service Link:https://geodata.md.gov/imap/rest/services/Transportation/MD_HighwayPerformanceMonitoringSystem/MapServer/0

Line Name: Name and/or basic description, if applicable.Trail System Name: Only applicable to trails. Some smaller trail segments within a particular park, may be a part of a larger trail system (ex. a trail in Barkley Meadows Park may be a part of the larger Gilleland Creek Greenway Trail System).Status: This field uses a domain in the database called, Status, which explains the current physical state of the trail. Although there are several domain values for this domain, for this particular feature class, only a few are likely to be used: Open, Closed, Planned & Proposed.Domain Values Value Definitions Open Trail is open to the public, free of charge Open_Fee Trail is open to the public, access fee is charged Open_Restricted Trail is open to the public, but access is restricted – ex by permit or reservation only Closed Trail exists but is not open to the public Decommissioned Trail has been removed from service or transferred to another jurisdiction Planned Trail planned for the future Proposed Trail ROW acquired or agreed to by all owning/managing partners Unknown Status of the trail unknown Difficulty Rating: This field uses a domain in the database called, Difficulty Rating, which defines the difficulty rating of the trail.Domain Values Value Definitions Easiest A trail requiring limited skill with little challenge to travel - mostly level; adequate width; minor crossings, well marked More Difficult A trail requiring some skill and challenge to travel. Minor ascent/descent; narrow passages; heights; natural crossings; length Most Difficult A trail requiring a high degree of skill and challenge to travel. Significant ascent/descents; scrambling crossings; some bouldering, extensive length from trail head to trail access Special/Technical Capability Rapids above level 2 for canoes or 3 for Kayaks, climbing gear, cold weather gear suggested Varies Difficulty depends on environmental conditions, floods, ice, snow etc. Accessibility Status:This field uses a domain in the database called, Accessibility Status. Accessibility guideline compliance status for trail or segment that is designed for pedestrian use.Domain Values Value Definitions Accessible Trail meets current accessibility guidelines (ADA and Access Board Interpretation/Guidelines) Not Accessible Trail does not meet accessibility guidelines Ineligible Trail determined ineligible to meet current trail accessibility guidelines Not Evaluated Trail not evaluated for accessibility GIS Length Ft: Geometry calculated with GIS. May need to be re-calculated to account for any changes in geometry.Width Ft: Manually input by user, since the linear feature contains no width to calculate with GIS.Park Name & Park ID: Identifies which park the feature falls within.

WSDOT evaluated and assigned a Level of Traffic Stress (LTS) ranking to WA state highway segments to aid in efforts to analyze high-level systemic safety and user acceptance of state highways for active transportation users. This data was also intended to inform high-level prioritization of active transportation improvements. LTS data rank highway segments from 1 to 4 based on roadway characteristics like posted speed, vehicle volume, number of travel lanes, and presence of active transportation infrastructure like sidewalks and bike lanes. WSDOT deemed LTS 1 suitable for all ages and abilities. LTS 2 is considered suitable for most active travelers. LTS 3 and 4 represent functional gaps in active transportation networks that present systemic safety issues and likely deter use of active modes.The data reports a Pedestrian Level of Traffic Stress (PLTS) and Bicycle Level of Traffic Stress (BLTS) based on the presence of mode-specific infrastructure and calculated using guidance from the WSDOT Design Manual, updated September 2024. PLTS is calculated using Exhibits 1520-1 and 1520-2 based on the presence of sidewalks recorded in WSDOT enterprise sidewalk data and presence and width of a paved shoulder recorded in the State Highway Log Roadway Data Shoulders dataset. BLTS is calculated using Exhibits 1520-5, 1520-6, and 1520-7 based on the presence and width of bike lanes recorded in the State Highway Log Special Use Lanes dataset. Data is not currently available on presence of separation materials, so bike lanes were only considered based on their width. The General LTS measure is based on Exhibit 1520-5. Ramp segments are included in the dataset with a default LTS ranking of 999. This ranking indicates that all ramps are to be considered high LTS (3 or 4) unless a manual evaluation of the roadway characteristics indicates otherwise. Datasets were not available that would enable ramp rankings to be determined systematically based on posted speed, traffic volume, and number of travel lanes, however a manual review of many ramp configurations across the state indicated that most ramps present LTS concerns.The data provided is not a substitute for detailed investigation of a location when specific investment decisions are being considered. The specific characteristics of locations with the same LTS rankings could vary considerably. It is important to note that an LTS 1 or 2 location might have additional, unmeasured characteristics that reduce its presumed suitability for active travel.For additional information regarding ranking methodology or other questions about WSDOT’s Level of Traffic Stress dataset, contact Grace Young (grace.young@wsdot.wa.gov).

The Road Segment table describes the administration and ownership of the segment of road. It contains tabular polyline data showing the log miles/measures, road name, functional class, government control, and U.S. Routes. Road names are derived from visual surveys by field crew or official GIS maps. Functional class is set by the Federal Highway Administration (FHWA). All other categories are determined by state and local agencies. This dataset is updated weekly. County – County in Tennessee where associated features and attributes are located.Route Number – Route in Tennessee with corresponding attributes.Special Case – Route designator for non-standard routes such as By-Pass.00 None01 Spur - S02 Alternate - A03 State Connector - C04 Bypass - BP05 Business Route - BR06 Northbound - N07 Southbound - S08 Eastbound - E09 Westbound - WCounty Sequence – This number indicates the sequential number of times a route enters and leaves the county, begins with zero (0).Beginning Log Mile (BLM) – The beginning log mile (measure) for the route segment.Ending Log Mile (ELM) - The ending log mile (measure) for the route segment.Functional Classification – These codes, set by the FHWA, provide a statewide highway functional classification in rural and urban areas to determine functional usage of the existing roads and streets.01 Rural Interstate02 Rural Other Principal Arterial03 Rural Freeway or Expressway06 Rural Minor Arterial07 Rural Major Collector08 Rural Minor Collector09 Rural Local11 Urban Interstate12 Urban Freeway or Expressway14 Urban Other Principal Arterial16 Urban Minor Arterial17 Urban Collector19 Urban LocalGovernment Control – These codes determine ownership and maintenance responsibility.01 State Highway Agency02 County04 Municipal11 State Park12 Local Park21 Other State Agency25 Other Local Agency26 Private27 Railroad40 Other Public60 Other Federal Agency63 US Fish and Wildlife64 US Forest Service66 National Park Service67 TVA68 Bureau of Land Management70 Corps of Engineers (Civil)72 Air Force73 Navy or Marines74 Army80 OtherUS Route Number – US Route Number assigned to roadway segment.

This is a collection of maps, layers, apps and dashboards that show population access to essential retail locations, such as grocery stores. Data sourcesPopulation data is from the 2010 U.S. Census blocks. Each census block has a count of stores within a 10 minute walk, and a count of stores within a ten minute drive. Census blocks known to be unpopulated are given a score of 0. The layer is available as a hosted feature layer.Grocery store locations are from SafeGraph, reflecting what was in the data as of October 2020. Access to the layer was obtained from the SafeGraph offering in ArcGIS Marketplace. For this project, ArcGIS StreetMap Premium was used for the street network in the origin-destination analysis work, because it already has the necessary attributes on each street segment to identify which streets are considered walkable, and supports a wide variety of driving parameters.The walkable access layer and drivable access layers are rasters, whose colors were chosen to allow the drivable access layer to serve as backdrop to the walkable access layer. Alternative versions of these layers are available. These pairs use different colors but are otherwise identical in content.Data PreparationArcGIS Network Analyst was used to set up a network street layer for analysis. ArcGIS StreetMap Premium was installed to a local hard drive and selected in the Origin-Destination workflow as the network data source. This allows the origins (Census block centroids) and destinations (SafeGraph grocery stores) to be connected to that network, to allow origin-destination analysis.The Census blocks layer contains the centroid of each Census block. The data allows a simple popup to be created. This layer's block figures can be summarized further, to tract, county and state levels.The SafeGraph grocery store locations were created by querying the SafeGraph source layer based on primary NAICS code. After connecting to the layer in ArcGIS Pro, a definition query was set to only show records with NAICS code 445110 as an initial screening. The layer was exported to a local disk drive for further definition query refinement, to eliminate any records that were obviously not grocery stores. The final layer used in the analysis had approximately 53,600 records. In this map, this layer is included as a vector tile layer.MethodologyEvery census block in the U.S. was assigned two access scores, whose numbers are simply how many grocery stores are within a 10 minute walk and a 10 minute drive of that census block. Every census block has a score of 0 (no stores), 1, 2 or more stores. The count of accessible stores was determined using Origin-Destination Analysis in ArcGIS Network Analyst, in ArcGIS Pro. A set of Tools in this ArcGIS Pro package allow a similar analysis to be conducted for any city or other area. The Tools step through the data prep and analysis steps. Download the Pro package, open it and substitute your own layers for Origins and Destinations. Parcel centroids are a suggested option for Origins, for example. Origin-Destination analysis was configured, using ArcGIS StreetMap Premium as the network data source. Census block centroids with population greater than zero were used as the Origins, and grocery store locations were used as the Destinations. A cutoff of 10 minutes was used with the Walk Time option. Only one restriction was applied to the street network: Walkable, which means Interstates and other non-walkable street segments were treated appropriately. You see the results in the map: wherever freeway overpasses and underpasses are present near a grocery store, the walkable area extends across/through that pass, but not along the freeway.A cutoff of 10 minutes was used with the Drive Time option. The default restrictions were applied to the street network, which means a typical vehicle's access to all types of roads was factored in.The results for each analysis were captured in the Lines layer, which shows which origins are within the cutoff of each destination over the street network, given the assumptions about that network (walking, or driving a vehicle).The Lines layer was then summarized by census block ID to capture the Maximum value of the Destination_Rank field. A census block within 10 minutes of 3 stores would have 3 records in the Lines layer, but only one value in the summarized table, with a MAX_Destination_Rank field value of 3. This is the number of stores accessible to that census block in the 10 minutes measured, for walking and driving. These data were joined to the block centroids layer and given unique names. At this point, all blocks with zero population or null values in the MAX_Destination_Rank fields were given a store count of 0, to help the next step.Walkable and Drivable areas are calculated into a raster layer, using Nearest Neighbor geoprocessing tool on the count of stores within a 10 minute walk, and a count of stores within a ten minute drive, respectively. This tool uses a 200 meter grid and interpolates the values between each census block. A census tracts layer containing all water polygons "erased" from the census tract boundaries was used as an environment setting, to help constrain interpolation into/across bodies of water. The same layer use used to "shoreline" the Nearest Neighbor results, to eliminate any interpolation into the ocean or Great Lakes. This helped but was not perfect.Notes and LimitationsThe map provides a baseline for discussing access to grocery stores in a city. It does not presume local population has the desire or means to walk or drive to obtain groceries. It does not take elevation gain or loss into account. It does not factor time of day nor weather, seasons, or other variables that affect a person's commute choices. Walking and driving are just two ways people get to a grocery store. Some people ride a bike, others take public transit, have groceries delivered, or rely on a friend with a vehicle. Thank you to Melinda Morang on the Network Analyst team for guidance and suggestions at key moments along the way; to Emily Meriam for reviewing the previous version of this map and creating new color palettes and marker symbols specific to this project. Additional ReadingThe methods by which access to food is measured and reported have improved in the past decade or so, as has the uses of such measurements. Some relevant papers and articles are provided below as a starting point.Measuring Food Insecurity Using the Food Abundance Index: Implications for Economic, Health and Social Well-BeingHow to Identify Food Deserts: Measuring Physical and Economic Access to Supermarkets in King County, WashingtonAccess to Affordable and Nutritious Food: Measuring and Understanding Food Deserts and Their ConsequencesDifferent Measures of Food Access Inform Different SolutionsThe time cost of access to food – Distance to the grocery store as measured in minutes

Human disturbance effects can be considered as either direct or indirect. Land use features, such as roads, settlements or mine sites, have a directphysical footprint that results in habitat loss or alteration. An area of indirectdisturbance may exist around these physical footprints, where noise, dust, smells or other factors influence caribou’s use of habitat. This area of indirect disturbance around a human development feature is known as the zone of influence (ZOI). Caribou may avoid these zones of influence, use them less frequently, exhibit altered behavior,or have a higher mortality risk from harvest or predation within them. In GIS mapping, ZOI is estimated as a spatial buffer of a defined distance around a human development feature.The amount of direct and indirect human-caused disturbance in the Bathurst range planning area was calculated from an integrated GIS data set of human land use features/surface disturbances developed as part of the range planning exercise. The human land use feature mapping was created by compiling and merging available GIS information, with the Government of NWT Cumulative Impact Monitoring Program (CIMP) database (CIMP 2015) being the main input, supplemented and modified where necessary by the National Road Network and mineral industry-provided information used to support project assessment and permitting activities. Detailed mapping methods are described in Appendix A of the Caribou Range Assessment and Technical Information report developed in support of the Bathurst Caribou Range Planning process. Please contact Karin Clark, Cumulative Effects Biologist, GNWT to obtain a copy of this report.The ZOI extent around each human development feature was estimated based on literature reviews and values used in recent environmental assessments. Average ZOI extents for different feature types were used based on reported values and supportable rationale. The rationale and literature sources used to estimate ZOI extents are listed in Appendix B of the same aforementioned report.Human land use feature types represented in the Bathurst range planning area human development database, and their estimated zones of influence (ZOI) on barren-ground caribou.Feature TypeFeature ClassDescriptionEstimated ZOI (km)LinearAll-season Access RoadAny all-season road, including roads in Settlements (average 10m width)5Major Electrical Transmission CorridorAny major electrical utility corridor (e.g., Snare River) (average 30m clearing width)4Public All-season Paved HighwayAny all-season paved highway (e.g., NWT Highway #3 and #4) (average 60m clearing width)5Mainline All-season Access (Haul) RoadAny major all-season access or haul road (e.g., current Ekati Misery Road or potential future Izok Corridor road) (average 20m width)5Winter RoadAll winter roads (except main Tibbit to Contwoyto Winter Road) (average 12m width)1Tibbit to Contwoyto Winter RoadMainline Tibbit to Contwoyto Winter Road (average 40m width)4PolygonalAirstripActive airstrip with paved or unpaved surface5CampMineral exploration camp, lodges or similar5Communication TowerCommunication tower1General IndustrialVariety of general industrial features1Mineral ExplorationMineral exploration-related infrastructure and disturbances5Minesite (Active)Minesites under construction or in production14Minesite (Past or Closed)Past or closed minesites, either abandoned or under active reclamation5MiscellaneousVariety of uncertain industrial or non-industrial surface disturbances or infrastructure.1Marine PortFuture proposed or conceptual marine port/laydown facilities in Nunavut on the Arctic coast (e.g., Grays Bay or Bathurst Inlet)5Power Generation FacilityHydro power generation facilities (dams, spillways, powerhouses, and associated)5QuarryAny excavation site used for the purpose of developing aggregate, sand, crushed rock, etc.5SettlementAny permanent settlement with a recognized municipal boundary (e.g., City of Yellowknife, Whatì, etc.)15ZOI buffers from adjacent human land use features may overlap. To avoid double-counting ZOI buffers when calculating total human disturbance, ZOI buffers were applied to footprints in a hierarchy (Table 3), based on the following considerations:features with the largest ZOI assumptions occurred at the top of the hierarchy to reflect the relative magnitude of influence on caribou; polygonal features were ranked higher than linear features (with the same ZOI assumption), because the ZOIs assumptions reflect disturbance activities, which would likely be more consistent over time at a small polygonal feature compared to activity along a road. Also, from a practical perspective, the dissolve function in the GIS is simpler when a polygonal feature is ranked higher, because it eliminates the situation where a road (and associated ZOI) would bisect a polygonal feature if it happened to run through it. There would be many exceptions to these base assumptions, especially if one were to incorporate a feature-specific description of the intensity of activity associated with a polygonal or linear feature. However, for this landscape-level tracking exercise, in the absence of site-specific data and associated caribou responses, it was more appropriate to consider the hierarchy of feature-types at a strategic level, and not attempt to generate specific assumptions for each feature on the landscape.

You can also access an API version of this dataset.

TMS

(traffic monitoring system) daily-updated traffic counts API

Important note: due to the size of this dataset, you won't be able to open it fully in Excel. Use notepad / R / any software package which can open more than a million rows.

Data reuse caveats: as per license.

Data quality

statement: please read the accompanying user manual, explaining:

how

 this data is collected identification 

 of count stations traffic 

 monitoring technology monitoring 

 hierarchy and conventions typical 

 survey specification data 

 calculation TMS 

 operation. 

Traffic

monitoring for state highways: user manual

[PDF 465 KB]

The data is at daily granularity. However, the actual update

frequency of the data depends on the contract the site falls within. For telemetry

sites it's once a week on a Wednesday. Some regional sites are fortnightly, and

some monthly or quarterly. Some are only 4 weeks a year, with timing depending

on contractors’ programme of work.

Data quality caveats: you must use this data in

conjunction with the user manual and the following caveats.

The

 road sensors used in data collection are subject to both technical errors and 

 environmental interference.Data 

 is compiled from a variety of sources. Accuracy may vary and the data 

 should only be used as a guide.As 

 not all road sections are monitored, a direct calculation of Vehicle 

 Kilometres Travelled (VKT) for a region is not possible.Data 

 is sourced from Waka Kotahi New Zealand Transport Agency TMS data.For 

 sites that use dual loops classification is by length. Vehicles with a length of less than 5.5m are 

 classed as light vehicles. Vehicles over 11m long are classed as heavy 

 vehicles. Vehicles between 5.5 and 11m are split 50:50 into light and 

 heavy.In September 2022, the National Telemetry contract was handed to a new contractor. During the handover process, due to some missing documents and aged technology, 40 of the 96 national telemetry traffic count sites went offline. Current contractor has continued to upload data from all active sites and have gradually worked to bring most offline sites back online. Please note and account for possible gaps in data from National Telemetry Sites. 

The NZTA Vehicle

Classification Relationships diagram below shows the length classification (typically dual loops) and axle classification (typically pneumatic tube counts),

and how these map to the Monetised benefits and costs manual, table A37,

page 254.

Monetised benefits and costs manual [PDF 9 MB]

For the full TMS

classification schema see Appendix A of the traffic counting manual vehicle

classification scheme (NZTA 2011), below.

Traffic monitoring for state highways: user manual [PDF 465 KB]

State highway traffic monitoring (map)

State highway traffic monitoring sites

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)

Esri ArcGIS Online Hosted Feature Layer which provides access to the MDOT SHA Roadway Access Control data product.MDOT SHA Roadway Access Control data consists of linear geometric features which showcase the types of control over vehicle access to roadways throughout the State of Maryland. Roadway Access Control data is commonly classified by three (3) control types, which are Full Access Control, Partial Access Control, and No Access Control. Roadway Access Control data is primarily used for general planning purposes, investment requirements modeling to calculate capacity and estimate type of design, in truck size and weight studies, and for Federal Highway Administration (FHWA) Highway Performance Monitoring System (HPMS) annual submission & coordination. The Maryland Department of Transportation State Highway Administration (MDOT SHA) currently reports this data only on the inventory direction (generally North or East) side of the roadway. Roadway Access Control data is not a complete representation of all roadway geometry.MDOT SHA Roadway Access Control data is developed as part of the Highway Performance Monitoring System (HPMS) which maintains and reports transportation related information to the Federal Highway Administration (FHWA) on an annual basis. HPMS is maintained by the Maryland Department of Transportation State Highway Administration (MDOT SHA), under the Office of Planning & Preliminary Engineering (OPPE) Data Services Division (DSD). Roadway Access Control data is used by various business units throughout MDOT, as well as many other Federal, State and local government agencies. Roadway Access Control data is key to understanding the types of control over vehicle access to roadways throughout the State of Maryland.MDOT SHA Roadway Access Control data is owned & maintained by the MDOT SHA Office of Planning & Preliminary Engineering (OPPE). This data product is updated & published on an annual basis for the prior year. This data is for the year 2020. This data product was last updated in November 2022.For more information related to the data, contact MDOT SHA OPPE Data Services Division (DSD):Email: DSD@mdot.maryland.govFor more information, contact MDOT SHA OIT Enterprise Information Services:Email: GIS@mdot.maryland.gov

Urban Habitat Connectivity Project (UHCP)Short description: A package of data containing potential habitat and fragmentation for seven species groups in the urban ACT. Each species group has two layer files. Connected habitat layers show potential core and corridor habitat for the species group, and connectivity/fragmentation between these habitat patches. Remnant patches layers contain areas which are predicted to be fragmented and inaccessible for the species group, but may be important for restoration activities. These layers are outputs of ecological connectivity modelling and have been developed using spatial data representing habitat and connectivity requirements specific to the species group.The following attributes are available in the data table for Connected Habitat layers:Species Group* - indicates the species group of interestPatch ID – a unique identifier for each ‘patch’ of connected habitat, an ID that is given to group all habitat areas which are predicted to be connected to each other.Habitat Type* – identifies if the polygon meets core or corridor habitat requirements, or if it is a remnant patch.Habitat Number – a numeric value linked to Habitat Type to support statistics and symbology. Core habitat has a value of 0 and corridor habitat has a value of 1.Patch Area (Ha)* – the area of the individual polygon in hectares.Connected Habitat Area (Ha) – the total area of potential habitat in the connected patch, determined by summing the Patch Area for all polygons with the same Patch ID.Shape area – the polygon’s area, calculated by default in meters squared.Shape length – the length of the line enclosing the polygon, calculated by default in meters squared.* Is also available in the data table for Remnant Patches layers.Spatial resolution: 1:10,000Coordinate system: GDA2020 MGA zone 55METHODSData collection / creation: Spatial layers for habitat and barriers were created and input into a habitat connectivity/fragmentation model specifically designed for the species group. The model was developed using metrics derived from expert elicitation. These metrics quantified essential habitat and connectivity requirements for the species group, for example the preferred spacing of trees, the maximum crossable width of a road, the typical dispersal distance, etc. The model identified habitat and barriers to connectivity, based on the metrics which could be mapped. Habitat was delineated by patch size to determine core and corridor habitat, and to remove areas which are too small to be functional. The habitat type is visible in the attribute table of the data.Connectivity between habitat patches is dependent on the species group’s dispersal capacity and the availability of core habitat, suitable corridors and a path without barriers. To assess this core habitat areas were buffered by the species group’s dispersal distance. This identified how far an individual will move to find a new core habitat patch. Movement to this distance is dependent on a suitable path. All habitat was buffered by the distance the species can move outside habitat (through non-habitat areas). This identified how far an individual will move outside any habitat (core or corridor) before they require another habitat patch (i.e. how far they can travel between stepping stones).Connectivity is further complicated by impassable barriers. Barriers were used to slice up the dispersal buffers and identify ‘dispersal patches’, areas which an individual can move within. Fragmentation is seen when a barrier is present, patches are too far from core habitat, or corridor habitat is too far apart.A unique ID was applied to each patch and represents connectivity/fragmentation. The patches were intersected with habitat to apply the new ID to the habitat areas. The final model outputs identify areas of potential core, corridor or remnant (inaccessible) habitat. Core and corridor habitat are viewable in the connected habitat dataset, whilst remnant patches are available separately. The data was simplified using the Douglas-Peuker algorithm, a tolerance of 0.5-2m, minimum size of 2-5m2 for retention, and holes filled in if less than 20m2. Small adjoining slithers <20m2 were dissolved into neighbouring polygons to optimise drawing speeds. Please contact the project team for the model script or further details on the methodology.NOTES ON USEQuality: The habitat connectivity modelling used to produce the data was informed by work by the City of Melbourne (Kirk et al., 2018). The original methods were expanded on, with habitat and connectivity requirements (metrics) specific to the species group determined from expert elicitation and further analysis to consider patch size for core or corridor patches. The expert elicitation process provided the best and most relevant quantitative description of habitat and barriers available (for a species group rather than a specific species). The input datasets were then tailored to the metrics for this project. Existing datasets were refined to be relevant and reflect the metrics identified through expert elicitation. New datasets were created where data was missing. All data was derived from existing authoritative sources and/or remotely sensed data. This data curation process ensured the input datasets, and resulting output, were relevant and fit for purpose.Limitations: This data should be considered indicative only as there are limitations to the modelling process. It considers all habitat and barriers equally and as discrete objects (i.e. it applies a discrete boundary around a patch and does not account for gradients or flexible boundaries).The model predicts habitat and connectivity based on the data available. It does not assess whether a species is present or consider temporal variability. Some habitat requirements are not mapped (e.g. native vegetation, lack of predators) due to the lack of an accurate or complete dataset. Some of these requirements are critical to the success of the species group. These habitat requirements are available and have been derived from expert elicitation. They should be considered at an area of interest.The model assumes the input data is up to date and accurate. Many of the habitat and barrier datasets used as inputs into the models are in some way informed by remote sensing data. Remote sensing data has limitations, such as potential for misclassification (e.g. bare ground and pavement could be confused). Additionally, remotely sensed data captures a point in time and will become outdated. Manual checks and improvements using supplementary data for specific sites have been completed to reduce as much error as possible.Data refinement: Unmapped habitat and connectivity requirements should be considered when using the data. The full list of known habitat and connectivity requirements for each species group, including those considered by the model and those unaccounted for, is available by request. Other data may also be used to track changes post-LiDAR capture. For example, new development footprints may be used to remove non-habitat areas and can be done so at a faster rate than waiting for new LiDAR captures and re-running the model.SHARINGLicenses/restrictions on use: Creative Commons By Attribution 4.0 (Australian Capital Territory)How to cite this data: ACT Government, 2023. Potential Habitat and Fragmentation in Urban ACT dataset, version 3. Polygon layer developed by the Office of Nature Conservation, Environment, Planning and Sustainable Development Directorate, Canberra.CONTACTFor accessibility issues or data enquiries please contact the Connecting Nature, Connecting People team cncp@act.gov.au.