This intersection points feature class represents current intersections in the City of Los Angeles. Few intersection points, named pseudo nodes, are used to split the street centerline at a point that is not a true intersection at the ground level. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Intersection layer was created in geographical information systems (GIS) software to display intersection points. Intersection points are placed where street line features join or cross each other and where freeway off- and on-ramp line features join street line features. The intersection points layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a point feature class and attribute data for the features. The intersection points relates to the intersection attribute table, which contains data describing the limits of the street segment, by the CL_NODE_ID field. The layer shows the location of the intersection points on map products and web mapping applications, and the Department of Transportation, LADOT, uses the intersection points in their GIS system. The intersection attributes are used in the Intersection search function on BOE's web mapping application NavigateLA. The intersection spatial data and related attribute data are maintained in the Intersection layer using Street Centerline Editing application. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. List of Fields:Y: This field captures the georeferenced location along the vertical plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, Y = in the record of a point, while the X = .CL_NODE_ID: This field value is entered as new point features are added to the edit layer, during Street Centerline application editing process. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline spatial data layer, then the intersections point spatial data layer, and then the intersections point attribute data during the creation of new intersection points. Each intersection identification number is a unique value. The value relates to the street centerline layer attributes, to the INT_ID_FROM and INT_ID_TO fields. One or more street centerline features intersect the intersection point feature. For example, if a street centerline segment ends at a cul-de-sac, then the point feature intersects only one street centerline segment.X: This field captures the georeferenced location along the horizontal plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, X = in the record of a point, while the Y = .ASSETID: User-defined feature autonumber.USER_ID: The name of the user carrying out the edits.SHAPE: Feature geometry.LST_MODF_DT: Last modification date of the polygon feature.LAT: This field captures the Latitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.OBJECTID: Internal feature number.CRTN_DT: Creation date of the polygon feature.TYPE: This field captures a value for intersection point features that are psuedo nodes or outside of the City. A pseudo node, or point, does not signify a true intersection of two or more different street centerline features. The point is there to split the line feature into two segments. A pseudo node may be needed if for example, the Bureau of Street Services (BSS) has assigned different SECT_ID values for those segments. Values: • S - Feature is a pseudo node and not a true intersection. • null - Feature is an intersection point. • O - Intersection point is outside of the City of LA boundary.LON: This field captures the Longitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.

This parcels dataset is a spatial representation of tax lots for Union County, New Jersey that have been extracted from the NJ statewide parcels composite by the NJ Office of Information Technology, Office of GIS (NJOGIS). Parcels at county boundaries have been modified to correspond with the NJ county boundaries and the parcels in adjacent counties.Each parcel contains a field named PAMS_PIN based on a concatenation of the county/municipality code, block number, lot number and qualification code. Using the PAMS_PIN, the dataset can be joined to the MOD-IV database table that contains supplementary attribute information regarding lot ownership and characteristics. Due to irregularities in the data development process, duplicate PAMS_PIN values exist in the parcel records. Users should avoid joining MOD-IV database table records to all parcel records with duplicate PAMS_PINs because of uncertainty regarding whether the MOD-IV records will join to the correct parcel records. There are also parcel records with unique PAMS_PIN values for which there are no corresponding records in the MOD-IV database tables. This is mostly due to the way data are organized in the MOD-IV database.The polygons delineated in the dataset do not represent legal boundaries and should not be used to provide a legal determination of land ownership. Parcels are not survey data and should not be used as such.The MOD-IV system provides for uniform preparation, maintenance, presentation and storage of property tax information required by the Constitution of the State of New Jersey, New Jersey Statutes and rules promulgated by the Director of the Division of Taxation. MOD-IV maintains and updates all assessment records and produces all statutorily required tax lists for property tax bills. This list accounts for all parcels of real property as delineated and identified on each municipality's official tax map, as well as taxable values and descriptive data for each parcel. Tax List records were received as raw data from the Taxation Team of NJOIT which collected source information from municipal tax assessors and created the statewide table. This table was subsequently processed for ease of use with NJ tax parcel spatial data and split into an individual table for each county.***NOTE*** For users who incorporate NJOGIS services into web maps and/or web applications, please sign up for the NJ Geospatial Forum discussion listserv for early notification of service changes. Visit https://nj.gov/njgf/about/listserv/ for more information.

