Anyone who has taught GIS using Census Data knows it is an invaluable data set for showing students how to take data stored in a table and join it to boundary data to transform this data into something that can be visualised and analysed spatially. Joins are a core GIS skill and need to be learnt, as not every data set is going to come neatly packaged as a shapefile or feature layer with all the data you need stored within. I don't know how many times I taught students to download data as a table from Nomis, load it into a GIS and then join that table data to the appropriate boundary data so they could produce choropleth maps to do some visual analysis, but it was a lot! Once students had gotten the hang of joins using census data they'd often ask why this data doesn't exist as a prepackaged feature layer with all the data they wanted within it. Well good news, now a lot off it is and it's accessible through the Living Atlas! Don't get me wrong I fully understand the importance of teaching students how to perform joins but once you have this understanding if you can access data that already contains all the information you need then you should be taking advantage of it to save you time. So in this exercise I am going to show you how to load English and Welsh Census Data from the 2021 Census into the ArcGIS Map Viewer from the Living Atlas and produce some choropleth maps to use to perform visual analysis without having to perform a single join.

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

Initial Data Capture: Building were originally digitized using ESRI construction tools such as rectangle and polygon. Textron Feature Analyst was then used to digitize buildings using a semi-automated polygon capture tool as well as a fully automated supervised learning method. The method that proved to be most effective was the semi-automated polygon capture tool as the fully automated process produced polygons that required extensive cleanup. This tool increased the speed and accuracy of digitizing by 40%.Purpose of Data Created: To supplement our GIS viewers with a searchable feature class of structures within Ventura County that can aid in analysis for multiple agencies and the public at large.Types of Data Used: Aerial Imagery (Pictometry 2015, 9inch ortho/oblique, Pictometry 2018, 6inch ortho/oblique) Simi Valley Lidar Data (Q2 Harris Corp Lidar) Coverage of Data:Buildings have been collected from the aerial imageries extent. The 2015 imagery coverage the south county from the north in Ojai to the south in thousand oaks, to the east in Simi Valley, and to the West in the county line with Santa Barbara. Lockwood Valley was also captured in the 2015 imagery. To collect buildings for the wilderness areas we needed to use the imagery from 2007 when we last flew aerial imagery for the entire county. 2018 Imagery was used to capture buildings that were built after 2015.Schema: Fields: APN, Image Date, Image Source, Building Type, Building Description, Address, City, Zip, Data Source, Parcel Data (Year Built, Basement yes/no, Number of Floors) Zoning Data (Main Building, Out Building, Garage), First Floor Elevation, Rough Building Height, X/Y Coordinates, Dimensions. Confidence Levels/Methods:Address data: 90% All Buildings should have an address if they appear to be a building that would normally need an address (Main Residence). To create an address, we do a spatial join on the parcels from the centroid of a building polygon and extract the address data and APN. To collect the missing addresses, we can do a spatial join between the master address and the parcels and then the parcels back to the building polygons. Using a summarize to the APN field we will be able to identify the parcels that have multiple buildings and delete the address information for the buildings that are not a main residence.Building Type Data: 99% All buildings should have a building type according to the site use category code provided from the parcel table information. To further classify multiple buildings on parcels in residential areas, the shape area field was used to identify building polygons greater than 600 square feet as an occupied residence and all other buildings less than that size as outbuildings. All parcels, inparticular parcels with multiple buildings, are subject to classification error. Further defining could be possible with extensive quality control APN Data: 98% All buildings have received APN data from their associated parcel after a spatial join was performed. Building overlapping parcel lines had their centroid derived which allowed for an accurate spatial join.Troubleshooting Required: Buildings would sometimes overlap parcel lines making spatial joining inaccurate. To fix this you create a point from the centroid of the building polygon, join the parcel information to the point, then join the point with the parcel information back to the building polygon.

