Do not share this map Publicly!This template is for ACTIVE INCIDENTS only. For training, please use the Training template (found here). This workflow uses one template web map and contains all layers of the National Incident Feature Service in a single service (Unlike the standard template which splits features into Edit, View, and Repair services). It is for teams looking for a simple approach to ArcGIS Online implementation. All features are visible; editing is enabled for points, lines, and polygons and disabled for the IR layers [Workflow LINK]; contains the National Incident Feature Service layers: NWCG approved Event schema.This template web map is provided for quick deployment. Listed next are the steps to implement this Standard Workflow:1) Open this web map template in Map Viewer2) Do a Save As (Click Save and select Save As)3) Zoom to your fire area and add bookmarks4) Look for a red triangle polygon with your fire's attributes - do either of these: a. Use this polygon as a start for your incident and modify as needed b. Copy the attributes (most importantly, the IRWIN ID) into a new polygon and delete the triangle (delete in ArcMap or Pro)5) Create a display filter on features to only show features related to your incident (Optional).6) Create a new Photo Point Layer (Content > Create > Feature Layer > From Existing > #TEMPLATE - PhotoPoint). Add this to your web map and remove default PhotoPoint Layer7) Share with your Mobile Editing group8) Add necessary incident personnel to the Mobile Editing group9) Make available for Viewers:a. Save out a second version of this map and disable editing on all the layers except Photo Points.b. Share this version with the Viewing group.10) To track and manage suppression repair needs use the Suppression Repair Add-on

This dataset is a modified version of the FWS developed data depicting “Highly Important Landscapes”, as outlined in Memorandum FWS/AES/058711 and provided to the Wildlife Habitat Spatial analysis Lab on October 29th 2014. Other names and acronyms used to refer to this dataset have included: Areas of Significance (AoSs - name of GIS data set provided by FWS), Strongholds (FWS), and Sagebrush Focal Areas (SFAs - BLM). The BLM will refer to these data as Sagebrush Focal Areas (SFAs). Data were provided as a series of ArcGIS map packages which, when extracted, contained several datasets each. Based on the recommendation of the FWS Geographer/Ecologist (email communication, see data originator for contact information) the dataset called “Outiline_AreasofSignificance” was utilized as the source for subsequent analysis and refinement. Metadata was not provided by the FWS for this dataset. For detailed information regarding the dataset’s creation refer to Memorandum FWS/AES/058711 or contact the FWS directly. Several operations and modifications were made to this source data, as outlined in the “Description” and “Process Step” sections of this metadata file. Generally: The source data was named by the Wildlife Habitat Spatial Analysis Lab to identify polygons as described (but not identified in the GIS) in the FWS memorandum. The Nevada/California EIS modified portions within their decision space in concert with local FWS personnel and provided the modified data back to the Wildlife Habitat Spatial Analysis Lab. Gaps around Nevada State borders, introduced by the NVCA edits, were then closed as was a large gap between the southern Idaho & southeast Oregon present in the original dataset. Features with an area below 40 acres were then identified and, based on FWS guidance, either removed or retained. Finally, guidance from BLM WO resulted in the removal of additional areas, primarily non-habitat with BLM surface or subsurface management authority. Data were then provided to each EIS for use in FEIS development. Based on guidance from WO, SFAs were to be limited to BLM decision space (surface/sub-surface management areas) within PHMA. Each EIS was asked to provide the limited SFA dataset back to the National Operations Center to ensure consistent representation and analysis. Returned SFA data, modified by each individual EIS, was then consolidated at the BLM’s National Operations Center retaining the three standardized fields contained in this dataset.Several Modifications from the original FWS dataset have been made. Below is a summary of each modification.1. The data as received from FWS: 16,514,163 acres & 1 record.2. Edited to name SFAs by Wildlife Habitat Spatial Analysis Lab:Upon receipt of the “Outiline_AreasofSignificance” dataset from the FWS, a copy was made and the one existing & unnamed record was exploded in an edit session within ArcMap. A text field, “AoS_Name”, was added. Using the maps provided with Memorandum FWS/AES/058711, polygons were manually selected and the “AoS_Name” field was calculated to match the names as illustrated. Once all polygons in the exploded dataset were appropriately named, the dataset was dissolved, resulting in one record representing each of the seven SFAs identified in the memorandum.3. The NVCA EIS made modifications in concert with local FWS staff. Metadata and detailed change descriptions were not returned with the modified data. Contact Leisa Wesch, GIS Specialist, BLM Nevada State Office, 775-861-6421, lwesch@blm.gov, for details.4. Once the data was returned to the Wildlife Habitat Spatial Analysis Lab from the NVCA EIS, gaps surrounding the State of NV were closed. These gaps were introduced by the NVCA edits, exacerbated by them, or existed in the data as provided by the FWS. The gap closing was performed in an edit session by either extending each polygon towards each other or by creating a new polygon, which covered the gap, and merging it with the existing features. In addition to the gaps around state boundaries, a large area between the S. Idaho and S.E. Oregon SFAs was filled in. To accomplish this, ADPP habitat (current as of January 2015) and BLM GSSP SMA data were used to create a new polygon representing PHMA and BLM management that connected the two existing SFAs.5. In an effort to simplify the FWS dataset, features whose areas were less than 40 acres were identified and FWS was consulted for guidance on possible removal. To do so, features from #4 above were exploded once again in an ArcMap edit session. Features whose areas were less than forty acres were selected and exported (770 total features). This dataset was provided to the FWS and then returned with specific guidance on inclusion/exclusion via email by Lara Juliusson (lara_juliusson@fws.gov). The specific guidance was:a. Remove all features whose area is less than 10 acresb. Remove features identified as slivers (the thinness ratio was calculated and slivers identified by Lara Juliusson according to https://tereshenkov.wordpress.com/2014/04/08/fighting-sliver-polygons-in-arcgis-thinness-ratio/) and whose area was less than 20 acres.c. Remove features with areas less than 20 acres NOT identified as slivers and NOT adjacent to other features.d. Keep the remainder of features identified as less than 40 acres.To accomplish “a” and “b”, above, a simple selection was applied to the dataset representing features less than 40 acres. The select by location tool was used, set to select identical, to select these features from the dataset created in step 4 above. The records count was confirmed as matching between the two data sets and then these features were deleted. To accomplish “c” above, a field (“AdjacentSH”, added by FWS but not calculated) was calculated to identify features touching or intersecting other features. A series of selections was used: first to select records 6. Based on direction from the BLM Washington Office, the portion of the Upper Missouri River Breaks National Monument (UMRBNM) that was included in the FWS SFA dataset was removed. The BLM NOC GSSP NLCS dataset was used to erase these areas from #5 above. Resulting sliver polygons were also removed and geometry was repaired.7. In addition to removing UMRBNM, the BLM Washington Office also directed the removal of Non-ADPP habitat within the SFAs, on BLM managed lands, falling outside of Designated Wilderness’ & Wilderness Study Areas. An exception was the retention of the Donkey Hills ACEC and adjacent BLM lands. The BLM NOC GSSP NLCS datasets were used in conjunction with a dataset containing all ADPP habitat, BLM SMA and BLM sub-surface management unioned into one file to identify and delete these areas.8. The resulting dataset, after steps 2 – 8 above were completed, was dissolved to the SFA name field yielding this feature class with one record per SFA area.9. Data were provided to each EIS for use in FEIS allocation decision data development.10. Data were subset to BLM decision space (surface/sub-surface) within PHMA by each EIS and returned to the NOC.11. Due to variations in field names and values, three standardized fields were created and calculated by the NOC:a. SFA Name – The name of the SFA.b. Subsurface – Binary “Yes” or “No” to indicated federal subsurface estate.c. SMA – Represents BLM, USFS, other federal and non-federal surface management 12. The consolidated data (with standardized field names and values) were dissolved on the three fields illustrated above and geometry was repaired, resulting in this dataset.

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.