2014 - 2016 Top 200 Intersection Crash Cluster Locations.The top locations where reported collisions occurred have been identified. The crash cluster analysis methodology for the crashes uses a fixed meter search distance of 25 meters (82 ft.) to merge crash clusters together. The analysis method finds nearby crashes and merges their areas together, thus creating clusters. If two distinct clusters are found to share a common crash, the two clusters are merged into a single cluster. This method of search-and-merge results in a set of many distinct clusters of different sizes and shapes Furthermore, the methodology uses the Equivalent Property Damage Only (EPDO) weighting to rank the clusters. Additionally, due to the large geographic area encompassed by the crash clusters, it was difficult to name them so they were left unnamed but can be viewed spatially. A review of each location was required to make that determination of the top at grade intersection clusters. Generally, a location was determined to be an “intersection” if the cluster did not contain roadways with grade separation (interchange) nor weaving sections (rotaries or ramps). Intersections located at the ends of off-ramps or traffic circles/rotaries were generally not included. The clusters were reviewed in descending EPDO order until 200 locations were obtained.

The top locations where reported collisions occurred at intersections have been identified. The crash cluster analysis methodology for the top intersection clusters uses a fixed meter search distance of 25 meters (82 ft.) to merge crash clusters together. This analysis was based on crashes where a police officer specified one of the following junction types: Four way intersection, T-intersection, Y-intersection, five point or more. Furthermore, the methodology uses the Equivalent Property Damage Only (EPDO) weighting to rank the clusters. EPDO is based any type of injury crash (including fatal, incapacitating, non-incapacitating and possible) having a weighting of 21 compared to a property damage only crash (which has weighting of 1). The clustering analysis used crashes from the three year period from 2013-2015. The area encompassing the crash cluster may cover a larger area than just the intersection so it is critical to view these spatially.

Vermont GIS Parcel Data (dataset name = CadastralParcels_VTPARCELS) is published as of a set of three data layers. It includes standardized statewide parcel data--with joined Grand List data--for Vermont municipalities; an intermediary intersection table and data layer are used to facilitate the join. Data is compiled from multiple sources by Vermont Center for Geographic Information. [Information on Statewide Property Parcel Mapping Program] [Full metadata, including field descriptions]Published Layers:Statewide Standardized Parcel Data - parcel polygons:(feature class name = Cadastral_VTPARCELS_poly_standardized_parcels)Active parcels (including unlanded buildings)--with joined Grand List data, public right-of-ways, trail right-of-ways (for trails identified on the VTrans General Highway Maps, AKA Town Highway Maps), and surface water areas that serve as property boundaries.This layer is a product of joining Grand List data to active parcels. It is a value-added layer with a schema that is based on Vermont GIS Parcel Data Standard 2.3 and the Grand List schema.For scenarios where a one-to-many relationship exists between land and Grand List records--e.g., land with unlanded buildings, this layer includes an individual polygon for each related Grand List record; such scenarios create a stacked-polygon effect. For example, when an identify tool is applied to a location that has fifteen mobile homes on a land parcel, sixteen identical polygons can be returned--one for the land-surface Grand List record and fifteen for each of the mobile-home Grand List records.Statewide Standardized Parcel Data - inactive parcel polygons:(feature class name = Cadastral_VTPARCELS_poly_standardized_inactive)Inactive parcels and their related active parcels. Schema is based on Vermont GIS Parcel Data Standard 2.3.Statewide Standardized Parcel Data - Data Status polygons:(feature class name = Cadastral_VTPARCELS_poly_DataStatus)Status of parcel data by municipality.Intermediary Intersection Table and Data Layer:TABLE_VTPARCELS_intersection:An intersection table that relates records of the Grand List which have active SPAN numbers to records in the Cadastral_VTPARCELS_poly_standardized_parcels feature class which represent parcel features (PROPTYPE = ‘PARCEL’). Supports bi-directional matching/reconciliation between the Grand List and the parcels feature class.Schema is based on Vermont GIS Parcel Data Standard 2.3.Cadastral_VTPARCELS_poly_standardized_NONJOINED_parcels:Geometry and GIS-attribute base of Cadastral_VTPARCELS_poly_standardized_parcels, without Grand-List join. Schema is based on Vermont GIS Parcel Data Standard 2.3.Update Frequency and Time Period of Content:Vermont GIS Parcel Data is generally updated weekly. The time period of its content varies by municipality.