IntroductionIRWIN ArcGIS Online GeoPlatform Services The Integrated Reporting of Wildland-Fire Information (IRWIN) Production data is replicated every 60 seconds to the ArcGIS Online GeoPlatform organization so that read-only views can be provided for consumers. This replicated view is called the hosted datastore. The “IRWIN Data” group is a set of Feature Layer views based on the replicated IRWIN layers. These feature layers provide a near real-time feed of all valid IRWIN data. All incidents that have been shared through the integration service since May 20, 2014 are available through this service. The incident data provides the location of existing fires, size, conditions and several other attributes that help classify fires. The IRWIN Data service allows users to create a web map, share it with their organization, or pull it into ArcMap or ArcGIS Pro for more in-depth analysis.InstructionsTo allow the emergency management GIS staff to join the IRWIN Data group, they will need to set up an ArcGIS Online account through our account manager. Please send the response to Samantha Gibbes (Samantha.C.Gibbes@saic.com) and Kayloni Ahtong (kayloni_ahtong@ios.doi.gov). Use the below template and fill in each part as best as possible, where the point of contact (POC) is the person responsible for the account.Reply Email Body: The (name of application) application requests the following user account and access to the IRWIN Data group.POC Name: First name Last name and titlePOC Email: Username: <>_irwin (choose a username, something short, followed by _irwin)Business Justification: Once you are set up with the account, I will coordinate a call to go over any questions.

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.

Purpose

County 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 layer removes the coastal buffer polygons. This feature layer is for public use.

Related Layers

This dataset is part of a grouping of many datasets:

1. Cities: Only the city boundaries and attributes, without any unincorporated areas
   • With Coastal Buffers
   • Without Coastal Buffers
2. Counties: Full county boundaries and attributes, including all cities within as a single polygon
   • With Coastal Buffers
   • Without Coastal Buffers (this dataset)
3. Cities 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
   • Without Coastal Buffers
4. City and County Abbreviations
5. Unincorporated Areas (Coming Soon)
6. Census Designated Places
7. Cartographic Coastline
   • Polygon
   • Line source (Coming Soon)

Point of Contact

California Department of Technology, Office of Digital Services, gis@state.ca.gov

Field and Abbreviation Definitions

• CDTFA_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 Bureau
• CENSUS_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 System
• GNIS_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 county
• CENSUS_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.

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.

Purpose

County 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 Layers

This dataset is part of a grouping of many datasets:

1. Cities: Only the city boundaries and attributes, without any unincorporated areas
   • With Coastal Buffers
   • Without Coastal Buffers
2. Counties: Full county boundaries and attributes, including all cities within as a single polygon
   • With Coastal Buffers
   • Without Coastal Buffers
3. Cities 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 Buffers
4. Place Abbreviations
5. Unincorporated Areas (Coming Soon)
6. Census Designated Places (Coming Soon)
   
7. Cartographic Coastline
   • Polygon
   • Line source (Coming Soon)

Point of Contact

California Department of Technology, Office of Digital Services, odsdataservices@state.ca.gov

Field and Abbreviation Definitions

• 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
• Place Name: CDTFA incorporated (city) or county name
• 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.
• Legal Place Name: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information System
• GNIS_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 System
• Place Abbr: CalTrans Division of Local Assistance abbreviations of incorporated area names
• CNTY Abbr: CalTrans Division of Local Assistance abbreviations of county names
• Area_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.

Accuracy

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. COUNTY = county name; CITY = city name or unincorporated

NSO_SITE_SUMMARY_PUB_PT:This publication dataset joins the attributes and shape from NSO_SITE_PT to NSO_SUMMARY_TBL. The join between the two data objects is an outer join, which will result in a Site point record being duplicated for each Summary record it is related to. This data is only updated annually after the data entry has been completed for the previous years' field season.

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 March 2025. 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 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 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 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 layer removes the coastal buffer 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 BuffersWithout Coastal Buffers (this dataset)Cities 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)Working with Coastal BuffersThe dataset you are currently viewing excludes 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, odsdataservices@state.ca.govField 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

This data is utilized in the Lesson 1.1 What is Climate activity on the MI EnviroLearning Hub Climate Change page.Station data accessed was accessed from NOAA. Data was imported into ArcGIS Pro where Coordinate Table to Point was used to spatially enable the originating CSV. This feature service, which incorporates Census Designated Places from the U.S. Census Bureau’s 2020 Census Demographic and Housing Characteristics, was used to spatially join weather stations to the nearest incorporated area throughout Michigan.Email Egle-Maps@Michigan.gov for questions.Former name: MichiganStationswAvgs19912020_WithinIncoproatedArea_UpdatedName Display Name Field Name Description

