Unincorporated Urban Growth Areas (UGA) as defined by the Growth Management Act (GMA). The annual update is conducted by collecting UGA polygons directly from each of Washington's 39 counties. As of 2025, there are 27 counties with UGAs.All UGA polygons are normalized against the Department of Revenue's (DOR) "City Boundaries" layer (shared to the Washington Geoportal a.k.a. the GIS Open Data site: geo.wa.gov). The City Boundaries layer was processed into this UGA layer such that any overlapping area of UGA polygons (from authoritative individual counties) was erased. Since DOR polygons and county-sourced UGA polygons do not have perfect topology, many slivers resulted after the erase operation. These are attempted to be irradicated by these processing steps. "Multipart To Singlepart" Esri tool; exploded all polygons to be individualSlivers were mathematically identified using a 4 acre area threshold and a 0.3 "thinness ratio" threshold as described by Esri's "Polygon Sliver" tool. These slivers are merged into the neighboring features using Esri's "Eliminate" tool.Polygons that are less than 5,000 sq. ft. and not part of a DOR city (CITY_NM = Null) were also merged via the "Eliminate" tool. (many very small slivers were manually found yet mathematically did not meet the thinness ratio threshold)The final 8 polygons less than 25 sq. ft. were manually deleted (also slivers but were not lined up against another feature and missed by the "Eliminate" tool runs)Dissolved all features back to multipart using all fieldsAll UGAs polygons remaining are unincorporated areas beyond the city limits. Any polygon with CITY_NM populated originated from the DOR "City Boundaries" layer. The DOR's City Boundaries are updated quarterly by DOR. For the purposes of this UGA layer, the city boundaries was downloaded one time (4/24/2025) and will not be updated quarterly. Therefore, if precise city limits are required by any user of UGA boundaries, please refer to the city boundaries layer and conduct any geoprocessing needed. The DOR's "City Boundaries" layer is available here:https://www.arcgis.com/home/item.html?id=69fcb668dc8d49ea8010b6e33e42a13aData is updated in conjunction with the annual statewide parcel layer update. Latest update completed April 2025.

The files linked to this reference are the geospatial data created as part of the completion of the baseline vegetation inventory project for the NPS park unit. Current format is ArcGIS file geodatabase but older formats may exist as shapefiles. The TOP 2015 imagery was mosaiced and manipulated using image processing and segmentation techniques (e.g. unsupervised image classification, normalized difference vegetation index, etc.) to highlight any subtle vegetation signature differences. All of the preliminary results were evaluated for usefulness and the best examples were first converted to digital lines and polygons, were next combined with other relevant AMIS GIS layers (such as the roads network), and the results were used as the base layer for the new AMIS vegetation mapping effort. Building off the base layer, all relevant lines and polygons were exported as shapefiles and converted to ArcGIS coverages. The resulting coverages were run through a series of smoothing routines provided in the ArcGIS software. Following the smoothing, all digital line-work was manipulated to remove extraneous lines, eliminate small polygons, and merged polygons that split obvious stands of homogeneous vegetation. The cleaning stage was considered complete when all resulting polygons matched homogenous stands of vegetation apparent on the TOP 2015 imagery. At this point, the mapping shifted to manual techniques and all vegetation lines and polygons were visually inspected and manually moved, edited and/or updated as needed.

Polygons in this layer represent low food access areas: areas of the District of Columbia which are estimated to be more than a 10-minute walk from the nearest full-service grocery store. These have been merged with Census poverty data to estimate how much of the population within these areas is food insecure (below 185% of the federal poverty line in addition to living in a low food access area).Office of Planning GIS followed several steps to create this layer, including: transit analysis, to eliminate areas of the District within a 10-minute walk of a grocery store; non-residential analysis, to eliminate areas of the District which do not contain residents and cannot classify as low food access areas (such as parks and the National Mall); and Census tract division, to estimate population and poverty rates within the newly created polygon boundaries.Fields contained in this layer include:Intermediary calculation fields for the aforementioned analysis, and:PartPop2: The total population estimated to live within the low food access area polygon (derived from Census tract population, assuming even distribution across the polygon after removing non-residential areas, followed by the removal of population living within a grocery store radius.)PrtOver185: The portion of PartPop2 which is estimated to have household income above 185% of the federal poverty line (the food secure population)PrtUnd185: The portion of PartPop2 which is estimated to have household income below 185% of the federal poverty line (the food insecure population)PercentUnd185: A calculated field showing PrtUnd185 as a percent of PartPop2. This is the percent of the population in the polygon which is food insecure (both living in a low food access area and below 185% of the federal poverty line).Note that the polygon representing Joint Base Anacostia-Bolling was removed from this analysis. While technically classifying as a low food access area based on the OP Grocery Stores layer (since the JBAB Commissary, which only serves military members, is not included in that layer), it is recognized that those who do live on the base have access to the commissary for grocery needs.Last updated November 2017.

This dataset corresponds to land area polygons of Australian coastline and surrounding islands. It was generated from 10 m Sentinel 2 imagery from 2022 - 2024 using the Normalized Difference Water Index (NDWI) to distinguish land from water. It was estimated from composite imagery made up from images where the tide is above the mean sea level. The coastline approximately corresponds to the mean high water level. This dataset was created as part of the NESP MaC 3.17 northern Australian Reef mapping project. It was developed to allow the inshore edge of digitised fringing reef features to be neatly clipped to the land areas without requiring manual digitisation of the neighbouring coastline. This required a coastline polygon with an edge positional error of below 50 m so as to not distort the shape of small fringing reefs. We found that existing coastline datasets such as the Geodata Coast 100K 2004 and the Australian Hydrographic Office (AHO) Australian land and coastline dataset did not meet our needs. The scale of the Geodata Coast 100K 2004 was too coarse to represent small islands and the the positional error of the Australian Hydrographic Office (AHO) Australian land and coastline dataset was too high (typically 80 m) for our application as the errors would have introduced significant errors in the shape of small fringing reefs. The Digital Earth Australia Coastline (GA) dataset was sufficiently accurate and detailed however the format of the data was unsuitable for our application as the coast was expressed as disconnected line features between rivers, rather than a closed polygon of the land areas. We did however base our approach on the process developed for the DEA coastline described in Bishop-Taylor et al., 2021 (https://doi.org/10.1016/j.rse.2021.112734). Adapting it to our existing Sentinel 2 Google Earth processing pipeline. The difference between the approach used for the DEA coastline and this dataset was the DEA coastline performed the tidal calculations and filtering at the pixel level, where as in this dataset we only estimated a single tidal level for each whole Sentinel image scene. This was done for computational simplicity and to align with our existing Google Earth Engine image processing code. The images in the stack were sorted by this tidal estimate and those with a tidal high greater than the mean seal level were combined into the composite. The Sentinel 2 satellite follows a sun synchronous orbit and so does not observe the full range of tidal levels. This observed tidal range varies spatially due to the relative timing of peak tides with satellite image timing. We made no accommodation for variation in the tidal levels of the images used to calculate the coastline, other than selecting images that were above the mean tide level. This means tidal height that the dataset coastline corresponds to will vary spatially. While this approach is less precise than that used in the DEA Coastline the resulting errors were sufficiently low to meet the project goals.
This simplified approach was chosen because it integrated well with our existing Sentinel 2 processing pipeline for generating composite imagery. To verify the accuracy of this dataset we manually checked the generated coastline with high resolution imagery (ArcGIS World Imagery). We found that 90% of the coastline polygons in this dataset have a horizontal position error of less than 20 m when compared to high-resolution imagery, except for isolated failure cases. During our manual checks we identified some areas where our algorithm can lead to falsely identifying land or not identifying land. We identified specific scenarios, or 'failure modes,' where our algorithm struggled to distinguish between land and water. These are shown in the image "Potential failure modes": a) The coastline is pushed out due to breaking waves (example: western coast, S2 tile ID 49KPG). b) False land polygons are created because of very turbid water due to suspended sediment. In clear water areas the near infrared channel is almost black, starkly different to the bright land areas. In very highly turbid waters the suspended sediment appears in the near infrared channel, raising its brightness to a level where it starts to overlap with the brightness of the dimmest land features. (example: Joseph Bonaparte Gulf, S2 tile ID 52LEJ). This results in turbid rivers not being correctly mapped. In version 1-1 of the dataset the rivers across northern Australia were manually corrected for these failures. c) Very shallow, gentle sloping areas are not recognised as water and the coastline is pushed out (example: Mornington Island, S2 tile ID 54KUG). Update: A second review of this area indicated that the mapped coastline is likely to be very close to the try coastline. d) The coastline is lower than the mean high water level (example: Great Keppel (Wop-pa) Island, S2 tile ID 55KHQ). Some of these potential failure modes could probably be addressed in the future by using a higher resolution tide calculation and using adjusted NDWI thresholds per region to accommodate for regional differences. Some of these failure modes are likely due to the near infrared channel (B8) being able to penetrate the water approximately 0.5 m leading to errors in very shallow areas. Some additional failures include: - Interpreting jetties as land - Interpreting oil rigs as land - Bridges being interpreted as land, cutting off rivers Methods: The coastline polygons were created in four separate steps: 1. Create above mean sea level (AMSL) composite images. 2. Calculate the Normalized Difference Water Index (NDWI) and visualise as a grey scale image. 3. Generate vector polygons from the grey scale image using a NDWI threshold. 4. Clean up and merge polygons. To create the AMSL composite images, multiple Sentinel 2 images were combined using the Google Earth Engine. The core algorithm was: 1. For each Sentinel 2 tile filter the "COPERNICUS/S2_HARMONIZED" image collection by - tile ID - maximum cloud cover 20% - date between '2022-01-01' and '2024-06-30' - asset_size > 100000000 (remove small fragments of tiles) 2. Remove high sun-glint images (see "High sun-glint image detection" for more information). 3. Split images by "SENSING_ORBIT_NUMBER" (see "Using SENSING_ORBIT_NUMBER for a more balanced composite" for more information). 4. Iterate over all images in the split collections to predict the tide elevation for each image from the image timestamp (see "Tide prediction" for more information). 5. Remove images where tide elevation is below mean sea level. 6. Select maximum of 200 images with AMSL tide elevation. 7. Combine SENSING_ORBIT_NUMBER collections into one image collection. 8. Remove sun-glint and apply atmospheric correction on each image (see "Sun-glint removal and atmospheric correction" for more information). 9. Duplicate image collection to first create a composite image without cloud masking and using the 15th percentile of the images in the collection (i.e. for each pixel the 15th percentile value of all images is used). 10. Apply cloud masking to all images in the original image collection (see "Cloud Masking" for more information) and create a composite by using the 15th percentile of the images in the collection (i.e. for each pixel the 15th percentile value of all images is used). 11. Combine the two composite images (no cloud mask composite and cloud mask composite). This solves the problem of some coral cays and islands being misinterpreted as clouds and therefore creating holes in the composite image. These holes are "plugged" with the underlying composite without cloud masking. (Lawrey et al. 2022) Next, for each image the NDWI was calculated: 1. Calculate the normalised difference using the B3 (green) and B8 (near infrared). 2. Shift the value range from between -1 and +1 to values between 1 and 255 (0 reserved as no-data value). 3. Export image as 8 bit unsigned Integer grey scale image. During the next step, we generated vector polygons from the grey scale image using a NDWI threshold: 1. Upscale image to 5 m resolution using bilinear interpolation. This was to help smooth the coastline and reduce the error introduced by the jagged pixel edges. 2. Apply a threshold to create a binary image (see "NDWI Threshold" for more information) with the value 1 for land and 2 for water (0: no data). 3. Create polygons for land values (1) in the binary image. 4. Export as shapefile. Finally, we created a single layer from the vectorised images: 1. Merge and dissolve all vector layers in QGIS. 2. Perform smoothing (QGIS toolbox, Iterations 1, Offset 0.25, Maximum node angle to smooth 180). 3. Perform simplification (QGIS toolbox, tolerance 0.00003). 4. Remove polygon vertices on the inner circle to fill out the continental Australia. 5. Perform manual QA/QC. In this step we removed false polygons created due to sun glint and breaking waves. We also removed very small features (1 – 1.5 pixel sized features, e.g. single mangrove trees) by calculating the area of each feature (in m2) and removing features smaller than 200 m2. 15th percentile composite: The composite image was created using the 15th percentile of the pixels values in the image stack. The 15th percentile was chosen, in preference to the median, to select darker pixels in the stack as these tend to correspond to images with clearer water conditions and higher tides. High sun-glint image detection: Images with high sun-glint can lead to lower quality composite images. To determine high sun-glint images, a land mask was first applied to the image to only retain water pixels. This land mask was estimated using NDWI. The proportion of the water pixels in the near-infrared and short-wave infrared bands above a sun-glint threshold was calculated. Images with a high proportion were then filtered out of the image collection.
Sun-glint removal and atmospheric correction: The Top of Atmosphere L1