Snapshot of all Cross roads, T Intersections, Dangerous Intersections, Circle, Y Intersections, Turns, Crossovers, Do Not Block Intersections, Large Arrows Two Directions, Turn Lane Signs, Advance Arrows, Merges, Diagonal Arrow of Approaching Roads, and lane must turn right or left signs in West Virginia as extracted by Mutcdname from an overall Sign Dataset. Datasets include RouteID, Sign ID Number, County Code, Route Number, Sub Route Number, Sign System, Supplemental Code, Supplemental Description, Direction, Milepoint, Number of Signs, Location, Mutcdname and Mutcode, Mutcdcat, Text, County, Photo URL, and XY Coordinates. Data is current as of 2015 and is updated as needed. Coordinate System: NAD_1983_UTM_Zone_17N

Feature class that compares the elevations between sand dune crests (extracted from available LiDAR datasets from 2010 and 2013) with published FEMA Base Flood Elevations (BFEs) from preliminary FEMA DFIRMS (Panels issued in 2018 and 2019) in coastal York and Cumberland counties (up through Willard Beach in South Portland). Steps to create the dataset included:Shoreline structures from the most recent NOAA EVI LANDWARD_SHORETYPE feature class were extracted using the boundaries of York and Cumberland counties. This included 1B: Exposed, Solid Man-Made structures, 8B: Sheltered, Solid Man-Made Structures; 6B: Riprap, and 8C: Sheltered Riprap. This resulted in the creation of Cumberland_ESIL_Structures and York_ESIL_Structures. Note that ESIL uses the MHW line as the feature base.Shoreline structures from the work by Rice (2015) were extracted using the York and Cumberland county boundaries. This resulted in the creation of Cumberland_Rice_Structures and York_Rice_Structures.Additional feature classes for structures were created for York and Cumberland county structures that were missed. This was Slovinsky_York_Structures and Slovinsky_Cumberland_Structures. GoogleEarth imagery was inspected while additional structures were being added to the GIS. 2012 York and Cumberland County imagery was used as the basemap, and structures were classified as bulkheads, rip rap, or dunes (if known). Also, whether or not the structure was in contact with the 2015 HAT was noted.MEDEP was consulted to determine which permit data (both PBR and Individual Permit, IP, data) could be used to help determine where shoreline stabilization projects may have been conducted adjacent to or on coastal bluffs. A file was received for IP data and brought into GIS (DEP_Licensing_Points). This is a point file for shoreline stabilization permits under NRPA.Clip GISVIEW.MEDEP.Permit_By_Rule_Locations to the boundaries of the study area and output DEP_PBR_Points.Join GISVIEW.sde>GISVIEW.MEDEP.PBR_ACTIVITY to the DEP_PBR_Points using the PBR_ID Field. Then, export this file as DEP_PBR_Points2. Using the new ACTIVITY_DESC field, select only those activities that relate to shoreline stabilization projects:PBR_ACTIVITY ACTIVITY_DESC02 Act. Adjacent to a Protected Natural Resource04 Maint Repair & Replacement of Structure08 Shoreline StabilizationSelect by Attributes > PBR_ACTIVITY IN (‘02’, ‘04’, ‘08’) select only those activities likely to be related to shoreline stabilization, and export the selected data as a DEP_PBR_Points3. Then delete 1 and 2, and rename this final product as DEP_PBR_Points.Next, visually inspect the Licensing and PBR files using ArcMap 2012, 2013 imagery, along with Google Earth imagery to determine the extents of armoring along the shoreline.Using EVI and Rice data as indicators, manually inspect and digitize sections of the coastline that are armored. Classify the seaward shoreline type (beach, mudflat, channel, dune, etc.) and the armor type (wall or bulkhead). Bring in the HAT line and, using that and visual indicators, identify whether or not the armored sections are in contact with HAT. Use Google Earth at the same time as digitizing in order to help constrain areas. Merge digitized armoring into Cumberland_York_Merged.Bring the preliminary FEMA DFIRM data in and use “intersect” to assign the different flood zones and elevations to the digitized armored sections. This was done first for Cumberland, then for York Counties. Delete ancillary attributes, as needed. Resulting layer is Cumberland_Structure_FloodZones and York_Structure_FloodZones.Go to NOAA Digital Coast Data Layers and download newest LiDAR data for York and Cumberland county beach, dune, and just inland areas. This includes 2006 and newer topobathy data available from 2010 (entire coast), and selected areas from 2013 and 2014 (Wells, Scarborough, Kennebunk).Mosaic the 2006, 2010, 2013 and 2014 data (with 2013 and 2014 being the first dataset laying on top of the 2010 data) Mosaic this dataset into the sacobaydem_ftNAVD raster (this is from the MEGIS bare-earth model). This will cover almost all of the study area except for armor along several areas in York. Resulting in LidAR206_2010_2013_Mosaic.tif.Using the LiDAR data as a proxy, create a “seaward crest” line feature class which follows along the coast and extracts the approximate highest point (cliff, bank, dune) along the shoreline. This will be used to extract LiDAR data and compare with preliminary flood zone information. The line is called Dune_Crest.Using an added tool Points Along Line, create points at 5 m spacing along each of the armored shoreline feature lines and the dune crest lines. Call the outputs PointsonLines and PointsonDunes.Using Spatial Analyst, Extract LIDAR elevations to the points using the 2006_2010_2013 Mosaic first. Call this LidarPointsonLines1. Select those points which have NULL values, export as this LiDARPointsonLines2. Then rerun Extract Values to Points using just the selected data and the state MEGIS DEM. Convert RASTERVALU to feet by multiplying by 3.2808 (and rename as Elev_ft). Select by Attributes, find all NULL values, and in an edit session, delete them from LiDARPointsonLines. Then, merge the 2 datasets and call it LidarPointsonLines. Do the same above with dune lines and create LidarPointsonDunes.Next, use the Cumberland and York flood zone layers to intersect the points with the appropriate flood zone data. Create ….CumbFIRM and …YorkFIRM files for the dunes and lines.Select those points from the Dunes feature class that are within the X zone – these will NOT have an associated BFE for comparison with the Lidar data. Export the Dune Points as Cumberland_York_Dunes_XZone. Run NEAR and use the merged flood zone feature class (with only V, AE, and AO zones selected). Then, join the flood zone data to the feature class using FID (from the feature class) and OBJECTID (from the flood zone feature class). Export as Cumberland_York_Dunes_XZone_Flood. Delete ancillary columns of data, leaving the original FLD_ZONE (X), Elev_ft, NEAR_DIST (distance, in m, to the nearest flood zone), FLD_ZONE_1 (the near flood zone), and the STATIC_BFE_1 (the nearest static BFE).Do the same as above, except with the Structures file (Cumberland_York_Structures_Lidar_DFIRM_Merged), but also select those features that are within the X zone and the OPEN WATER. Export the points as Cumberland_York_Structures_XZone. Again, run the NEAR using the merged flood zone and only AE, VE, and AO zones selected. Export the file as Cumberland_York_Structures_XZone_Flood.Merge the above feature classes with the original feature classes. Add a field BFE_ELEV_COMPARE. Select all those features whose attributes have a VE or AE flood zone and use field calculator to calculate the difference between the Elev_ft and the BFE (subtracting the STATIC_BFE from Elev_ft). Positive values mean the maximum wall value is higher than the BFE, while negative values mean the max is below the BFE. Then, select the remaining values with switch selection. Calculate the same value but use the NEAR_STATIC_BFE value instead. Select by Attributes>FLD_ZONE=AO, and use the DEPTH value to enter into the above created fields as negative values. Delete ancilary attribute fields, leaving those listed in the _FINAL feature classes described above the process steps section.