This provides a polygon coastline and islands layer which is based on the Topo50 products. It is a combination of the following layers:

• NZ Coastlines (Topo 1:50k)
• NZ Island Polygons (Topo 1:50k)
• NZ Auckland Is Island Polygons (Topo, 1:50k)
• NZ Campbell Is / Motu Ihupuku Island Polygons (Topo, 1:50k)
• NZ Antipodes Is Island Polygons (Topo, 1:25k)
• NZ Kermadec Is Island Polygons (Topo, 1:25k)
• NZ Bounty Is Island Polygons (Topo, 1:25k)
• NZ Snares Is / Tini Heke Island Polygons (Topo, 1:25k)
• NZ Chatham Is island polygons (Topo, 1:50k)

This topographic coastline is the line forming the boundary between the land and sea, defined by mean high water.

Islands from the NZ Island Polygons layer that lie within the NZ Coastline and Chatham Islands areas (i.e. islands in lakes, rivers and estuaries) have been removed.

The GIS workflow to create the layer is:

1. NZ Coastlines were converted from a polyline to a polygon using a polyline to polygon tool.
2. The resulting coastal polygon was then used as an input into an erase tool and run against the NZ Island Polygon layer to remove all islands lying within the NZ Mainland and Stewart Island.
3. This was then merged with the NZ Chatham Is island polygons (Topo, 1:50k) that have had the islands within the main island polygon removed, NZ Auckland Is Island Polygons (Topo, 1:50k), NZ Campbell Is / Motu Ihupuku Island, NZ Antipodes Is Island Polygons (Topo, 1:25k), NZ Kermadec Is Island Polygons (Topo, 1:25k), NZ Bounty Is Island Polygons (Topo, 1:25k) and NZ Snares Is / Tini Heke Island Polygons (Topo, 1:25k) layers using a merge tool.

For more detailed description of each layer refer to the layer urls above.

APIs and web services This dataset is available via ArcGIS Online and ArcGIS REST services, as well as our standard APIs. LDS APIs and OGC web services ArcGIS Online map services ArcGIS REST API

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.