WARNING: This is a pre-release dataset and its fields names and data structures are subject to change. It should be considered pre-release until the end of 2024. Expected changes:Metadata is missing or incomplete for some layers at this time and will be continuously improved.We expect to update this layer roughly in line with CDTFA at some point, but will increase the update cadence over time as we are able to automate the final pieces of the process.This dataset is continuously updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications.PurposeCounty and incorporated place (city) boundaries along with third party identifiers used to join in external data. Boundaries are from the authoritative source the California Department of Tax and Fee Administration (CDTFA), altered to show the counties as one polygon. This layer displays the city polygons on top of the County polygons so the area isn"t interrupted. The GEOID attribute information is added from the US Census. GEOID is based on merged State and County FIPS codes for the Counties. Abbreviations for Counties and Cities were added from Caltrans Division of Local Assistance (DLA) data. Place Type was populated with information extracted from the Census. Names and IDs from the US Board on Geographic Names (BGN), the authoritative source of place names as published in the Geographic Name Information System (GNIS), are attached as well. Finally, the coastline is used to separate coastal buffers from the land-based portions of jurisdictions. This feature layer is for public use.Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal BuffersCounties: Full county boundaries and attributes, including all cities within as a single polygonWith Coastal BuffersWithout Coastal BuffersCities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.With Coastal Buffers (this dataset)Without Coastal BuffersPlace AbbreviationsUnincorporated Areas (Coming Soon)Census Designated Places (Coming Soon)Cartographic CoastlinePolygonLine source (Coming Soon)Working with Coastal BuffersThe dataset you are currently viewing includes the coastal buffers for cities and counties that have them in the authoritative source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except COASTAL, Area_SqMi, Shape_Area, and Shape_Length to get a version with the correct identifiers.Point of ContactCalifornia Department of Technology, Office of Digital Services, odsdataservices@state.ca.govField and Abbreviation DefinitionsCOPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering systemPlace Name: CDTFA incorporated (city) or county nameCounty: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.Legal Place Name: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.GEOID: numeric geographic identifiers from the US Census Bureau Place Type: Board on Geographic Names authorized nomenclature for boundary type published in the Geographic Name Information SystemPlace Abbr: CalTrans Division of Local Assistance abbreviations of incorporated area namesCNTY Abbr: CalTrans Division of Local Assistance abbreviations of county namesArea_SqMi: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.COASTAL: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.AccuracyCDTFA"s source data notes the following about accuracy:City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. COUNTY = county name; CITY = city name or unincorporated territory; COPRI = county number followed by the 3-digit city primary number used in the California State Board of Equalization"s 6-digit tax rate area numbering system (for the purpose of this map, unincorporated areas are assigned 000 to indicate that the area is not within a city).Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties.In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose.SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More information on this algorithm will be provided soon.Coastline CaveatsSome cities have buffers extending into water bodies that we do not cut at the shoreline. These include South Lake Tahoe and Folsom, which extend into neighboring lakes, and San Diego and surrounding cities that extend into San Diego Bay, which our shoreline encloses. If you have feedback on the exclusion of these items, or others, from the shoreline cuts, please reach out using the contact information above.Offline UseThis service is fully enabled for sync and export using Esri Field Maps or other similar tools. Importantly, the GlobalID field exists only to support that use case and should not be used for any other purpose (see note in field descriptions).Updates and Date of ProcessingConcurrent with CDTFA updates, approximately every two weeks, Last Processed: 12/17/2024 by Nick Santos using code path at https://github.com/CDT-ODS-DevSecOps/cdt-ods-gis-city-county/ at commit 0bf269d24464c14c9cf4f7dea876aa562984db63. It incorporates updates from CDTFA as of 12/12/2024. Future updates will include improvements to metadata and update frequency.

The LAS data set was originally classified according to 4 classes (ground, water, bridge overpass, and noise), with the rest of the data being unclassified. That left some classes to be derived and classified, of which one—the building/ structure class—was considered necessary for this project. In theory, deriving a building/structure layer is relatively straightforward: the building reflectance response should be unclassified, single-reflectance response points, whereas the vegetation, also unclassified, should yield a multiple-reflectance response as the beam bounces back through the canopy. Following this idea, we created a Digital Surface Model (DSM) from the single-response, unclassified LAS point cloud. We then subtracted these DSMs from the Bare Earth DEMs to create a difference image, which ideally should represent only buildings. Unfortunately, many trees were included in this “buildings” layer, due possibly to the sparse canopy that is characteristic of trees found in southwestern forests and possibly to the presence of fairly recent burn scars that include a number of standing dead trees and snags. In an attempt to remove the clutter of false positives due to trees, we developed a Normalized Difference Vegetation Index (NDVI) from the NAIP imagery acquired over the area in the same year. The NDVI is an image-processing technique that uses the reflective information found in the red (Red) and near-infrared (NIR) wavelengths to enhance the “green” vegetative response over other, non-vegetated surface features (Eq. 1). NDVI = (NIR−Red)/(NIR+Red) [Eq. 1]. This provides a floating-point image of values from -1 to 1, with numbers above 0 representing increasing vegetative cover. We further modified the NDVI equation to create an 8-bit image (Eq. 2). NDVImod = (NDVI+1)*100 [Eq. 2]. This 8-bit image had all positive integer values, where values above 100 indicated increasing vegetative cover. We used the generated NDVI image, in particular values above 109, to mask out many of the false anomalies. In addition, all heights less than 6 feet were masked out, as this was considered a minimum height for most buildings. We added 1 to values in the resulting image so that all values, even the zeroes, would be counted. Then values were clumped to produce an image of individually coded raster polygons. We eliminated all clusters smaller than 32 square meters (345 square feet) from the clumped image, ran a 3x3 majority filter to remove relict edges, and ran a 3x3 morphological close filter to remove holes in the raster polygons. We completed the raster processing in ERDAS IMAGINE and then converted the data set to a polygon layer in ESRI ArcGIS, as is and without using the ‘simplify polygon’ option. This was cleaned up further using the simplify buildings module with a minimum spacing of 2 meters. Once this was completed, the polygon layer was edited using the NAIP imagery and DSM Shaded Relief imagery as a background by a heads-up digitizing at a 1:3,000 scale (the approximate base resolution of the LiDAR data). The building/structure layer contained more than 44,612 identified structures.