Vermont GIS Parcel Data (dataset name = CadastralParcels_VTPARCELS) is published as of a set of three data layers. It includes standardized statewide parcel data--with joined Grand List data--for Vermont municipalities; an intermediary intersection table and data layer are used to facilitate the join. Data is compiled from multiple sources by Vermont Center for Geographic Information. [Information on Statewide Property Parcel Mapping Program] [Full metadata, including field descriptions]Published Layers:Statewide Standardized Parcel Data - parcel polygons:(feature class name = Cadastral_VTPARCELS_poly_standardized_parcels)Active parcels (including unlanded buildings)--with joined Grand List data, public right-of-ways, trail right-of-ways (for trails identified on the VTrans General Highway Maps, AKA Town Highway Maps), and surface water areas that serve as property boundaries.This layer is a product of joining Grand List data to active parcels. It is a value-added layer with a schema that is based on Vermont GIS Parcel Data Standard 2.3 and the Grand List schema.For scenarios where a one-to-many relationship exists between land and Grand List records--e.g., land with unlanded buildings, this layer includes an individual polygon for each related Grand List record; such scenarios create a stacked-polygon effect. For example, when an identify tool is applied to a location that has fifteen mobile homes on a land parcel, sixteen identical polygons can be returned--one for the land-surface Grand List record and fifteen for each of the mobile-home Grand List records.Statewide Standardized Parcel Data - inactive parcel polygons:(feature class name = Cadastral_VTPARCELS_poly_standardized_inactive)Inactive parcels and their related active parcels. Schema is based on Vermont GIS Parcel Data Standard 2.3.Statewide Standardized Parcel Data - Data Status polygons:(feature class name = Cadastral_VTPARCELS_poly_DataStatus)Status of parcel data by municipality.Intermediary Intersection Table and Data Layer:TABLE_VTPARCELS_intersection:An intersection table that relates records of the Grand List which have active SPAN numbers to records in the Cadastral_VTPARCELS_poly_standardized_parcels feature class which represent parcel features (PROPTYPE = ‘PARCEL’). Supports bi-directional matching/reconciliation between the Grand List and the parcels feature class.Schema is based on Vermont GIS Parcel Data Standard 2.3.Cadastral_VTPARCELS_poly_standardized_NONJOINED_parcels:Geometry and GIS-attribute base of Cadastral_VTPARCELS_poly_standardized_parcels, without Grand-List join. Schema is based on Vermont GIS Parcel Data Standard 2.3.Update Frequency and Time Period of Content:Vermont GIS Parcel Data is generally updated weekly. The time period of its content varies by municipality.