STATION_ID MichiganStationswAvgs19912020_W Station ID where weather data is collected

STATION MichiganStationswAvgs19912020_1 Station name where weather data is collected

ELEVATION MichiganStationswAvgs19912020_6 Elevation above mean sea level-meters

MLY-PRCP-NORMAL MichiganStationswAvgs19912020_8 Long-term averages of monthly precipitation total-inches

MLY-TAVG-NORMAL MichiganStationswAvgs19912020_9 Long-term averages of monthly average temperature -F

OID MichiganStationswAvgs1991202_10 Object ID for weather dataset

Join_Count MichiganStationswAvgs1991202_11 Spatial join count of weather station data to specific weather station

TARGET_FID MichiganStationswAvgs1991202_12 Spatial Join ID

Current place ANSI code MichiganStationswAvgs1991202_13 Census codes for identification of geographic entities (used for join)

Geographic Identifier MichiganStationswAvgs1991202_14 Geographic identifier (used for join)

Current class code MichiganStationswAvgs1991202_15 Class (CLASSFP) code defines the current class of a geographic entity

Current functional status MichiganStationswAvgs1991202_16 Status of weather station

Area of Land (Square Meters) MichiganStationswAvgs1991202_17 Area of land in square meters

Area of Water (Square Meters) MichiganStationswAvgs1991202_18 Area of water in square meters

Current latitude of the internal point MichiganStationswAvgs1991202_19 Latitude

Current longitude of the internal point MichiganStationswAvgs1991202_20 Longitude

Name MichiganStationswAvgs1991202_21 Location name of weather station

Current consolidated city GNIS code MichiganStationswAvgs1991202_22 Geographic Names Information System for an incorporated area

OBJECTID MichiganStationswAvgs1991202_23 Object ID for point dataset

This feature class contains the simplified transect data from the 2000-2020 Puget Sound eelgrass monitoring dataset. This dataset is produced by the Submerged Vegetation Monitoring Program (SVMP) within the Washington Department of Natural Resources based on annual monitoring. This simplified transect data are in the form of lines that represent the paths of underwater video surveys that were subsequently classified for the presence of eelgrass, Z. japonica and surfgrass. These data were simplified from the more detailed transect point data for the purpose of supporting a map service. In addition, the attribute table for the simplified transects includes many additional attributes that are not included in the point data. These additional attributes were derived from other tables in the SVMP database through joins and summaries.This feature class is distributed in an ArcGIS file geodatabase. A separate geodatabase is distributed with the main spatial and tabular data for the 2000-2020 dataset. This data is public information that can be freely shared.

Land Joins GIS Layer is a spatial dataset that maps out how individual land parcels are connected—either by shared borders (adjacency) or by spatial relationships (e.g., overlapping, touching, or within a buffer). This layer is important for managing land ownership, supporting land development and planning infrastructure

Election Results | Join Data from 2020 General Election. All election results are official and have been certified by the Crawford County Pennsylvania Election Board

Author: Titus, Maxwell (mtitus@esri.com)Last Updated: 3/4/2025Intended Environment: ArcGIS ProPurpose: This Notebook was designed to automate updates for Hosted Feature Services hosted in ArcGIS Online (or ArcGIS Portal) from ArcGIS Pro and a spatial join of two live datasets.Description: This Notebook was designed to automate updates for Hosted Feature Services hosted in ArcGIS Online (or ArcGIS Portal) from ArcGIS Pro. An associated ArcGIS Dashboard would then reflect these updates. Specifically, this Notebook would:First, pull two datasets - National Weather Updates and Public Schools - from the Living Atlas and add them to an ArcGIS Pro map.Then, the Notebook would perform a spatial join on two layers to give Public Schools features information on whether they fell within an ongoing weather event or alert. Next, the Notebook would truncate the Hosted Feature Service in ArcGIS Online - that is, delete all the data - and then append the new data to the Hosted Feature ServiceAssociated Resources: This Notebook was used as part of the demo for FedGIS 2025. Below are the associated resources:Living Atlas Layer: NWS National Weather Events and AlertsLiving Atlas Layer: U.S. Public SchoolsArcGIS Demo Dashboard: Demo Impacted Schools Weather DashboardUpdatable Hosted Feature Service: HIFLD Public Schools with Event DataNotebook Requirements: This Notebook has the following requirements:This notebook requires ArcPy and is meant for use in ArcGIS Pro. However, it could be adjusted to work with Notebooks in ArcGIS Online or ArcGIS Portal with the advanced runtime.If running from ArcGIS Pro, connect ArcGIS Pro to the ArcGIS Online or ArcGIS Portal environment.Lastly, the user should have editable access to the hosted feature service to update.