Note: The schema changed in February 2025 - please see below. We will post a roadmap of upcoming changes, but service URLs and schema are now stable. For deployment status of new services beginning in February 2025, see https://gis.data.ca.gov/pages/city-and-county-boundary-data-status. Additional roadmap and status links at the bottom of this metadata.This dataset is regularly updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications. PurposeCounty boundaries along with third party identifiers used to join in external data. Boundaries are from the California Department of Tax and Fee Administration (CDTFA). These boundaries are the best available statewide data source in that CDTFA receives changes in incorporation and boundary lines from the Board of Equalization, who receives them from local jurisdictions for tax purposes. Boundary accuracy is not guaranteed, and though CDTFA works to align boundaries based on historical records and local changes, errors will exist. If you require a legal assessment of boundary location, contact a licensed surveyor.This dataset joins in multiple attributes and identifiers from the US Census Bureau and Board on Geographic Names to facilitate adding additional third party data sources. In addition, we attach attributes of our own to ease and reduce common processing needs and questions. Finally, coastal buffers are separated into separate polygons, leaving the land-based portions of jurisdictions and coastal buffers in adjacent polygons. This feature layer is for public use. Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal BuffersCounties: Full county boundaries and attributes, including all cities within as a single polygonWith Coastal Buffers (this dataset)Without Coastal BuffersCities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.With Coastal BuffersWithout Coastal BuffersCity and County AbbreviationsUnincorporated Areas (Coming Soon)Census Designated PlacesCartographic CoastlinePolygonLine source (Coming Soon)State BoundaryWith Bay CutsWithout Bay Cuts Working with Coastal Buffers The dataset you are currently viewing includes the coastal buffers for cities and counties that have them in the source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except OFFSHORE and AREA_SQMI to get a version with the correct identifiers. Point of ContactCalifornia Department of Technology, Office of Digital Services, gis@state.ca.gov Field and Abbreviation DefinitionsCDTFA_COUNTY: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.CDTFA_COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system. The boundary data originate with CDTFA's teams managing tax rate information, so this field is preserved and flows into this dataset.CENSUS_GEOID: numeric geographic identifiers from the US Census BureauCENSUS_PLACE_TYPE: City, County, or Town, stripped off the census name for identification purpose.GNIS_PLACE_NAME: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.CDT_COUNTY_ABBR: Abbreviations of county names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 3 characters.CDT_NAME_SHORT: The name of the jurisdiction (city or county) with the word "City" or "County" stripped off the end. Some changes may come to how we process this value to make it more consistent.AREA_SQMI: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.OFFSHORE: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".PRIMARY_DOMAIN: Currently empty/null for all records. Placeholder field for official URL of the city or countyCENSUS_POPULATION: Currently null for all records. In the future, it will include the most recent US Census population estimate for the jurisdiction.GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead. Boundary AccuracyCounty boundaries were originally derived from a 1:24,000 accuracy dataset, with improvements made in some places to boundary alignments based on research into historical records and boundary changes as CDTFA learns of them. City boundary data are derived from pre-GIS tax maps, digitized at BOE and CDTFA, with adjustments made directly in GIS for new annexations, detachments, and corrections.Boundary accuracy within the dataset varies. While CDTFA strives to correctly include or exclude parcels from jurisdictions for accurate tax assessment, this dataset does not guarantee that a parcel is placed in the correct jurisdiction. When a parcel is in the correct jurisdiction, this dataset cannot guarantee accurate placement of boundary lines within or between parcels or rights of way. This dataset also provides no information on parcel boundaries. For exact jurisdictional or parcel boundary locations, please consult the county assessor's office and a licensed surveyor. CDTFA's data is used as the best available source because BOE and CDTFA receive information about changes in jurisdictions which otherwise need to be collected independently by an agency or company to compile into usable map boundaries. CDTFA maintains the best available statewide boundary information. CDTFA's source data notes the following about accuracy: City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties. In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose. SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More information on this algorithm will be provided soon. Coastline CaveatsSome cities have buffers extending into water bodies that we do not cut at the shoreline. These include South Lake Tahoe and Folsom, which extend into neighboring lakes, and San Diego and surrounding cities that extend into San Diego Bay, which our shoreline encloses. If you have feedback on the exclusion of these

The LAS data set was originally classified according to 4 classes (ground, water, bridge overpass, and noise), with the rest of the data being unclassified. That left some classes to be derived and classified, of which one—the building/ structure class—was considered necessary for this project. In theory, deriving a building/structure layer is relatively straightforward: the building reflectance response should be unclassified, single-reflectance response points, whereas the vegetation, also unclassified, should yield a multiple-reflectance response as the beam bounces back through the canopy. Following this idea, we created a Digital Surface Model (DSM) from the single-response, unclassified LAS point cloud. We then subtracted these DSMs from the Bare Earth DEMs to create a difference image, which ideally should represent only buildings. Unfortunately, many trees were included in this “buildings” layer, due possibly to the sparse canopy that is characteristic of trees found in southwestern forests and possibly to the presence of fairly recent burn scars that include a number of standing dead trees and snags. In an attempt to remove the clutter of false positives due to trees, we developed a Normalized Difference Vegetation Index (NDVI) from the NAIP imagery acquired over the area in the same year. The NDVI is an image-processing technique that uses the reflective information found in the red (Red) and near-infrared (NIR) wavelengths to enhance the “green” vegetative response over other, non-vegetated surface features (Eq. 1). NDVI = (NIR−Red)/(NIR+Red) [Eq. 1]. This provides a floating-point image of values from -1 to 1, with numbers above 0 representing increasing vegetative cover. We further modified the NDVI equation to create an 8-bit image (Eq. 2). NDVImod = (NDVI+1)*100 [Eq. 2]. This 8-bit image had all positive integer values, where values above 100 indicated increasing vegetative cover. We used the generated NDVI image, in particular values above 109, to mask out many of the false anomalies. In addition, all heights less than 6 feet were masked out, as this was considered a minimum height for most buildings. We added 1 to values in the resulting image so that all values, even the zeroes, would be counted. Then values were clumped to produce an image of individually coded raster polygons. We eliminated all clusters smaller than 32 square meters (345 square feet) from the clumped image, ran a 3x3 majority filter to remove relict edges, and ran a 3x3 morphological close filter to remove holes in the raster polygons. We completed the raster processing in ERDAS IMAGINE and then converted the data set to a polygon layer in ESRI ArcGIS, as is and without using the ‘simplify polygon’ option. This was cleaned up further using the simplify buildings module with a minimum spacing of 2 meters. Once this was completed, the polygon layer was edited using the NAIP imagery and DSM Shaded Relief imagery as a background by a heads-up digitizing at a 1:3,000 scale (the approximate base resolution of the LiDAR data). The building/structure layer contained more than 44,612 identified structures.