For more information about the contents of each table, download the codebook.This layer/table is part of the Transportation-Health Database, developed in a joint partnership between the Los Angeles County Public Health Department and the City of Los Angeles Department of Transportation. For related tables/features, look below in "Related Datasets." All of the data tables are designed to be viewed by joining them to the intersection layer, "GeomIntersections." Join the "boeint_fkey" field in the table with the "boeint_pkey" field in the GeomIntersections feature layer. This project is in part supported by funding from the Centers for Disease Control and Prevention, Cooperative Agreement No. 1U58DP005509-01, through the Los Angeles County Department of Public Health.

Download .zipMaps and data associated with oil-and-gas wells represent one of the largest datasets at the Ohio Department of Natural Resources. This GIS data layer contains all the locatable oil-and-gas wells in Ohio. The feature is derived from coordinates obtained from the Division of Oil and Gas Resources Management (DOGRM) oil and gas well database – Risk Based Data Management System (RBDMS). The RBDMS database has a long history and is a comprehensive collection of well data from historic pre-1980 paper well records (digitized by the Division of Geological Survey (DGS)) to post-1980 DOGRM database solutions.Since 1860, it is estimated that more than 267,000 oil-and-gas wells have been drilled in Ohio. The compressed file also includes a feature used to connect the surface location to the bottom location of a well that has been drilled directionally or horizontally. This feature is NOT the actual wellbore path, it is simply a graphical representation indicating the relationship between the two well points.Contact Information:GIS Support, ODNR GIS ServicesOhio Department of Natural ResourcesDivision of Oil & Gas ResourcesOil and Gas Resources Management2045 Morse Road Bldg F-2Columbus, OH, 43229-6693Telephone: 614-265-6462Email: gis.support@dnr.ohio.gov Data Update Frequency: Every Saturday

View metadata for key information about this dataset.Topographic contours are a combination of line segments that connect but do not intersect; these represent elevation on a map of the natural and artificial features of an area. The contour data has been derived from the 2022 LiDAR collected between March and April of 2022 and the output tiled according to the tiling scheme used for the classified LiDAR dataset. Topographic contours are at intervals of one foot, and cover approximately 196 sq miles total.For questions about this dataset or for technical assistance, email maps@phila.gov.