Overview:This document describes the 2021 accessibility data released by the Accessibility Observatory at the University of Minnesota. The data are included in the National Accessibility Evaluation Project for 2021, and this information can be accessed for each state in the U.S. at https://access.umn.edu/research/america. The following sections describe the format, naming, and content of the data files.Data Formats: The data files are provided in a Geopackage format. Geopackage (.gpkg) files are an open-source, geospatial filetype that can contain multiple layers of data in a single file, and can be opened with most GIS software, including both ArcGIS and QGIS.Within this zipfile, there are six geopackage files (.gpkg) structured as follows. Each of them contains the blocks shapes layer, results at the block level for all LEHD variables (jobs and workers), with a layer of results for each travel time (5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60 minutes). {MPO ID}_tr_2021_0700-0859-avg.gpkg = Average Transit Access Departing Every Minute 7am-9am{MPO ID}_au_2021_08.gpkg = Average Auto Access Departing 8am{MPO ID}_bi_2021_1200_lts1.gpkg = Average Bike Access on LTS1 Network{MPO ID}_bi_2021_1200_lts2.gpkg = Average Bike Access on LTS2 Network{MPO ID}_bi_2021_1200_lts3.gpkg = Average Bike Access on LTS3 Network{MPO ID}_bi_2021_1200_lts4.gpkg = Average Bike Access on LTS4 NetworkFor mapping and geospatial analysis, the blocks shape layer within each geopackage can be joined to the blockid of the access attribute data. Opening and Using Geopackages in ArcGIS:Unzip the zip archiveUse the "Add Data" function in Arc to select the .gpkg fileSelect which layer(s) are needed — always select "main.blocks" as this layer contains the Census block shapes; select any other attribute data layers as well.There are three types of layers in the geopackage file — the "main.blocks" layer is the spatial features layer, and all other layers are either numerical attribute data tables, or the "fieldname_descriptions" metadata layer. The numerical attribute layers are named with the following format:[mode]_[threshold]_minutes[mode] is a two-character code indicating the transport mode used[threshold] is an integer indicating the travel time threshold used for this data layerTo use the data spatially, perform a join between the "main.blocks" layer and the desired numerical data layer, using either the numerical "id" fields, or 15-digit "blockid" fields as join fields.

This layer was created to serve as a guide as to the placement of original property boundaries prior to being subdivided or merged together in accordance with assessment data in subdivisions platted in the 1950's and 60's and of property with plats that did not clearly state that property lines were being removed. This layer was NOT created at survey level accuracy. Also contained in this dataset are private right of way easements, and parcel joins.

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