The LAS data set was originally classified according to 4 classes (ground, water, bridge overpass, and noise), with the rest of the data being unclassified. That left some classes to be derived and classified, of which one—the building/ structure class—was considered necessary for this project. In theory, deriving a building/structure layer is relatively straightforward: the building reflectance response should be unclassified, single-reflectance response points, whereas the vegetation, also unclassified, should yield a multiple-reflectance response as the beam bounces back through the canopy. Following this idea, we created a Digital Surface Model (DSM) from the single-response, unclassified LAS point cloud. We then subtracted these DSMs from the Bare Earth DEMs to create a difference image, which ideally should represent only buildings. Unfortunately, many trees were included in this “buildings” layer, due possibly to the sparse canopy that is characteristic of trees found in southwestern forests and possibly to the presence of fairly recent burn scars that include a number of standing dead trees and snags. In an attempt to remove the clutter of false positives due to trees, we developed a Normalized Difference Vegetation Index (NDVI) from the NAIP imagery acquired over the area in the same year. The NDVI is an image-processing technique that uses the reflective information found in the red (Red) and near-infrared (NIR) wavelengths to enhance the “green” vegetative response over other, non-vegetated surface features (Eq. 1). NDVI = (NIR−Red)/(NIR+Red) [Eq. 1]. This provides a floating-point image of values from -1 to 1, with numbers above 0 representing increasing vegetative cover. We further modified the NDVI equation to create an 8-bit image (Eq. 2). NDVImod = (NDVI+1)*100 [Eq. 2]. This 8-bit image had all positive integer values, where values above 100 indicated increasing vegetative cover. We used the generated NDVI image, in particular values above 109, to mask out many of the false anomalies. In addition, all heights less than 6 feet were masked out, as this was considered a minimum height for most buildings. We added 1 to values in the resulting image so that all values, even the zeroes, would be counted. Then values were clumped to produce an image of individually coded raster polygons. We eliminated all clusters smaller than 32 square meters (345 square feet) from the clumped image, ran a 3x3 majority filter to remove relict edges, and ran a 3x3 morphological close filter to remove holes in the raster polygons. We completed the raster processing in ERDAS IMAGINE and then converted the data set to a polygon layer in ESRI ArcGIS, as is and without using the ‘simplify polygon’ option. This was cleaned up further using the simplify buildings module with a minimum spacing of 2 meters. Once this was completed, the polygon layer was edited using the NAIP imagery and DSM Shaded Relief imagery as a background by a heads-up digitizing at a 1:3,000 scale (the approximate base resolution of the LiDAR data). The building/structure layer contained more than 44,612 identified structures.

This project maps the conversion from mid-20th century (1946-71) flood and sprinkler irrigation to sprinkler irrigation (center-pivot and other sprinkler), and other land types (fallow, crop, and flood remaining flood) in Montana, by 2019.

Over the past 50 years, many producers in Montana have made changes to their irrigation practice and infrastructure in an effort to increase irrigation efficiency, defined as the ratio of water consumed by crops to water diverted or pumped (consumed water ÷ diverted water). Changes in the method of irrigation, especially conversion from flood to sprinkler irrigation, may have significant on-farm benefits such as reduced labor and increased production. Conversion can have both beneficial and adverse impacts on streamflow and aquatic ecosystems depending on local site-specific hydrogeologic conditions and how irrigation water is managed. As part of the Montana Water Center’s effort to better understand the effects of increased irrigation efficiency in Montana (Lonsdale et al. 2020), historic conversion from flood to sprinkler irrigation was analyzed using available agricultural statistics, maps from state and federal sources, and an independent Geographic Information Systems (GIS) analysis.

The first Resource in this HydroShare Collection, "Conversion from Flood to Sprinkler Irrigation in Montana between Mid-20th Century and 2019", presents the GIS analysis and maps the amount and spatial distribution of conversion from flood to sprinkler irrigation, between the mid-20th century and 2019. Historic mid-20th century irrigation was mapped in detail from 1943-1965 by the State Engineer’s Office and from 1966-1971 by the Montana Water Resources Board—the predecessor of the Montana Department of Natural Resources and Conservation (DNRC). A scanned and georeferenced version of the Water Resources Surveys (WRS) was compared with maps of contemporary irrigated land (Montana Department of Revenue’s 2019 Final Land Unit Classification—DORFLU2019) to estimate the area of land converted from flood to sprinkler irrigation. Prior to GIS analysis, both datasets were edited to ensure valid comparison between irrigated field mapping conducted at the two points in time. To estimate the amount of conversion from flood to sprinkler irrigation, and other uses, the GIS layers (WRS flood and sprinkler 1946-1971 and DOR-FLU 2019) were overlain in ArcGIS; then the clipping erase functions were used to select the WRS flood and sprinkler parcels that were shown as sprinkler irrigated in 2019. Additional conversion classes were also mapped that represent the changes from WRS flood and sprinkler to cropland, hayland and fallow, and WRS sprinkler- remaining- sprinkler and flood remaining flood. Details of the analysis are provided in Appendix C. of the main report and which is located within HydroShare Resource: https://www.hydroshare.org/resource/15392cb3617b4519af6ae8972f603502/data/contents/Appendix_C._Methods_and_data_for_GIS_mapping_of_conversion_from_flood_to_sprinkler_irrigation.pdf