View metadata for key information about this dataset.Topographic contours are a combination of line segments that connect but do not intersect; these represent elevation on a map of the natural and artificial features of an area. The contour data has been derived from the 2018 LiDAR collected between April 18th and 25th, 2018 and the output tiled according to the tiling scheme used for the classified LiDAR dataset. Topographic contours are at intervals of two feet, and cover approximately 196 sq miles total.For questions about this dataset or for technical assistance, email maps@phila.gov.

View metadata for key information about this dataset.Topographic contours are a combination of line segments that connect but do not intersect; these represent elevation on a map of the natural and artificial features of an area. The contours were generated from the 2015 LiDAR data which was collected between April 18th and 25th, 2015. The dataset consists of 1024 vector files which correspond to the classified LAS data of the same name and coverage. Topographic contours are at intervals of two feet, and cover approximately 196 sq miles total.For questions about this dataset or for technical assistance, email maps@phila.gov.

This dataset represents road centerlines (RCLs) for all named streets (including those named with a number) and private driveways in Snohomish County for use in the Washington State Next Generation 911 (NG911) program to support emergency call routing. RCLs follow the NENA RCL GIS data model and are provided to the Washington State NG911 program on a monthly basis and to Snohomish County Public Safety Answering Points on request. Any other use of these data are not directly supported by Snohomish County.Roads and driveways are updated daily or weekly from addressing notifications sent from partner jurisdictions, Snohomish County PDS, SNO911 dispatcher comments, reports from field crews, UAS flights conducted by EESCS, and other verified data sources as required. Named roads are typically digitized from official site plans and occasionally deviate from final construction. Private driveways are added to support proper routing of emergency crews and often include unofficial or ad-hoc roadways, and will always join another RCL at a vertex. Named roads are split wherever they intersect another named road or cross a jurisdictional boundary. Fields include valid TO and FROM address ranges for the street segment. In some cases, RCLs in new developments may appear in data before the roadway is completed. For a detailed description of all fields please refer to the NENA NG911 data model: https://www.nena.org/page/ng911gisdatamodel