New dataset https://mto-on-ca.maps.arcgis.com/home/item.html?id=54fb115a856843629ece14db3308a599This is non-directional option that provides input data on traveling direction links, including AADTT, vehicle class distribution, number of axle per truck, and axle load distribution for AASHTOWare Pavement ME Design. This program can generate the following three data files for any specific LHRS sections: Traffic data input file in XML format that contains the AADTT, vehicle class distribution, axle per truck, and axle spacing & configuration. Axle load spectrum file in ALF format that contains the axle load spectrum tables of single, tandem, tridem and quad axle types. A summary file in spreadsheet format that contains the above traffic data. The above XMF and ALF files can be directly input into AASHTOWare Pavement ME Design to run the analysis. If traffic data is insufficient within the LHRS section, the tables for Southern or Northern Ontario will be generated.VF04 StringTruck flow volume of FHWA vehicle class 4VF05 StringTruck flow volume of FHWA vehicle class 5VF06 StringTruck flow volume of FHWA vehicle class 6VF07 StringTruck flow volume of FHWA vehicle class 7VF08 StringTruck flow volume of FHWA vehicle class 8VF09 StringTruck flow volume of FHWA vehicle class 9VF10 StringTruck flow volume of FHWA vehicle class 10VF11 StringTruck flow volume of FHWA vehicle class 11VF12 StringTruck flow volume of FHWA vehicle class 12VF13 StringTruck flow volume of FHWA vehicle class 13SUMAADTT06 Stringtotal truck traffic volume of FHWA vehicle class 4 - 13PF04 StringTruck flow percentage of FHWA vehicle class 4PF05 StringTruck flow percentage of FHWA vehicle class 5PF06 StringTruck flow percentage of FHWA vehicle class 6PF07 StringTruck flow percentage of FHWA vehicle class 7PF08 StringTruck flow percentage of FHWA vehicle class 8PF09 StringTruck flow percentage of FHWA vehicle class 9PF10 StringTruck flow percentage of FHWA vehicle class 10PF11 StringTruck flow percentage of FHWA vehicle class 11PF12 StringTruck flow percentage of FHWA vehicle class 12PF13 StringTruck flow percentage of FHWA vehicle class 13

The blank geodatabase has the required fields for submitting wetland determination polygons and requested map edits for the Vermont Significant Wetlands Inventory. The valid NWI codes are included in the a separate table inside the file geodatabase. Consider joining the Wetland Program's ArcGIS Online Group for submitting determination or wetlands edits. If your organization has an ArcGIS organizational account, make a request to join this group:https://www.arcgis.com/home/group.html?id=164aab9de6e44ec79aa0dfa7ee41dfcb#overviewJoin a groupTo join a group, do the following:Verify that you are signed in.Click Groups at the top of the site, and use the tabs, filters, sort options, and search as needed to find the group you want to join.Click the name of the group to open its group page.On the Overview tab, click Join this group. If necessary, click Submit Request.Depending on the group's membership settings, you will see a message indicating that you are now a member of the group or that your request has been sent to the group owner (after clicking Submit Request). If a request is sent, the owner of the group sees it on the group page and accepts or denies your request for membership. If the owner accepts your request, you are added as a member, and the group appears on your Groups page.

This dataset represents all real property parcels within the City of Charlottesville, Virginia that are owned by the City of Charlottesville or the City School Board. It includes detailed polygon geometry of parcel boundaries and joins authoritative ownership data from the parcel points layer to identify parcels currently held by the City. The data is filtered using a dynamic view that identifies ownership using common naming conventions found in city records. This includes ownership by the City of Charlottesville, City School Board, and other variations used in tax assessment and land records. Fields Included:OBJECTID: Internal database identifierGPIN: Geographic Parcel Identification NumberOWNER: Current owner name (e.g., "City of Charlottesville")SHAPE: Polygon geometry representing parcel boundaries Source & Processing Notes:Based on authoritative data from the City’s GIS parcel datasets (parcel_area and parcel_point)Ownership identified via dynamic SQL view matching typical City and School Board naming conventionsOWNER LIKE 'CITY OF CH''VILLE%'pt.OWNER LIKE 'CITY OF CHARLOTTESVILLE%'pt.OWNER LIKE 'CITY OF, CH''VILLE%'pt.OWNER LIKE 'CITY OF, CHARLOTTESVILLE%'pt.OWNER LIKE 'CITY, OF CHARLOTTESVILLE%'pt.OWNER LIKE 'SCHOOL BD-CITY OF CH''VILLE%'pt.OWNER LIKE 'SCHOOL BOARD%'pt.OWNER LIKE 'SCHOOL, BD-OF CH''VILLE%'pt.OWNER LIKE 'SCHOOL, BOARD OF%'Spatial joins ensure parcel geometry is directly linked to ownership point recordsUpdated regularly to reflect current ownership from tax and assessor records