This layer generally describes Geologically Hazardous Areas as defined in TMC 13.11.700, including erosion and landslide hazard areas. It is used to review changes to these areas including development proposals, proposals for vegetation modification, and potential violations for compliance with critical area and building codes.This layer was derived from 2018 bare earth lidar. The initial analysis steps include: slope tool to create a % rise surface then using the int tool and reclassify using the 0-15, 15-25, 25-40 and >40 percent slope. Those classifications were converted to polygons. Further refinement was done to reduce the number of polygons. All areas in the >15% classification were deleted, all polygons <200ft in length and all polygons < 100 sq. ft. in area were deleted. Additional simplifying was done to create smoother boundaries of areas and a series of positive and negative buffers was used to remove holes in areas. Additional refinement to this was done including: (Deleted polygons <= 200 sq. ft. for Slope Category 15 - 25%. Deleted polygons <= 100 sq. ft. for Slope Category 25 - 40% & Over 40%)Data Steward contact: Craig Kuntz, ckuntz@cityoftacoma.org or Lisa Spadoni, Natural Resources Program Manager, lspadoni@cityoftacoma.org.

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, coastal buffers are removed, leaving 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 BuffersWithout Coastal Buffers (this dataset)Place 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.

As described in the Executive Summary below from the Draft 2021-2029 Housing Element, these are the parcels from the 'Rezoning Program' as of 7/26/21. For more information about the Draft Housing Element, please click here.EXECUTIVE SUMMARY (from Draft Housing Element):The County is required to ensure the availability of residential sites, at adequate densities and appropriate development standards, in the unincorporated areas to accommodate its share of the regional housing need--also known as the Regional Housing Needs Allocation (RHNA). The unincorporated areas have been assigned a RHNA of 90,052 units for the 2021-2029 Housing Element planning period, which is subdivided by level of affordability as follows:Very Low Income – 25,648Lower Income – 13,691Moderate Income – 14,180Above Moderate Income – 36,533The Sites Inventory (Appendix A) is comprised of vacant and underutilized sites that are zoned at appropriate densities and development standards to facilitate housing development. Other strategies to accommodate the RHNA include projected number of ADUs, specific plan capacity, selected entitled projects, and capacity or planned development on County-owned sites within cities. The remainder of the RHNA is accommodated by sites to be rezoned to accommodate higher density housing development.MORE DETAILED INFO ON METHODOLOGY: ((PLACEHOLDER for Appendix G from BOS Consent posting))UPDATE HISTORY:1/5/21 - Coded Supervisorial District for each parcel2/4/21 - Added four fields that show the proposed / existing Land Use Policy / Zoning that display the category + brief description + density range - done mainly for the Story Map. Also, renamed the GIS layer (removed 'Adequate_Sites_Inventory' from the name).3/16/21 - Added 'Status Update (2021)' field to flag those parcels for removal following findings from Housing Section and EIR consultant.3/31/21 - Began making edits based on QC done by Housing Section in March, 2021 and exported this layer to an ARCHIVE version so we have the original data if needed. Made the following updates in AltadenaCoded all 'GC' categories as 'N/A' for RHNA Eligible and removed proposed LUP / Zoning category - THESE CAN NO LONGER BE COUNTED IN REZONE.Downgraded Proposed MU to Proposed CG for all current 'MU / Commercial Zones', and updated min/max density. Nulled out proposed zoning categories. Need to re-do unit calculations!4/1/21 - Continuing with Altadena QC, updating Status Update (2021) field:Downgraded Proposed MU to Proposed CG for all current 'MU / Non-Commercial Zones', and updated min/max density. Need Proposed Zoning from HE Section for consistency with CG category. Need to re-do unit calculations!Coded the ones marked 'Zoe to review'4/4/21 - Coded additional parcels that were condos (missed from before). Updated '2021 Update notes' and condo-related fields (including units). In Altadena, re-calculated units for all that are downgraded from Prop LU MU > CG. Identified those not meeting 16 unit minimum, and of those that were RHNA eligible, were coded as 'No'. Noted in the '2021 Update notes'.4/5/21 - Made the following edits per QC results from Housing Section:Lennox / W. Athens - coded '65 dB' parcels as "N/A" (removing from Rezoning list).Altadena - verified that no additional RHNA eligible parcels removed due to the criteria: “Existing residential buildings 50 or more years old, where the number of units allowed under the new LU is at least 2 - 3 times what's on the ground”All areas - coded Density Bonus of 27.5% as identified from the Housing Section as blank4/6/21 - Continued making edits per the QC results from Housing Section from the Rezoning list.4/7/21 - Continued making edits per the QC results from the Housing Section for Altadena.4/10/21 - Double-checked all Rezone edits. Re-calculated all units for all those that were updated (Status Update 2021 IS NOT NULL) and are on Rezoning list (RHNA Eligible? <> 'N/A'). Exported RHNA eligible to spreadsheet and double-checked unit maths.4/12/21 - Updated last proposed zoning categories in Altadena (confirmed by Housing Section). Updated current / proposed zoning descriptions (removed zoning suffices).4/13/21 - Made additional QC updates to some statuses regarding parcels that overlap with ASI.4/14/21 - Updated current zoning for the recently adopted By-Right Housing Ordinance Zone Change (all of these cases have the status of "N/A" - or, not considered for rezoning)4/15/21 - Researched 11 parcels that were coded as 'Yes - Rezoning Program' for RHNA Eligibility AND were flagged as not RHNA eligible for the model runs done previously 'Filter 2b'. Confirmed they should all remain RHNA eligible with the exception of 2.4/27/21 - Updated status for additional sites during week of 4/19, and on 4/27. Updated 107 parcels to the RHNA Eligibility Status of "Yes - Moderate Income"4/28/21 - Updated 310 parcels to the RHNA Eligibility Status of "Yes - Above Moderate Income"5/4/21 - Updated RHNA Eligibility Status to "No" since it overlapped with ASI.5/5/21 - Updated RHNA Eligibility Status to "Yes - Moderate" and "Yes - Above Moderate", and also removed two parcels that were also Historical Sites, per QC requests from Housing Section. SUMMARIZED THIS DATA AS A TABLE TO RESPOND TO SUPERVISORIAL DISTRICT 1.5/11/21 - Updated schema:RHNA Eligible now just 'Yes' or 'No' (Rather than 'Yes + Inc level')Added fields for various income levels - to match what is in ASI layerKept 'Realistic Capacity' for the 'Non RHNA-Eligible' sites (these aren't broken down by Income level)Calculated 'Very Low' and 'Low' income levels to be 50/50 of the 'Realistic Capacity' (rounded up for VL, rounded down for L)5/12/21 - PREP FOR HCD TEMPLATE - Added field for Vacant / Non Vacant uses per the Assessor Use Code (ends in 'V' or 'X')6/2/21 - Updated one parcel that had 'Prop min density' blank. Trimmed Site Address field of trailing spaces.6/10/21 - ARCHIVED - exported to an archived layer as this is a snapshot in time from when it was sent to HCD on 6/7/21.6/28/21 - Exported the features (essentially copied the layer) as there was some strange behavior of attributes not selecting and joins not fully working - suspected that the data was slightly corrupted somehow, however a simple copy seemed to fix the issue. Modified several parcels per QC done by Housing Section in June, added some parcels as well.6/29/21 - Added sites per June QC and updated relevant fields - flagged those that need to have units recalculated in a temporary field.6/30/21 - Updated units for added sites. Flagged several parcels in FF and WALP for removal. RENAMED 'RHNA STATUS' CATEGORIES FROM "N/A" TO "REMOVE" (to be consistent with the ASI)7/1/21 - Removed or otherwise modified several parcels due to overlapping with new bldg permits / entitlements.7/6/21 - Updated based on refinements identified by the Housing Section on 7/1/21: Adding back Central Ave in Florence-Firestone and adding/removing sites in La Crescenta-Montrose, and updating some minor things (not related to units).7/7/21 - Checked math on all unit calculations using formulas in Excel - a small number of them were off by 1 unit (probably due to not rounding), and they were fixed. Added 'Planning Areas' field.7/20/21 - Incorporated changes following additional QC and zoning Inconsistencies identified in South and West Whittier following significant shortfall with the removal of Northlake Specific Plan:Added Income Category field and calculated valuesRemoved one parcel that overlapped with an existing Mobile Home ParkRemoved 1,122 polygons flagged as "REMOVED" that overlapped with the South and West Whittier changes (select by location against "Zoning_Inconsistancy_Parcels_SDs_345" layer.Added parcels for Above Moderate RHNA units from "Zoning_Inconsistancy_Parcels_SDs_345" layer and filled in fields as necessary.Added Adj Cluster IDs for 8 of the newly added parcels (adding to the next highest available ID in the whole dataset)7/24/21 - Coded all empty Site Addresses with nearest Street Intersection. See analysis fields starting with "Street_Intersection" in 'Housing_Element_2021_2029' File GDB.7/25/21 - Added ZIP Codes for those that were blank.7/26/21 - re-worded the metadata description (above UPDATE HISTORY)7/30/21 - 7/31/21 - Added Proposed Florence-Firestone TOD parcels.9/13/21 - Slight update to calculate the 'Income Category' field for those with RHNA Eligible = NO - to make those NULL.11/16/21 - Removed Density Bonus from the bottom 15% of sites (71 sites out of the 468) per HCD's comment. For the sites that fell below the 16 units, they were moved to the Above Moderate income category to receive RHNA credit.12/30/21 - Added updated Supervisorial District ID from 2021 update.2/17/22 - Cleared out Realistic Capacity and all income level units for "RHNA Eligible = NO". This is a clean-up measure. Kept all unit calculations for these up until the 'Realistic Capacity' field.3/15/22 & 3/16/22 - Re-allocation of income-level units per recommendation by HCD. New fields were added to indicate the original income level unit numbers (as submitted to the state following the Board Hearing), and an HCD Comments field was added to flag these parcels that changed, and the transfer of units between the income categories.SLA - move units from VL/L to Mod. Added 2,238 to Mod and subtracted 1,144 from VL, and 1,094 Low Income (lots with sf < 5,950). Checked if there were any project-specific allocations to income levels and there were none.SLA - move units from L to AM. Remaining Low Income after Step 1 is 5,819, so take approximately half of that. Selecting from pool outside of those selected in STEP 1, and lot size < 10,000sf, moved 2,566 from Low Income to Above Moderate. Checked if there were any project-specific allocations to income levels and there were none. OTHER SUBMARKET - move units from L to AM. Moved 10,031 units from L to AM (lots < 90,000 sf). NOTE, that this was most of

This feature class represents combined 200ft and 1000ft beach buffers derived from Intertidal_PL. The process for creating this combined buffer is as follows: Select from Intertidal_PL where Description in ( 'CHK' , 'INT', 'EST', 'UIT' ) and buffer it 1000 ft, then dissolve all, so it's just a big ol' blob. Use the same selected set from Intertidal_PL and buffer it 200 feet, then dissolve all.Then select from Intertidal_PL where Description in ( 'CHK' , 'SW', 'EST' ) and erase those areas from the big buffered blobs. (I do not erase the INT areas because that might leave gaps and slivers along the shoreline above the water.)Add a field called Buff1000ft to the 1000 foot buffer and populate it with 'Y'. Add a field called Buff200ft to the 200 foot buffer and populate it with 'Y'. Identity the 200 ft buffer onto the 1000 ft buffer.Select where the field Buff200ft is blank and populate it with 'N'. (This would be the area within the 1000 ft buffer that falls outside of the 200 ft buffer.)The resulting buffer polygons can end up being wider than 1000ft or 200ft respectively in some places (beach…etc), but the intent of the polygons is to go landward 1000ft/200ft – the additional width is due to the beach/island/peninsula type stuff. The reason I originally started choosing to buffer CHK, INT, EST, and UIT was because I was concerned that buffering only INT might lead to odd gaps.

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

Terms of UseData Limitations and DisclaimerThe user’s use of and/or reliance on the information contained in the Document 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.This is an ongoing data development project. Attempts have been made to contact all PWS systems, but not all have responded with information on their service area. MassDEP will continue to collect and verify this information. Some PWS service areas included in this datalayer have not been verified by the PWS or the municipality involved, but since many of those areas are based on information published online by the municipality, the PWS, or in a publicly available report, they are included in the estimated PWS service area datalayer.Please note: All PWS 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 PWS service area are necessarily served by the system, and some properties outside the mapped service areas could be served by the PWS – please contact the relevant PWS. Not all service areas have been confirmed by the systems.Please use the following citation to reference these data:MassDEP, Water Utility Resilience Program. 2025. Community and Non-Transient Non-Community Public Water System Service Area (PubV2025_3).IMPORTANT NOTICE: This MassDEP Estimated Water Service datalayer may not be complete, may contain errors, omissions, and other inaccuracies and the data are subject to change. This version is published through MassGIS. We want to learn about the data uses. If you use this dataset, please notify staff in the Water Utility Resilience Program (WURP@mass.gov).This GIS datalayer represents approximate service areas for Public Water Systems (PWS) in Massachusetts. In 2017, as part of its “Enhancing Resilience and Emergency Preparedness of Water Utilities through Improved Mapping” (Critical Infrastructure Mapping Project ), the MassDEP Water Utility Resilience Program (WURP) began to uniformly map drinking water service areas throughout Massachusetts using information collected from various sources. Along with confirming existing public water system (PWS) service area information, the project collected and verified estimated service area delineations for PWSs not previously delineated and will continue to update the information contained in the datalayers. As of the date of publication, WURP has delineated Community (COM) and Non-Transient Non-Community (NTNC) service areas. Transient non-community (TNCs) are not part of this mapping project.Layers and Tables:The MassDEP Estimated Public Water System Service Area data comprises two polygon feature classes and a supporting table. Some data fields are populated from the MassDEP Drinking Water Program’s Water Quality Testing System (WQTS) and Annual Statistical Reports (ASR).The Community Water Service Areas feature class (PWS_WATER_SERVICE_AREA_COMM_POLY) includes polygon features that represent the approximate service areas for PWS classified as Community systems.The NTNC Water Service Areas feature class (PWS_WATER_SERVICE_AREA_NTNC_POLY) includes polygon features that represent the approximate service areas for PWS classified as Non-Transient Non-Community systems.The Unlocated Sites List table (PWS_WATER_SERVICE_AREA_USL) contains a list of known, unmapped active Community and NTNC PWS services areas at the time of publication.ProductionData UniversePublic Water Systems in Massachusetts are permitted and regulated through the MassDEP Drinking Water Program. The WURP has mapped service areas for all active and inactive municipal and non-municipal Community PWSs in MassDEP’s Water Quality Testing Database (WQTS). Community PWS refers to a public water system that serves at least 15 service connections used by year-round residents or regularly serves at least 25 year-round residents.All active and inactive NTNC PWS were also mapped using information contained in WQTS. An NTNC or Non-transient Non-community Water System refers to a public water system that is not a community water system and that has at least 15 service connections or regularly serves at least 25 of the same persons or more approximately four or more hours per day, four or more days per week, more than six months or 180 days per year, such as a workplace providing water to its employees.These data may include declassified PWSs. Staff will work to rectify the status/water services to properties previously served by declassified PWSs and remove or incorporate these service areas as needed.Maps of service areas for these systems were collected from various online and MassDEP sources to create service areas digitally in GIS. Every PWS is assigned a unique PWSID by MassDEP that incorporates the municipal ID of the municipality it serves (or the largest municipality it serves if it serves multiple municipalities). Some municipalities contain more than one PWS, but each PWS has a unique PWSID. The Estimated PWS Service Area datalayer, therefore, contains polygons with a unique PWSID for each PWS service area.A service area for a community PWS may serve all of one municipality (e.g. Watertown Water Department), multiple municipalities (e.g. Abington-Rockland Joint Water Works), all or portions of two or more municipalities (e.g. Provincetown Water Dept which serves all of Provincetown and a portion of Truro), or a portion of a municipality (e.g. Hyannis Water System, which is one of four PWSs in the town of Barnstable).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 estimates based on the general location of the source wells or the general estimated location of the service area - these do not represent the actual service area.Service areas were mapped initially from 2017 to 2022 and reflect varying years for which service is implemented for that service area boundary. WURP maintains the dataset quarterly with annual data updates; however, the dataset may not include all current active PWSs. A list of unmapped PWS systems is included in the USL table PWS_WATER_SERVICE_AREA_USL available for download with the dataset. Some PWSs that are not mapped may have come online after this iteration of the mapping project; these will be reconciled and mapped during the next phase of the WURP project. PWS IDs that represent regional or joint boards with (e.g. Tri Town Water Board, Randolph/Holbrook Water Board, Upper Cape Regional Water Cooperative) will not be mapped because their individual municipal service areas are included in this datalayer.PWSs that do not have corresponding sources, may be part of consecutive systems, may have been incorporated into another PWSs, reclassified as a different type of PWS, or otherwise taken offline. PWSs that have been incorporated, reclassified, or taken offline will be reconciled during the next data update.Methodologies and Data SourcesSeveral methodologies were used to create service area boundaries using various sources, including data received from the systems 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 PWS websites. When provided with water line data rather than generalized areas, 300-foot buffers were created around the water 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.Verification ProcessSmall-scale PDF file maps with roads and other infrastructure were sent to every PWS for corrections or verifications. For small systems, 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 PWS 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 the PWS.Sources of information for estimated drinking water service areasThe following information was used to develop estimated drinking water service areas:EOEEA Water Assets Project (2005) water lines (these were buffered to create service areas)Horsely Witten Report 2008Municipal Master Plans, Open Space Plans, Facilities Plans, Water Supply System Webpages, reports and online interactive mapsGIS data received from PWSDetailed infrastructure mapping completed through the MassDEP WURP Critical Infrastructure InitiativeIn the absence of other service area information, for municipalities served by a town-wide water system serving at least 97% of the population, the municipality’s boundary was used. Determinations of which municipalities are 97% or more served by the PWS were made based on the Percent Water Service Map created in 2018 by MassDEP based on various sources of information including but not limited to:The Winter population served submitted by the PWS in the ASR submittalThe number of services from WQTS as a percent of developed parcelsTaken directly from a Master Plan, Water Department Website, Open Space Plan, etc. found onlineCalculated using information from the town on the population servedMassDEP staff estimateHorsely Witten Report 2008Calculation based on Water System Areas Mapped through MassDEP WURP Critical Infrastructure Initiative, 2017-2022Information found in publicly available PWS planning documents submitted to MassDEP or as part of infrastructure planningMaintenanceThe

This dataset is a modified version of the FWS developed data depicting “Highly Important Landscapes”, as outlined in Memorandum FWS/AES/058711 and provided to the Wildlife Habitat Spatial analysis Lab on October 29th 2014. Other names and acronyms used to refer to this dataset have included: Areas of Significance (AoSs - name of GIS data set provided by FWS), Strongholds (FWS), and Sagebrush Focal Areas (SFAs - BLM). The BLM will refer to these data as Sagebrush Focal Areas (SFAs). Data were provided as a series of ArcGIS map packages which, when extracted, contained several datasets each. Based on the recommendation of the FWS Geographer/Ecologist (email communication, see data originator for contact information) the dataset called “Outiline_AreasofSignificance” was utilized as the source for subsequent analysis and refinement. Metadata was not provided by the FWS for this dataset. For detailed information regarding the dataset’s creation refer to Memorandum FWS/AES/058711 or contact the FWS directly. Several operations and modifications were made to this source data, as outlined in the “Description” and “Process Step” sections of this metadata file. Generally: The source data was named by the Wildlife Habitat Spatial Analysis Lab to identify polygons as described (but not identified in the GIS) in the FWS memorandum. The Nevada/California EIS modified portions within their decision space in concert with local FWS personnel and provided the modified data back to the Wildlife Habitat Spatial Analysis Lab. Gaps around Nevada State borders, introduced by the NVCA edits, were then closed as was a large gap between the southern Idaho & southeast Oregon present in the original dataset. Features with an area below 40 acres were then identified and, based on FWS guidance, either removed or retained. Guidance from BLM WO resulted in the removal of additional areas including: non-habitat with BLM surface or subsurface management authority, all areas within the Lander EIS boundary, and areas outside of PHMA once EISs had updated PHMA designation.Several Modifications from the original FWS dataset have been made. Below is a summary of each modification.1. The data as received from FWS.2. Edited to name SFAs by Wildlife Habitat Spatial Analysis Lab:Upon receipt of the “Outiline_AreasofSignificance” dataset from the FWS, a copy was made and the one existing & unnamed record was exploded in an edit session within ArcMap. A text field, “AoS_Name”, was added. Using the maps provided with Memorandum FWS/AES/058711, polygons were manually selected and the “AoS_Name” field was calculated to match the names as illustrated. Once all polygons in the exploded dataset were appropriately named, the dataset was dissolved, resulting in one record representing each of the seven SFAs identified in the memorandum.3. The NVCA EIS made modifications in concert with local FWS staff. Metadata and detailed change descriptions were not returned with the modified data. Contact Leisa Wesch, GIS Specialist, BLM Nevada State Office, 775-861-6421, lwesch@blm.gov, for details.4. Once the data was returned to the Wildlife Habitat Spatial Analysis Lab from the NVCA EIS, gaps surrounding the State of NV were closed. These gaps were introduced by the NVCA edits, exacerbated by them, or existed in the data as provided by the FWS. The gap closing was performed in an edit session by either extending each polygon towards each other or by creating a new polygon, which covered the gap, and merging it with the existing features. In addition to the gaps around state boundaries, a large area between the S. Idaho and S.E. Oregon SFAs was filled in. To accomplish this, ADPP habitat (current as of January 2015) and BLM GSSP SMA data were used to create a new polygon representing PHMA and BLM management that connected the two existing SFAs.5. In an effort to simplify the FWS dataset, features whose areas were less than 40 acres were identified and FWS was consulted for guidance on possible removal. To do so, features from #4 above were exploded once again in an ArcMap edit session. Features whose areas were less than forty acres were selected and exported (770 total features). This dataset was provided to the FWS and then returned with specific guidance on inclusion/exclusion via email by Lara Juliusson (lara_juliusson@fws.gov). The specific guidance was:a. Remove all features whose area is less than 10 acresb. Remove features identified as slivers (the thinness ratio was calculated and slivers identified by Lara Juliusson according to https://tereshenkov.wordpress.com/2014/04/08/fighting-sliver-polygons-in-arcgis-thinness-ratio/) and whose area was less than 20 acres.c. Remove features with areas less than 20 acres NOT identified as slivers and NOT adjacent to other features.d. Keep the remainder of features identified as less than 40 acres.To accomplish “a” and “b”, above, a simple selection was applied to the dataset representing features less than 40 acres. The select by location tool was used, set to select identical, to select these features from the dataset created in step 4 above. The records count was confirmed as matching between the two data sets and then these features were deleted. To accomplish “c” above, a field (“AdjacentSH”, added by FWS but not calculated) was calculated to identify features touching or intersecting other features. A series of selections was used: first to select records < 20 acres that were not slivers, second to identify features intersecting other features, and finally another to identify features touching the boundary of other features. Once the select by locations were applied, the field “AdjacentSH” was calculated to identify the features as touching, intersecting or not touching other features. Features identified as not touching or intersecting were selected, then the select by location tool was used , set to select identical, to select these features from the dataset created in step 4 above. The records count was confirmed as matching between the two data sets and then these features were deleted. 530 of the 770 features were removed in total.6. Based on direction from the BLM Washington Office, the portion of the Upper Missouri River Breaks National Monument (UMRBNM) that was included in the FWS SFA dataset was removed. The BLM NOC GSSP NLCS dataset was used to erase these areas from #5 above. Resulting sliver polygons were also removed and geometry was repaired.7. In addition to removing UMRBNM, the BLM Washington Office also directed the removal of Non-ADPP habitat within the SFAs, on BLM managed lands, falling outside of Designated Wilderness’ & Wilderness Study Areas. An exception was the retention of the Donkey Hills ACEC and adjacent BLM lands. The BLM NOC GSSP NLCS datasets were used in conjunction with a dataset containing all ADPP habitat, BLM SMA and BLM sub-surface management unioned into one file to identify and delete these areas.8. The resulting dataset, after steps 2 – 8 above were completed, was dissolved to the SFA name field yielding this feature class with one record per SFA area.9. The "Acres" field was added and calculated.10. All areas within the Lander EIS were erased from the dataset (ArcGIS 'Erase' function) and resulting sliver geometries removed.11. Data were clipped to Proposed Plan PHMA.12. The "Acres" field was re-calculated

Complete accounting of all incorporated cities, including the boundary and name of each individual city. From 2009 to 2022 CAL FIRE maintained this dataset by processing and digitally capturing annexations sent by the state Board of Equalization (BOE). In 2022 CAL FIRE began sourcing data directly from BOE, in order to allow the authoritative department provide data directly. This data is then adjusted so it resembles the previous formats.Processing includes:• Clipping the dataset to traditional state boundaries• Erasing areas that span the Bay Area (derived from calw221.gdb)• Querying for incorporated areas only• Dissolving each incorporated polygon into a single feature• Calculating the COUNTY field to remove the word 'County'Version 24_1 is based on BOE_CityCounty_20240315, and includes all annexations present in BOE_CityAnx2023_20240315. Note: The Board of Equalization represents incorporated city boundaries as extending significantly into waterways, including beyond coastal boundaries. To see the representation in its original form please reference the datasets listed above.Note: The Board of Equalization represents incorporated city boundaries is extending significantly into waterways, including beyond coastal boundaries. To see the representation in its original form please reference the datasets listed above.

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpageunder LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/ It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherSalt Lake County Tax Exempt codes below:AE - Airport - ExemptCC - Commercial Common AreaCE - Conservation EasementCM - CemeteryEC - Exempt CharitableEE - Exempt EducationER - Exempt ReligiousGB - GreenbeltHE - Homeowners Assoc ExemptIL - In LieuIR - Irrigation CompanyMC - Master CardOE - Owner ExemptPE - Part ExemptPR - Pro-RatedPT - Privilege TaxPY - Privilege Tax on a YieldSA - State AssessedSC - State and Cnty AssessedSE - Special - ExemptSU - Salt Lake - Utah CntyTD - Divided Tax DistrictUI - Undivided_Interest TAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialSalt Lake County Property Class codes below:R - Residential / CondoC - CommercialI - IndustrialRE - RecreationalA - AgriculturalMH - Multi HousingMore information about the PROP_CLASS and PROP_TYPE for Salt Lake County can be found at http://slco.org/assessor/new/queryproptyp.cfmPROP_TYPE (expected) Text 100 - Single Family Res.,Townhome, CondoPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

AT_2004_HOWA

   File Geodatabase Feature Class


   Thumbnail Not Available

   Tags

   Socio-economic resources, Information, Social Institutions, Hierarchy, Territory, BES, Parcel, Property, Property View, A&T, Database, Assessors, Taxation




   Summary


   Serves as a basis for performing various analyses based on parcel data.


   Description


   Assessments & Taxation (A&T) Database from MD Property View 2004 for Howard County. The A&T Database contains parcel data from the State Department of Assessments and Taxation; it incorporates parcel ownership and address information, parcel valuation information and basic information about the land and structure(s) associated with a given parcel. These data form the basis for the 2004 Database, which also includes selected Computer Assisted Mass Appraisal (CAMA) characteristics, text descriptions to make parcel code field data more readily accessible and logical True/False fields which identify parcels with certain characteristics. Documentation for A&T, including a thorough definition for all attributes is enclosed. Complete Property View documentation can be found at http://www.mdp.state.md.us/data/index.htm under the "Technical Background" tab.


   It should be noted that the A&T Database consists of points and not parcel boundaries. For those areas where parcel polygon data exists the A&T Database can be joined using the ACCTID or a concatenation of the BLOCK and LOT fields, whichever is appropriate. (Spaces may have to be excluded when concatenating the BLOCK and LOT fields).


   A cursory review of the 2004 version of the A&T Database indicates that it has more accurate data when compared with the 2003 version, particularly with respect to dwelling types. However, for a given record it is not uncommon for numerous fields to be missing attributes. Based on previous version of the A&T Database it is also not unlikely that some of the information is inaccurate. This layer was edited to remove points that did not have a valid location because they failed to geocode. There were 1160 such points. A listing of the deleted points is in the table with the suffix "DeletedRecords."


   Credits


   Maryland Department of Planning


   Use limitations


   BES use only.


   Extent



   West -77.186932  East -76.699458 

   North 39.373967  South 39.099693 




   Scale Range

   There is no scale range for this item.

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 shapefile provides a worldwide geographic division by merging the World Continents division proposed by Esri Data and Maps (2024) to the Global Oceans and Seas version 1 division proposed by the Flanders Marine Institute (2021). Though divisions of continents and oceans/seas are available, the combination of both in a single shapefile is scarce.

The Continents and Oceans/Seas shapefile was carefully processed to remove overlaps between the inputs, and to fill gaps (i.e., areas with no information) by spatially joining these gaps to neighbour polygons. In total, the original world continents input divides land areas into 8 categories (Africa, Antarctica, Asia, Australia, Europe, North America, Oceania, and South America), while the original oceans/seas input divides the oceans/seas into 10 categories (Arctic Ocean, Baltic Sea, Indian Ocean, Mediterranean Region, North Atlantic Ocean, North Pacific Ocean, South Atlantic Ocean, South China and Easter Archipelagic Seas, South Pacific Ocean, and Southern Ocean). Therefore, the resulting world geographic division has 18 possible categories.

References

Esri Data and Maps (2024). World Continents. Available online at https://hub.arcgis.com/datasets/esri::world-continents/about. Accessed on 05 March 2024.

Flanders Marine Institute (2021). Global Oceans and Seas, version 1. Available online at https://www.marineregions.org/. https://doi.org/10.14284/542. Accessed on 04 March 2024.