Reason for SelectionProtected natural areas in urban environments provide urban residents a nearby place to connect with nature and offer refugia for some species. Because beaches in Puerto Rico and the U.S. Virgin Islands are open to the public, beaches also provide important outdoor recreation opportunities for urban residents, so we include beaches as parks in this indicator.Input DataSoutheast Blueprint 2023 subregions: CaribbeanSoutheast Blueprint 2023 extentNational Oceanic and Atmospheric Administration (NOAA) National Centers for Environmental Information (NCEI) Coastal Relief Model, accessed 11-22-2022Protected Areas Database of the United States (PAD-US) 3.0: VI, PR, and Marine Combined Fee EasementPuerto Rico Protected Natural Areas 2018 (December 2018 update): Terrestrial and marine protected areas (PACAT2018_areas_protegidasPR_TERRESTRES_07052019.shp, PACAT2018_areas_protegidasPR_MARINAS_07052019.shp) 2020 Census Urban Areas from the Census Bureau’s urban-rural classification; download the data, read more about how urban areas were redefined following the 2020 censusOpenStreetMap data “multipolygons” layer, accessed 3-14-2023A polygon from this dataset is considered a park if the “leisure” tag attribute is either “park” or “nature_reserve”, and considered a beach if the value in the “natural” tag attribute is “beach”. OpenStreetMap describes leisure areas as “places people go in their spare time” and natural areas as “a wide variety of physical geography, geological and landcover features”. Data were downloaded in .pbf format and translated ton an ESRI shapefile using R code. OpenStreetMap® is open data, licensed under the Open Data Commons Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF). Additional credit to OSM contributors. Read more on the OSM copyright page. TNC Lands - Public Layer, accessed 3-8-2023U.S. Virgin Islands beaches layer (separate vector layers for St. Croix, St. Thomas, and St. John) provided by Joe Dwyer with Lynker/the NOAA Caribbean Climate Adaptation Program on 3-3-2023 (contact jdwyer@lynker.com for more information)Mapping StepsMost mapping steps were completed using QGIS (v 3.22) Graphical Modeler.Fix geometry errors in the PAD-US PR data using Fix Geometry. This must be done before any analysis is possible.Merge the terrestrial PR and VI PAD-US layers.Use the NOAA coastal relief model to restrict marine parks (marine polygons from PAD-US and Puerto Rico Protected Natural Areas) to areas shallower than 10 m in depth. The deep offshore areas of marine parks do not meet the intent of this indicator to capture nearby opportunities for urban residents to connect with nature.Merge into one layer the resulting shallow marine parks from marine PAD-US and the Puerto Rico Protected Natural Areas along with the combined terrestrial PAD-US parks, OpenStreetMap, TNC Lands, and USVI beaches. Omit from the Puerto Rico Protected Areas layer the “Zona de Conservación del Carso”, which has some policy protections and conservation incentives but is not formally protected.Fix geometry errors in the resulting merged layer using Fix Geometry.Intersect the resulting fixed file with the Caribbean Blueprint subregion.Process all multipart polygons to single parts (referred to in Arc software as an “explode”). This helps the indicator capture, as much as possible, the discrete units of a protected area that serve urban residents.Clip the Census urban area to the Caribbean Blueprint subregion.Select all polygons that intersect the Census urban extent within 1.2 miles (1,931 m). The 1.2 mi threshold is consistent with the average walking trip on a summer day (U.S. DOT 2002) used to define the walking distance threshold used in the greenways and trails indicator. Note: this is further than the 0.5 mi distance used in the continental version of the indicator. We extended it to capture East Bay and Point Udall based on feedback from the local conservation community about the importance of the park for outdoor recreation.Dissolve all the park polygons that were selected in the previous step.Process all multipart polygons to single parts (“explode”) again.Add a unique ID to the selected parks. This value will be used to join the parks to their buffers.Create a 1.2 mi (1,931 m) buffer ring around each park using the multiring buffer plugin in QGIS. Ensure that “dissolve buffers” is disabled so that a single 1.2 mi buffer is created for each park.Assess the amount of overlap between the buffered park and the Census urban area using overlap analysis. This step is necessary to identify parks that do not intersect the urban area, but which lie within an urban matrix. This step creates a table that is joined back to the park polygons using the UniqueID.Remove parks that had ≤2% overlap with the urban areas when buffered. This excludes mostly non-urban parks that do not meet the intent of this indicator to capture parks that provide nearby access for urban residents. Note: In the continental version of this indicator, we used a threshold of 10%. In the Caribbean version, we lowered this to 2% in order to capture small parks that dropped out of the indicator when we extended the buffer distance to 1.2 miles.Calculate the GIS acres of each remaining park unit using the Add Geometry Attributes function.Join the buffer attribute table to the previously selected parks, retaining only the parks that exceeded the 2% urban area overlap threshold while buffered. Buffer the selected parks by 15 m. Buffering prevents very small parks and narrow beaches from being left out of the indicator when the polygons are converted to raster.Reclassify the polygons into 7 classes, seen in the final indicator values below. These thresholds were informed by park classification guidelines from the National Recreation and Park Association, which classify neighborhood parks as 5-10 acres, community parks as 30-50 acres, and large urban parks as optimally 75+ acres (Mertes and Hall 1995).Export the final vector file to a shapefile and import to ArcGIS Pro.Convert the resulting polygons to raster using the ArcPy Polygon to Raster function. Assign values to the pixels in the resulting raster based on the polygon class sizes of the contiguous park areas.Clip to the Caribbean Blueprint 2023 subregion.As a final step, clip to the spatial extent of Southeast Blueprint 2023. Note: For more details on the mapping steps, code used to create this layer is available in the Southeast Blueprint Data Download under > 6_Code. Final indicator valuesIndicator values are assigned as follows:6 = 75+ acre urban park5 = >50 to <75 acre urban park4 = 30 to <50 acre urban park3 = 10 to <30 acre urban park2 = 5 to <10 acre urban park1 = <5 acre urban park0 = Not identified as an urban parkKnown IssuesThis indicator does not include park amenities that influence how well the park serves people and should not be the only tool used for parks and recreation planning. Park standards should be determined at a local level to account for various community issues, values, needs, and available resources. This indicator includes some protected areas that are not open to the public and not typically thought of as “parks”, like mitigation lands, private easements, and private golf courses. While we experimented with excluding them using the public access attribute in PAD, due to numerous inaccuracies, this inadvertently removed protected lands that are known to be publicly accessible. As a result, we erred on the side of including the non-publicly accessible lands.This indicator includes parks and beaches from OpenStreetMap, which is a crowdsourced dataset. While members of the OpenStreetMap community often verify map features to check for accuracy and completeness, there is the potential for spatial errors (e.g., misrepresenting the boundary of a park) or incorrect tags (e.g., labelling an area as a park that is not actually a park). However, using a crowdsourced dataset gives on-the-ground experts, Blueprint users, and community members the power to fix errors and add new parks to improve the accuracy and coverage of this indicator in the future.Other Things to Keep in MindThis indicator calculates the area of each park using the park polygons from the source data. However, simply converting those park polygons to raster results in some small parks and narrow beaches being left out of the indicator. To capture those areas, we buffered parks and beaches by 15 m and applied the original area calculation to the larger buffered polygon, so as not to inflate the area by including the buffer. As a result, when the buffered polygons are rasterized, the final indicator has some areas of adjacent pixels that receive different scores. While these pixels may appear to be part of one contiguous park or suite of parks, they are scored differently because the park polygons themselves are not actually contiguous. The Caribbean version of this indicator uses a slightly different methodology than the continental Southeast version. It includes parks within a 1.2 mi distance from the Census urban area, compared to 0.5 mi in the continental Southeast. We extended it to capture East Bay and Point Udall based on feedback from the local conservation community about the importance of the park for outdoor recreation. Similarly, this indicator uses a 2% threshold of overlap between buffered parks and the Census urban areas, compared to a 10% threshold in the continental Southeast. This helped capture small parks that dropped out of the indicator when we extended the buffer distance to 1.2 miles. Finally, the Caribbean version does not use the impervious surface cutoff applied in the continental Southeast because the landcover data available in the Caribbean does not assess percent impervious in a comparable way.Disclaimer: Comparing with Older Indicator VersionsThere are numerous problems with using Southeast Blueprint