The second Resource in this Collection," Uncertainty analysis of irrigation conversion polygon areas", provides files used in the uncertainty analysis of polygon areas resulting from overlaying/clipping/erase GIS operations that map the irrigation system conversions from mid-20th century to 2019.There are several sources of uncertainty in the conversion mapping results. The first is that the analysis only accounts for changes that occurred between the WRS 1946-71 and DORFLU2019; it is possible that additional flood irrigation developed between the two points in time may have also been converted to sprinkler. Another source of uncertainty is due to GIS processing and overlay/clip/erase functions that create “sliver” polygons of apparent change due to misalignment of the WRS 1946-71 and DORFLU2019 layers (i.e., co-registration error). This was evaluated using the spatially distributed probabilistic (SDP) method of Leonard and others (2020) and found to be small—generally less than one percent of the area of conversion polygons. Digitizing error was evaluated indirectly and found to be about ±12 percent of the reported area values. The values sum in quadrature to provide an overall estimate of error in polygon area of 12%. Conversion from flood to sprinkler polygon areas presented in the main report, and associated error statistics, apply to the whole dataset at the statewide scale. For use at the basin scale (for example, HUC4 Upper Yellowstone, the end user should review the uncertainty estimate for specific conversion polygons and refine if necessary. Please see Appendix D. Uncertainty analysis.pdf for details of the analysis. All citations are included in the References.txt file and in the main report.

Sieve filters are lacking in ArcGIS. Therefore, I developed a simple model that will perform a sieve filter based on the Jeffrey Evans' comments in the following forum:http://gis.stackexchange.com/questions/91609/where-can-i-use-a-sieve-filterThe basic idea of the sieve filter is that you can remove small "specks" or "polygons" from a categorical raster replacing them with their neighoring values. Unlike a focal majority operation which generalizes your data the sieve filter preserves the basic shapes of the "polygons". the only parameter required is the minimum number of cells in "polygon" (region group in raster terminology).Alternatively there may be some instances where you wish to generalize your data using a focal majority operation. However, the focal majority will return No Data in the case of a tie. Usually these are single cells or very small clusters of cells. The focal sieve tool allows you to remove these "specks" from your data. Hence, you get the generalization of the focal majority but use the sieve operation to clean up the specks. The focal sieve tool requires both a neighborhood size like a typical focal statistic but also a minimum number of cells.

This project provides files used in the uncertainty analysis of polygon areas resulting from overlaying/clipping/erasing GIS operations that map the conversion from mid-21st century flood (and sprinkler irrigation) to sprinkler irrigation (center-pivot and other sprinkler), and other land types (fallow, crop, and flood remaining flood) in Montana, by 2019.

This project is part of a larger effort that maps the conversion from mid-20th century flood (and sprinkler irrigation) to sprinkler irrigation (center-pivot and other sprinkler), and other land types (fallow, crop, and flood remaining flood) in Montana, by 2019. This file contains results of mapping the conversion from mid-20th century flood (and sprinkler irrigation) to sprinkler irrigation (center-pivot and other sprinkler), and other land types (to cropland—C, hayland--H, fallow –FA, and sprinkler remaining sprinkler) in Montana, by 2019. As part of the Montana Water Center’s effort to better understand the effects of increased irrigation efficiency in Montana (Lonsdale et al. 2020), historic conversion from flood to sprinkler irrigation was analyzed using available agricultural statistics, maps from state and federal sources, and an independent Geographic Information Systems (GIS) analysis. This project presents the GIS analysis and maps the amount and spatial distribution of conversion from flood to sprinkler irrigation, between the mid-20th century and 2019. Historic mid-20th century irrigation was mapped in detail from 1943-1965 by the State Engineer’s Office and from 1966-1971 by the Montana Water Resources Board—the predecessor of the Montana Department of Natural Resources and Conservation (DNRC). A scanned and georeferenced version of the Water Resources Surveys (WRS) was compared with maps of contemporary irrigated land (Montana Department of Revenue’s 2019 Final Land Unit Classification—DORFLU2019) to estimate the area of land converted from flood to sprinkler irrigation. Prior to GIS analysis, both datasets were edited to ensure valid comparison between irrigated field mapping conducted at the two points in time. To estimate the amount of conversion from flood to sprinkler irrigation, and other uses, the GIS layers (WRS flood and sprinkler 1946-1971 and DOR-FLU 2019) were overlain in ArcGIS; then the clipping erase functions were used to select the WRS flood and sprinkler parcels that were shown as sprinkler irrigated in 2019. Additional conversion classes were also mapped that represent the changes from WRS flood and sprinkler to cropland, hayland and fallow, and WRS sprinkler remaining sprinkler.

There are several sources of uncertainty in the conversion mapping results. The first is that the analysis only accounts for changes that occurred between the WRS 1946-71 and DORFLU2019; it is possible that additional flood irrigation developed between the two points in time may have also been converted to sprinkler. Lacking statewide mapping of irrigation for intervening years, it was not possible to evaluate this. In addition, WRS were not available for several counties, and the amount of conversion could not be estimated. Although several of the counties are in eastern Montana and have little irrigation, Beaverhead and Yellowstone Counties have significant irrigation and could have significant conversion--therefore the statewide estimate of conversion should be considered a minimum value.

Another source of uncertainty is due to GIS processing and overlay/clip/erase functions that create “sliver” polygons of apparent change due to misalignment of the WRS 1946-71 and DORFLU2019 layers (i.e. co-registration error). This was evaluated using the spatially distributed probabilistic (SDP) method of Leonard and others (2020) and found to be small—generally less than one percent of the area of conversion polygons. Digitizing error was evaluated indirectly and found to be about ±12 percent of the reported area values. The values sum in quadrature to provide an overall estimate of error in polygon area of 12%.

Conversion from flood to sprinkler polygon areas presented in the report, and associated error statistics, apply to the whole dataset at the statewide scale. For use at the basin scale (for example, HUC4 Upper Yellowstone, the end user should review the uncertainty estimate for specific conversion polygons and refine if necessary.

Please see Appendix D_Uncertainty analysis.pdf for details of the analysis: https://www.hydroshare.org/resource/51957cd254b54891ba2e239428bd132d/data/contents/Appendix_D_Uncertainty_Analysis.pdf

This shapefile represents proposed management categories (Core, Priority, General, and Non-Habitat) derived from the intersection of habitat suitability categories and lek space use. Habitat suitability categories were derived from a composite, continuous surface of sage-grouse habitat suitability index (HSI) values for Nevada and northeastern California formed from the multiplicative product of the spring, summer, and winter HSI surfaces. Summary of steps to create Management Categories: HABITAT SUITABILITY INDEX: The HSI was derived from a generalized linear mixed model (specified by binomial distribution and created using ArcGIS 10.2.2) that contrasted data from multiple environmental factors at used sites (telemetry locations) and available sites (random locations). Predictor variables for the model represented vegetation communities at multiple spatial scales, water resources, habitat configuration, urbanization, roads, elevation, ruggedness, and slope. Vegetation data was derived from various mapping products, which included NV SynthMap (Petersen 2008, SageStitch (Comer et al. 2002, LANDFIRE (Landfire 2010), and the CA Fire and Resource Assessment Program (CFRAP 2006). The analysis was updated to include high resolution percent cover within 30 x 30 m pixels for Sagebrush, non-sagebrush, herbaceous vegetation, and bare ground (C. Homer, unpublished; based on the methods of Homer et al. 2014, Xian et al. 2015 ) and conifer (primarily pinyon-juniper, P. Coates, unpublished). The pool of telemetry data included the same data from 1998 - 2013 used by Coates et al. (2014) as well as additional telemetry location data from field sites in 2014. The dataset was then split according to calendar date into three seasons. Spring included telemetry locations (n = 14,058) from mid-March to June; summer included locations (n = 11,743) from July to mid-October; winter included locations (n = 4862) from November to March. All age and sex classes of marked grouse were used in the analysis. Sufficient data (i.e., a minimum of 100 locations from at least 20 marked Sage-grouse) for modeling existed in 10 subregions for spring and summer, and seven subregions in winter, using all age and sex classes of marked grouse. It is important to note that although this map is composed of HSI values derived from the seasonal data, it does not explicitly represent habitat suitability for reproductive females (i.e., nesting and with broods). Insufficient data were available to allow for estimation of this habitat type for all seasons throughout the study area extent. A Resource Selection Function (RSF) was calculated for each subregion using R software (v 3.13) and season using generalized linear models to derive model-averaged parameter estimates for each covariate across a set of additive models. For each season, subregional RSFs were transformed into Habitat Suitability Indices, and averaged together to produce an overall statewide HSI whereby a relative probability of occurrence was calculated for each raster cell. The three seasonal HSI rasters were then multiplied to create a composite annual HSI. In order to account for discrepancies in HSI values caused by varying ecoregions within Nevada, the HSI was divided into north and south extents using a slightly modified flood region boundary (Mason 1999) that was designed to represent respective mesic and xeric regions of the state. North and south HSI rasters were each relativized according to their maximum value to rescale between zero and one, then mosaicked once more into a state-wide extent. HABITAT CATEGORIZATION: Using the same ecoregion boundaries described above, the habitat classification dataset (an independent data set comprising 10% of the total telemetry location sample) was split into locations falling within respective north and south regions. HSI values from the composite and relativized statewide HSI surface were then extracted to each classification dataset location within the north and south region. The distribution of these values were used to identify class break values corresponding to 0.5 (high), 1.0 (moderate), and 1.5 (low) standard deviations (SD) from the mean HSI. These class breaks were used to classify the HSI surface into four discrete categories of habitat suitability: High, Moderate, Low, and Non-Habitat. In terms of percentiles, High habitat comprised greater than 30.9 % of the HSI values, Moderate comprised 15 – 30.9%, Low comprised 6.7 – 15%, and Non-Habitat comprised less than 6.7%.The classified north and south regions were then clipped by the boundary layer and mosaicked to create a statewide categorical surface for habitat selection. Each habitat suitability category was converted to a vector output where gaps within polygons less than 1.2 million square meters were eliminated, polygons within 500 meters of each other were connected to create corridors and polygons less than 1.2 million square meters in one category were incorporated to the adjacent category. The final step was to mask major roads that were buffered by 50m (Census, 2014), lakes (Peterson, 2008) and urban areas, and place those masked areas into the non-habitat category. The existing urban layer (Census 2010) was not sufficient for our needs because it excluded towns with a population lower than 1,500. Hence, we masked smaller towns (populations of 100 to 1500) and development with Census Block polygons (Census 2015) that had at least 50% urban development within their boundaries when viewed with reference imagery (ArcGIS World Imagery Service Layer). SPACE USE INDEX CALCULATION: Updated lek coordinates and associated trend count data were obtained from the 2015 Nevada Sage-grouse Lek Database compiled by the Nevada Department of Wildlife (NDOW, S. Espinosa, 9/20/2015). Leks count data from the California side of the Buffalo-Skedaddle and Modoc PMU's that contributed to the overall space-use model were obtained from the Western Association of Fish and Wildlife Agencies (WAFWA), and included count data up to 2014. We used NDOW data for border leks (n = 12), and WAFWA data for those fully in California and not consistently surveyed by NDOW. We queried the database for leks with a ‘LEKSTATUS’ field classified as ‘Active’ or ‘Pending’. Active leks comprised leks with breeding males observed within the last 5 years (through the 2014 breeding season). Pending leks comprised leks without consistent breeding activity during the prior 3 - 5 surveys or had not been surveyed during the past 5 years; these leks typically trended towards ‘inactive’, or newly discovered leks with at least 2 males. A sage-grouse management area (SGMA) was calculated by buffering Population Management Units developed by NDOW by 10km. This included leks from the Buffalo-Skedaddle PMU that straddles the northeastern California – Nevada border, but excluded leks for the Bi-State Distinct Population Segment. The 5-year average (2011 - 2015) for the number of male grouse (or NDOW classified 'pseudo-males' if males were not clearly identified but likely) attending each lek was calculated. Compared to the 2014 input lek dataset, 36 leks switched from pending to inactive, and 74 new leks were added for 2015 (which included pending ‘new’ leks with one year of counts. A total of 917 leks were used for space use index calculation in 2015 compared to 878 leks in 2014. Utilization distributions describing the probability of lek occurrence were calculated using fixed kernel density estimators (Silverman 1986) with bandwidths estimated from likelihood based cross-validation (CVh) (Horne and Garton 2006). UDs were weighted by the 5-year average (2011 - 2015) for the number of males grouse (or unknown gender if males were not identified) attending leks. UDs and bandwidths were calculated using Geospatial Modelling Environment (Beyer 2012) and the ‘ks’ package (Duong 2012) in Program R. Grid cell size was 30m. The resulting raster was re-scaled between zero and one by dividing by the maximum pixel value. The non-linear effect of distance to lek on the probability of grouse spatial use was estimated using the inverse of the utilization distribution curves described by Coates et al. (2013), where essentially the highest probability of grouse spatial use occurs near leks and then declines precipitously as a non-linear function. Euclidean distance was first calculated in ArcGIS, reclassified into 30-m distance bins (ranging from 0 - 30,000m), and bins reclassified according to the non-linear curve in Coates et al. (2013). The resulting raster was re-scaled between zero and one by dividing by the maximum cell value. A Spatial Use Index (SUI) was calculated by taking the average of the lek utilization distribution and non-linear distance-to-lek rasters in ArcGIS, and re-scaled between zero and one by dividing by the maximum cell value. The volume of the SUI at cumulative at specific isopleths was extracted in Geospatial Modelling Environment (Beyer 2012) with the command ‘isopleth’. Interior polygons (i.e., donuts’ > 1.2 km2) representing no probability of use within a larger polygon of use were erased from each isopleth. The 85% isopleth, which provided greater spatial connectivity and consistency with previously used agency standards (e.g., Doherty et al. 2010), was ultimately recommended by the Sagebrush Ecosystem Technical Team. The 85% SUI isopleth was clipped by the Nevada state boundary. MANAGEMENT CATEGORIES: The process for category determination was directed by the Nevada Sagebrush Ecosystem Technical team. Sage-grouse habitat was categorized into 4 classes: High, Moderate, Low, and Non-Habitat as described above, and intersected with the space use index to form the following management categories . 1) Core habitat: Defined as the intersection between all suitable habitat (High, Moderate, and Low) and the 85% Space Use Index (SUI). 2) Priority habitat: Defined as all high quality habitat

Terms of Use:

Data Limitations Disclaimer

The MassDEP Estimated Sewer System Service Area Boundaries datalayer may not be complete, may contain errors, omissions, and other inaccuracies, and the data are subject to change. The user’s use of and/or reliance on the information contained in the Document (e.g. data) shall be at the user’s own risk and expense. MassDEP disclaims any responsibility for any loss or harm that may result to the user of this data or to any other person due to the user’s use of the Document.

All sewer service area delineations are estimates for broad planning purposes and should only be used as a guide. The data is not appropriate for site-specific or parcel-specific analysis. Not all properties within a sewer service area are necessarily served by the system, and some properties outside the mapped service areas could be served by the wastewater utility – please contact the relevant wastewater system. Not all service areas have been confirmed by the sewer system authorities.

This is an ongoing data development project. Attempts have been made to contact all sewer/wastewater systems, but not all have responded with information on their service area. MassDEP will continue to collect and verify this information. Some sewer service areas included in this datalayer have not been verified by the POTWs, privately-owned treatment works, GWDPs, or the municipality involved, but since many of those areas are based on information published online by the municipality, the utility, or in a publicly available report, they are included in the estimated sewer service area datalayer.

Please use the following citation to reference these data

MassDEP. Water Utility Resilience Program. 2025. Publicly-Owned Treatment Work and Non-Publicly-Owned Sewer Service Areas (PubV2024_12).

We want to learn about the data uses. If you use this dataset, please notify staff in the Water Resilience program (WURP@mass.gov).

Layers and Tables:

The MassDEP Estimated Sewer System Service Area data layer comprises two feature classes and a supporting table:

Publicly-Owned Treatment Works (POTW) Sewer Service Areas feature class SEWER_SERVICE_AREA_POTW_POLY includes polygon features for sewer service areas systems operated by publicly owned treatment works (POTWs)Non-Publicly Owned Treatment Works (NON-POTW) Sewer Service Areas feature class SEWER_SERVICE_AREA_NONPOTW_POLY includes polygon features for sewer service areas for operated by NON publicly owned treatment works (NON-POTWs)The Sewer Service Areas Unlocated Sites table SEWER_SERVICE_AREA_USL contains a list of known, unmapped active POTW and NON-POTW services areas at the time of publication.

ProductionData Universe

Effluent wastewater treatment plants in Massachusetts are permitted either through the Environmental Protection Agency’s (EPA) National Pollutant Discharge Elimination System (NPDES) surface water discharge permit program or the MassDEP Groundwater Discharge Permit Program. The WURP has delineated active service areas served by publicly and privately-owned effluent treatment works with a NPDES permit or a groundwater discharge permit.

National Pollutant Discharge Elimination System (NPDES) Permits

In the Commonwealth of Massachusetts, the EPA is the permitting authority for regulating point sources that discharge pollutants to surface waters. NPDES permits regulate wastewater discharge by limiting the quantities of pollutants to be discharged and imposing monitoring requirements and other conditions. NPDES permits are typically co-issued by EPA and the MassDEP. The limits and/or requirements in the permit ensure compliance with the Massachusetts Surface Water Quality Standards and Federal Regulations to protect public health and the aquatic environment. Areas served by effluent treatment plants with an active NPDES permit are included in this datalayer based on a master list developed by MassDEP using information sourced from the EPA’s Integrated Compliance Information System (ICIS).

Groundwater Discharge (GWD) Permits

In addition to surface water permittees, the WURP has delineated all active systems served by publicly and privately owned effluent treatment works with groundwater discharge (GWD) permits, and some inactive service areas. Groundwater discharge permits are required for systems discharging over 10,000 GPD sanitary wastewater – these include effluent treatment systems for public, district, or privately owned effluent treatment systems. Areas served by an effluent treatment plant with an active GWD permit are included in this datalayer based on lists received from MassDEP Wastewater staff.

Creation of Unique IDs for Each Service Area

The Sewer Service Area datalayer contains polygons that represent the service area of a particular wastewater system within a particular municipality. Every discharge permittee is assigned a unique NPDES permit number by EPA or a unique GWD permit identifier by MassDEP. MassDEP WURP creates a unique Sewer_ID for each service area by combining the municipal name of the municipality served with the permit number (NPDES or GWD) ascribed to the sewer that is serving that area. Some municipalities contain more than one sewer system, but each sewer system has a unique Sewer_ID. Occasionally the area served by a sewer system will overlap another town by a small amount – these small areas are generally not given a unique ID. The Estimated sewer Service Area datalayer, therefore, contains polygons with a unique Sewer_ID for each sewer service area. In addition, some municipalities will have multiple service areas being served by the same treatment plant – the Sewer_ID for these will contain additional identification, such as the name of the system, to uniquely identify each system.

Classifying System Service Areas

WURP staff reviewed the service areas for each system and, based on OWNER_TYPE, classified as either a publicly-owned treatment work (POTW) or a NON-POTW (see FAC_TYPE field). Each service area is further classified based on the population type served (see SECTOR field).

Methodologies and Data Sources

Several methodologies were used to create service area boundaries using various sources, including data received from the sewer system in response to requests for information from the MassDEP WURP project, information on file at MassDEP, and service area maps found online at municipal and wastewater system websites. When MassDEP received sewer line data rather than generalized areas, 300-foot buffers were created around the sewer lines to denote service areas and then edited to incorporate generalizations. Some municipalities submitted parcel data or address information to be used in delineating service areas. Many of the smaller GWD permitted sewer service areas were delineated using parcel boundaries related to the address on file.

Verification Process

Small-scale pdf file maps with roads and other infrastructure were sent to systems for corrections or verifications. If the system were small, such as a condominium complex or residential school, the relevant parcels were often used as the basis for the delineated service area. In towns where 97% or more of their population is served by the wastewater system and no other service area delineation was available, the town boundary was used as the service area boundary. Some towns responded to the request for information or verification of service areas by stating that the town boundary should be used since all, or nearly all, of the municipality is served by one wastewater system.

To ensure active systems are mapped, WURP staff developed two work flows. For NPDES-permitted systems, WURP staff reviewed available information on EPA’s ICIS database and created a master list of these systems. Staff will work to routinely update this master list by reviewing the ICIS database for new NPDES permits. The master list will serve as a method for identifying active systems, inactive systems, and unmapped systems. For GWD permittees, GIS staff established a direct linkage to the groundwater database, which allows for populating information into data fields and identifying active systems, inactive systems, and unmapped systems.

All unmapped systems are added to the Sewer Service Area Unlocated List (SEWER_SERVICE_AREAS_USL) for future mapping. Some service areas have not been mapped but their general location is represented by a small circle which serves as a placeholder - the location of these circles are estimated based on the general location of the treatment plant or the general estimated location of the service area - these do not represent the actual service area.

Percent Served Statistics The attribute table for the POTW sewer service areas (SEWER_SERVICE_AREA_POTW_POLY) has several fields relating to the percent of the town served by the particular system and one field describing the percent of town served by all systems in the town. The field ‘Percent AREA Served by System’ is strictly a calculation done dividing the area of the system by the total area of the town and multiplying by 100. In contrast, the field ‘Percent Served by System’, is not based on a particular calculation or source – it is an estimate based on various sources – these estimates are for planning purposes only. Data includes information from municipal websites and associated plans, the 1990 Municipal Priority list from CMR 310 14.17, the 2004 Pioneer Institute for Public Policy Research “percent on sewer” document, information contained on NPDES Permits and MassDEP Wastewater program staff input. Not all POTW systems have percent served statistics. Percentage may reflect the percentage of parcels served, the percent of area within a community served or the population served and should not be used for legal boundary definition or regulatory interpretation.

Sources of information for estimated wastewater service areas:

EEOA Water Assets

This shapefile represents habitat suitability categories (High, Moderate, Low, and Non-Habitat) derived from a composite, continuous surface of sage-grouse habitat suitability index (HSI) values for Nevada and northeastern California during the winter season, and is a surrogate for habitat conditions during periods of cold and snow. Summary of steps to create Habitat Categories: HABITAT SUITABILITY INDEX: The HSI was derived from a generalized linear mixed model (specified by binomial distribution and created using ArcGIS 10.2.2) that contrasted data from multiple environmental factors at used sites (telemetry locations) and available sites (random locations). Predictor variables for the model represented vegetation communities at multiple spatial scales, water resources, habitat configuration, urbanization, roads, elevation, ruggedness, and slope. Vegetation data was derived from various mapping products, which included NV SynthMap (Petersen 2008, SageStitch (Comer et al. 2002, LANDFIRE (Landfire 2010), and the CA Fire and Resource Assessment Program (CFRAP 2006). The analysis was updated to include high resolution percent cover within 30 x 30 m pixels for Sagebrush, non-sagebrush, herbaceous vegetation, and bare ground (C. Homer, unpublished; based on the methods of Homer et al. 2014, Xian et al. 2015 ) and conifer (primarily pinyon-juniper, P. Coates, unpublished). The pool of telemetry data included the same data from 1998 - 2013 used by Coates et al. (2014); additional telemetry location data from field sites in 2014 were added to the dataset. The dataset was then split according calendar date into three seasons (spring, summer, winter). Winter included telemetry locations (n = 4862) from November to March. All age and sex classes of marked grouse were used in the analysis. Sufficient data (i.e., a minimum of 100 locations from at least 20 marked Sage-grouse) for modeling existed in 10 subregions for spring and summer, and seven subregions in winter, using all age and sex classes of marked grouse. It is important to note that although this map is composed of HSI values derived from the seasonal data, it does not explicitly represent habitat suitability for reproductive females (i.e., nesting and with broods). Insufficient data were available to allow for estimation of this habitat type for all seasons throughout the study area extent. A Resource Selection Function (RSF) was calculated for each subregion using R software (v 3.13) and using generalized linear models to derive model-averaged parameter estimates for each covariate across a set of additive models. Subregional RSFs were transformed into Habitat Suitability Indices, and averaged together to produce an overall statewide HSI whereby a relative probability of occurrence was calculated for each raster cell during the spring season. In order to account for discrepancies in HSI values caused by varying ecoregions within Nevada, the HSI was divided into north and south extents using a slightly modified flood region boundary (Mason 1999) that was designed to represent respective mesic and xeric regions of the state. North and south HSI rasters were each relativized according to their maximum value to rescale between zero and one, then mosaicked once more into a state-wide extent. HABITAT CATEGORIZATION: Using the same ecoregion boundaries described above, the habitat classification dataset (an independent data set comprising 10% of the total telemetry location sample) was split into locations falling within respective north and south regions. HSI values from the composite and relativized statewide HSI surface were then extracted to each classification dataset location within the north and south region. The distribution of these values were used to identify class break values corresponding to 0.5 (high), 1.0 (moderate), and 1.5 (low) standard deviations (SD) from the mean HSI. These class breaks were used to classify the HSI surface into four discrete categories of habitat suitability: High, Moderate, Low, and Non-Habitat. In terms of percentiles, High habitat comprised greater than 30.9 % of the HSI values, Moderate comprised 15 – 30.9%, Low comprised 6.7 – 15%, and Non-Habitat comprised less than 6.7%.The classified north and south regions were then clipped by the boundary layer and mosaicked to create a statewide categorical surface for habitat selection . Each habitat suitability category was converted to a vector output where gaps within polygons less than 1.2 million square meters were eliminated, polygons within 500 meters of each other were connected to create corridors and polygons less than 1.2 million square meters in one category were incorporated to the adjacent category. The final step was to mask major roads that were buffered by 50m (Census, 2014), lakes (Peterson, 2008) and urban areas, and place those masked areas into the non-habitat category. The existing urban layer (Census 2010) was not sufficient for our needs because it excluded towns with a population lower than 1,500. Hence, we masked smaller towns (populations of 100 to 1500) and development with Census Block polygons (Census 2015) that had at least 50% urban development within their boundaries when viewed with reference imagery (ArcGIS World Imagery Service Layer). REFERENCES: California Forest and Resource Assessment Program (CFRAP). 2006. Statewide Land Use / Land Cover Mosaic. [Geospatial data.] California Department of Forestry and Fire Protection, http://frap.cdf.ca.gov/data/frapgisdata-sw-rangeland-assessment_data.php Census 2010. TIGER/Line Shapefiles. Urban Areas [Geospatial data.] U.S. Census Bureau, Washington D.C., https://www.census.gov/geo/maps-data/data/tiger-line.html Census 2014. TIGER/Line Shapefiles. Roads [Geospatial data.] U.S. Census Bureau, Washington D.C., https://www.census.gov/geo/maps-data/data/tiger-line.html Census 2015. TIGER/Line Shapefiles. Blocks [Geospatial data.] U.S. Census Bureau, Washington D.C., https://www.census.gov/geo/maps-data/data/tiger-line.html Coates, P.S., Casazza, M.L., Brussee, B.E., Ricca, M.A., Gustafson, K.B., Overton, C.T., Sanchez-Chopitea, E., Kroger, T., Mauch, K., Niell, L., Howe, K., Gardner, S., Espinosa, S., and Delehanty, D.J. 2014, Spatially explicit modeling of greater sage-grouse (Centrocercus urophasianus) habitat in Nevada and northeastern California—A decision-support tool for management: U.S. Geological Survey Open-File Report 2014-1163, 83 p., http://dx.doi.org/10.3133/ofr20141163. ISSN 2331-1258 (online) Comer, P., Kagen, J., Heiner, M., and Tobalske, C. 2002. Current distribution of sagebrush and associated vegetation in the western United States (excluding NM). [Geospatial data.] Interagency Sagebrush Working Group, http://sagemap.wr.usgs.gov Homer, C.G., Aldridge, C.L., Meyer, D.K., and Schell, S.J. 2014. Multi-Scale Remote Sensing Sagebrush Characterization with Regression Trees over Wyoming, USA; Laying a Foundation for Monitoring. International Journal of Applied Earth Observation and Geoinformation 14, Elsevier, US. LANDFIRE. 2010. 1.2.0 Existing Vegetation Type Layer. [Geospatial data.] U.S. Department of the Interior, Geological Survey, http://landfire.cr.usgs.gov/viewer/ Mason, R.R. 1999. The National Flood-Frequency Program—Methods For Estimating Flood Magnitude And Frequency In Rural Areas In Nevada U.S. Geological Survey Fact Sheet 123-98 September, 1999, Prepared by Robert R. Mason, Jr. and Kernell G. Ries III, of the U.S. Geological Survey; and Jeffrey N. King and Wilbert O. Thomas, Jr., of Michael Baker, Jr., Inc. http://pubs.usgs.gov/fs/fs-123-98/ Peterson, E. B. 2008. A Synthesis of Vegetation Maps for Nevada (Initiating a 'Living' Vegetation Map). Documentation and geospatial data, Nevada Natural Heritage Program, Carson City, Nevada, http://www.heritage.nv.gov/gis Xian, G., Homer, C., Rigge, M., Shi, H., and Meyer, D. 2015. Characterization of shrubland ecosystem components as continuous fields in the northwest United States. Remote Sensing of Environment 168:286-300. NOTE: This file does not include habitat areas for the Bi-State management area and the spatial extent is modified in comparison to Coates et al. 2014

Feature layer of potential vernal pools as topographic basins (sinks) where surface water could collect. These polygons were modeled from a lidar 1-foot pixel DEM within the mapped areas of mounded topography and indicate potential for inundating vernal pool habitat, but only field surveys can confirm the presence of that habitat or associated species. Pool basins meet minimum depth and area thresholds (0.5 inch and 50 ft²) and were subjectively filtered to eliminate depressions of a size, depth, or condition inconsistent with the potential presence of vernal pool biota, including very small and/or shallow depressions, and impoundments or excavations such as quarries, stock ponds, lakes, etc. Attributes for each pool polygon include maximum and mean depth, basin volume, and the contributing watershed catchment area.

The models delineating potential vernal pools (Pools) were generated by filling depressions in the DEM using the ArcGIS Spatial Analyst FILL() tool, then subtracting the unfilled surface from the filled surface using raster arithmetic to derive a depression Depth raster on a cell by cell basis. The Depth raster was thresholded at 1/2" minimum depth and 50 sq ft minimum surface area, and converted to vector polygons. This is a combined feature class from 158 individual feature classes used to delineate pool boundaries within each of the analysis area tiles.

All basin polygons were then manually reviewed to identify and eliminate all drainage ditches, irrigation canals, stock ponds, lakes, quarries, artificial impoundments and other manmade depressions and water features not qualifying as potential vernal pools. We retained disturbed vernal pools, or semi-anthropogenic pools with intact apparently duripan substrate potentially supporting vernal pool biota. This process was subjective to a degree, but used orthophoto/historic orthophoto overlays to assess disturbance and vegetation patterns.

All filtered pool polygons were processed using spatial and zonal overlays with the depth, slope and flow accumulation raster models to populate individual pool feature attributes for depth, volume, area, and contributing watershed. Processing was accomplished on a tile by tile basis using Python scripting in the ArcGIS Jupyter Notebook. All pool polygons were assigned a feature ID attribute corresponding with the associated Mounded Landform habitat polygons so that combined pool statistics for each landform polygon could be computed.

Areas managed as WILDERNESSwithin Glacier National Park. This mapping was compiled in 2014, implementing NPS Director's Order 41 (2013), which provides guidelines to NPS units for delineating wilderness boundaries. The two main criteria provided by DO-41 are that boundaries 1) must be easily identifiable on the ground, and 2) standard boundary setbacks from roads, paved or unpaved, should be 100-feet either side of centerline. Included in this mapping are areas EXCLUDED from wilderness, which generally fall within 100-feet of road centerline or are part of the park's Visitor Service Zone (GMP, 1999). Additional areas categorized as 'Excluded from wilderness' include lands designated as part of the Visitor Service Zone (VSZ), documented in the GLAC Commercial Serices Plan (2004). Developed area footprints were mapped and then buffered 300-feet. Utility corridors and point locations were mapped and buffered 25-feet. Also, large lakes with existing commercial services were included in the VSZ and thus were categorized as Excluded.POTENTIAL WILDERNESS AREAS (PWA) are the 3rd map class; these lands are currently in private ownership, providing access to private ownership, or are small fragmented areas (i.e. not easily identified on the ground and difficult to manage as wilderness due to size and surrounding land uses) between areas excluded from wilderness (e.g. utility corridors and lands between utility corridors and other excluded areas).Chronology of edits:Begin edits 11/8/13 to implement DO-41. Update layer March 4, 2014 - create version 3 with the following edits - based on 3/3/14 meeting with GLAC Leadership Team (Kym Hall):1. Camas Cr patrol cabin, include 100-ft buffer of cabin + 100-ft buffer of roadway from Inside Rd.2. Bowman CG area: extend 'excluded' area from admin road to creek edge to accommodate admin road/trail (to bridge) not yet mapped. Also inlcude 100-ft buffered trail and 100-ft buffered buildings due east of bridge. 3. Kintla CG - same changes as Bowman, using standard 100-ft buffer of road/cabins4. Belly River enclave is added to the data set.-----------Update layer January 24, 2014 with these edits:1. Add Marias Pass 'excluded' area; 100-ft buffer of RR turnaround.2. Extend HQ area 'excluded' polygon to river /park bdy3. Create Dev Area footprints for Road Camp & Packer's Roost; buffer 300-ft and add to 'excluded'.----------Update layer January 13, 2014 with these edits:1. Bowman CG - add admin road missed, 2. Walton - remove exclusion area between road buffer and boundary, and 3. Swiftcurrent - include Swiftcurrent+Josephine Lakes as excluded, plus bump-out areas for boat storage and creek used to ferry supplies from Swift. Lake to Josephine Lake.---------Update layer April 15-18, 2014 with these additions/edits:1. Create developed area for Apgar Lookout; buffer 300-ft.2. Create developed area for 1913 Ranger Station (St Mary); buffer 300-ft.3. Add 2 monitoring wells in St Mary Flats (foot of lake south of GTSR); buffer 25-ft and connect to 'excluded area' polygon4. Add water source point for Many Glacier winter cabin (north of MG road near hotel jct; buffer 25-ft and add to 'excluded area' polygon5. Buffer McCarthy Homestead structures 100-ft and add to Excluded Area polygon for Inside North Fork Rd6. Buffer Ford Creek cabin structures 100-ft and add to Excluded Area polygon for Inside North Fork Rd7. Buffer Baring Crek cabin structures 100-ft and add to Excluded Area polygon Going to the Sun Rd8. Add to Excluded Area a strip of land 60-ft south of the International Boundary (per 1974 Wilderness proposal & MOU with GLAC and Int'l Boundary Comm).---------Updated layer 5/27/2014 - add approx. 2 acres to 'Excluded fro mWilderness' near the St Mary River bridge along GTSR. This sliver of land was included to utilize the river bank as a visible and distinguishable boundary in the field.

© NPS, Glacier NP GIS Program

This layer is a component of Glacier National Park.

This map service provides layers covering a variety of different datasets and themes for Glacier National Park. It is meant to be consumed by internet mapping applications and for general reference. It is for internal NPS use only. Produced November 2014.

© Denver Service Center Planning Division, IMR Geographic Resources Division, Glacier National Park

Data has been created from hosted feature service (https://mapping.gw.govt.nz/arcgis/rest/services/GW/NRPMap_P_operative/MapServer). It has been shared to the Open Data Portal. Map of lowland areas for category 2 surface waterbodies in the Wellington region for the management of rivers and streams in productive rural lowland areas.This feature class is derived from the New Zealand Land Resource Inventory (NZLRI) and the Land Cover Database v4 (2012), both produced by Landcare Research - Manaaki Whenua.In particular it is based on the land use capability layer which makes an assessment of the productive capability of land areas based on the underlying geology, soil type, slope angle, erosion susceptibility and vegetative cover.Slope classes A, B & C (under 16 deg) and soil classes 1-4 (arable land) were classified for inclusion in the area. Slope classes D,E, F & G (over 16 deg) and soil classes 5-8 (non-arable land) were excluded.It was created by first eliminating discrete polygons with slope classes below 15 degrees, occurring within broader areas above 16 degrees, using the dissolve tool. Likewise, islands of land over 16 degrees smaller than 15 km2sitting within lowland areas under 16 degrees were eliminated. Then complex, crenulated areas were rounded off with the simplify and smooth polygon tool. The whole delineation was then checked for accuracy and aligned where necessary to conform to slopes under 16 degrees with arable soils classes four and under.

Reason for Selection Large areas of intact natural habitat are favorable for conservation of numerous species, including reptiles and amphibians, birds, and large mammals. The Esri Green Infrastructure data covers the entire United States and has been used in other broad-scale conservation planning efforts, so using this existing data helps align the Blueprint with other conservation efforts and reduce duplication of effort. We chose to use “Core Size (acres)” as the metric for this indicator. Other evaluation attributes included in this index, such as the default “Core Score”, were less suitable because they were calculated using inputs that are duplicative of other indicators.Input Data2021 National Land Cover Database (NLCD)Southeast Blueprint 2024 extentEsri’s Intact Habitat Cores 2023, accessed 2-16-2024: Core Size (Acres); to download, select “Open in ArcGIS Desktop” and make a local copy. According to Esri’s data description for the 2023 intact habitat cores update: “This layer represents modeled Intact Habitat Cores, or minimally disturbed natural areas at least 100 acres in size and greater than 200 meters wide. Esri created these data following a methodology outlined by the Green Infrastructure Center Inc. These data were generated using 2019 National Land Cover Data. Cores were derived from all “natural” landcover classes and excluded all “developed” and “agricultural” classes including crop, hay and pasture lands. The resulting cores were tested for size and width requirements (at least 100 acres in size and greater than 200 meters wide) and then converted into unique polygons.”Mapping StepsConvert the Esri Intact Habitat Cores 2023 polygons to a 30 m raster using the values in the “Acres” field. We used the feature layer map service as the input in the Polygon to Raster function in the code.Reclassify the above raster into 4 classes, seen in the final indicator values below.Use NLCD to remove zero values in deep marine areas, which are outside the scope of this terrestrial indicator. Use a conditional statement to assign NoData to any area with a pixel value >0 in the NLCD.As a final step, clip to the spatial extent of Southeast Blueprint 2024. 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:3 = Large core (>10,000 acres)2 = Medium core (>1,000-10,000 acres)1 = Small core (>100–1,000 acres) 0 = Not a coreKnown IssuesThe core analysis for this indicator is based on the 2019 NLCD, not the more recent 2021 NLCD. Esri has shared the scripts and input data used to create this layer, which may also help update this indicator in the future.Even small dirt roads serve as hard boundaries for habitat cores. While this makes sense for some species, this indicator likely underestimates the effective size of the patch for some more mobile animals.Waterbodies like reservoirs are also considered part of habitat cores, so this layer likely overestimates the effective size of the habitat core for most species.Many intact habitat cores have a speckling of small altered areas inside of them. In some cases, like in areas of west TX with concentrated oil wells, there can be many alterations in a gridded pattern across the entire core. This indicator underestimates the cumulative impacts of interior alterations—especially when the small altered footprints are densely packed in a grid within a habitat core.Disclaimer: Comparing with Older Indicator Versions There are numerous problems with using Southeast Blueprint indicators for change analysis. Please consult Blueprint staff if you would like to do this (email hilary_morris@fws.gov).Literature CitedEsri Green Infrastructure Center. Data Description: Detailed Description and Methodology for Intact Habitat Cores. PDF. Last updated June 30, 2023. [https://nation.maps.arcgis.com/home/item.html?id=047d9b05e0c842b1b126bc0767acfd5e]. Esri Green Infrastructure Center, Inc. 2023. Intact Habitat Cores (2023). [https://www.arcgis.com/home/item.html?id=b404b86a079a48049cb50272df23267a].