The top 200 locations where reported collisions occurred at intersections have been identified. The crash cluster analysis methodology for the top intersection clusters uses a fixed meter search distance of 25 meters (82 ft.) to merge crash clusters together. This analysis was based on crashes where a police officer specified one of the following junction types: Four way intersection, T-intersection, Y-intersection, five point or more. Furthermore, the methodology uses the Equivalent Property Damage Only (EPDO) weighting to rank the clusters. EPDO is based any type of injury crash (including fatal, incapacitating, non-incapacitating and possible) having a weighting of 21 compared to a property damage only crash (which has weighting of 1). The clusters were reviewed in descending EPDO order until 200 locations were obtained. The clustering analysis used crashes from the three year period from 2017-2019. The area encompassing the crash cluster may cover a larger area than just the intersection so it is critical to view these spatially.

The data illustrates the “Urbanized Area” for the Municipal Separate Storm Sewer System (MS4) program from the 2010 census. "Urbanized area" means a place and the adjacent densely populated territory that together have a minimum population of 50,000 people, as defined by the United States bureau of the census and as determined by the latest available decennial census. The data is provided to the Michigan Department of Environment, Great Lakes, and Energy (EGLE) by the United States Environmental Protection Agency. The urbanized area is the regulated area for municipalities that are regulated under the MS4 program, including but not limited to cities, township, and villages."2020 Census Populations of 50K or more" and "Automatically Designated Areas" was provided by US EPA in July 2023 and combined with Michigan Open GIS Data (Minor Civil Divisions: Cities, Townships and Villages) using ESRI's ArcGIS Pro Software. Tools used include Pairwise Intersect, Merge, Pairwise Erase, and manual editing to combine the two layers.Please contact the individuals below with any questions.Christe Alwin: ALWINC@michigan.gov (point of contact)Patrick Klein: kleinp3@michigan.gov (creator)

FIELD NAME

DESCRIPTION

Name

Short name of the municipality (Lansing)

Label

The municipalities full name (City of Lansing)

Type

The type of municipality (city, township, or village)

SQMILEArea of the shape in Square Miles

ACRES

Area of the shape in Acres

Published in June 2024. Learn more about EGLE's Municipal Storm Water Program.Additional information describing Part 21 Wastewater Discharge Permits.