This dataset was created to be used in my Capstone Project for the Google Data Analytics Professional Certificate. Data was web scraped from the state websites to combine the GIS information like FIPS, latitude, longitude, and County Codes by both number and Mailing Number.

RStudio was used for this web scrape and join. For details on how it was done you can go to the following link for my Github repository.

Feel free to follow my Github or LinkedIn profile to see what I end up doing with this Dataset.

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.

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.

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

Feature layer generated from running the Find Centroids solution for Join_CSC_Features_to_NYS_Civil_Boundaries_SHP_Cities_Towns.

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

Have you ever wanted to create your own maps, or integrate and visualize spatial datasets to examine changes in trends between locations and over time? Follow along with these training tutorials on QGIS, an open source geographic information system (GIS) and learn key concepts, procedures and skills for performing common GIS tasks – such as creating maps, as well as joining, overlaying and visualizing spatial datasets. These tutorials are geared towards new GIS users. We’ll start with foundational concepts, and build towards more advanced topics throughout – demonstrating how with a few relatively easy steps you can get quite a lot out of GIS. You can then extend these skills to datasets of thematic relevance to you in addressing tasks faced in your day-to-day work.

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

The towns of Connecticut (CT) Parcels and Computer-Assisted Mass Appraisal (CAMA) data for 2022 are part of a zipped file containing two items: CT parcels in geodatabases organized by COGs and associated CAMA files.

The parcel information includes 169 out of 169 town organized with geodatabases for each of the 9 Council of Governments. Most of the parcel data sets can be linked to the CAMA data which has attribute information (e.g. value of house, number of bedrooms) about real property. The parcel features for each town are in shape files, feature classes, or within a geodatabase. Most parcels are organized by town and COG and placed within a geodatabases.

The CAMA data sets have information about real property within the towns of CT. It may be linked to the parcels using a join process within a GIS package like ArcGIS Pro or QGIS. 154 out of 169 towns have complete CAMA information. Of the remaining 15 towns, four have no information and the remaining have some limited information mixed into the parcel attribute tables. These files were gathered from the CT towns by the COGs and then submitted to CT OPM. Town data is organized by COG. Attribute names, primary key, secondary key, naming conventions, and file formats are not fully consistent but some cleaning and reorganization was conducted to improve quality. This file was created on 03/08/2023 from data collected in 2021-2022.

Maps have always been a powerful tool for visualizing data. Participants will learn how to link the static data of census tables to census geographies by using open-source GIS software. Participants will learn how to join data, calculate new attributes, symbolize geography and create maps. No prior GIS experience is necessary. QGIS will be required to be downloaded prior to the workshop, and laptops will be required. Download instructions https://qgis.org/en/site/forusers/download.html. Download data files https://drive.google.com/drive/folders/1xrAj_BrPtMDBgdi9MXWGcrcuVGfTsGgi?usp=sharing

This specialized location dataset delivers detailed information about marina establishments. Maritime industry professionals, coastal planners, and tourism researchers can leverage precise location insights to understand maritime infrastructure, analyze recreational boating landscapes, and develop targeted strategies.

How Do We Create Polygons?

-All our polygons are manually crafted using advanced GIS tools like QGIS, ArcGIS, and similar applications. This involves leveraging aerial imagery, satellite data, and street-level views to ensure precision. -Beyond visual data, our expert GIS data engineers integrate venue layout/elevation plans sourced from official company websites to construct highly detailed polygons. This meticulous process ensures maximum accuracy and consistency. -We verify our polygons through multiple quality assurance checks, focusing on accuracy, relevance, and completeness.

What's More?

-Custom Polygon Creation: Our team can build polygons for any location or category based on your requirements. Whether it’s a new retail chain, transportation hub, or niche point of interest, we’ve got you covered. -Enhanced Customization: In addition to polygons, we capture critical details such as entry and exit points, parking areas, and adjacent pathways, adding greater context to your geospatial data. -Flexible Data Delivery Formats: We provide datasets in industry-standard GIS formats like WKT, GeoJSON, Shapefile, and GDB, making them compatible with various systems and tools. -Regular Data Updates: Stay ahead with our customizable refresh schedules, ensuring your polygon data is always up-to-date for evolving business needs.

Unlock the Power of POI and Geospatial Data

With our robust polygon datasets and point-of-interest data, you can: -Perform detailed market and location analyses to identify growth opportunities. -Pinpoint the ideal locations for your next store or business expansion. -Decode consumer behavior patterns using geospatial insights. -Execute location-based marketing campaigns for better ROI. -Gain an edge over competitors by leveraging geofencing and spatial intelligence.

Why Choose LocationsXYZ?

LocationsXYZ is trusted by leading brands to unlock actionable business insights with our accurate and comprehensive spatial data solutions. Join our growing network of successful clients who have scaled their operations with precise polygon and POI datasets. Request your free sample today and explore how we can help accelerate your business growth.

Feature layer generated from running the Join Features solution

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.

A comprehensive dataset of 1,513 Pakistani cities, towns, tehsils, districts and places with latitude/longitude, administrative region, population (when available) and Wikidata IDs — ideal for mapping, geospatial analysis, enrichment, and location-based ML.

Why this dataset is valuable:

• Full geocoordinates for every entry (100% coverage) — ready for mapping and spatial joins.
• Wide geographic coverage across all 7 major regions of Pakistan (provinces / administrative regions).
• Wikidata IDs included for reliable cross-referencing and automatic enrichment from external knowledge bases.
• Useful for data scientists, GIS engineers, civic tech projects, academic research, and startups building Pakistan-focused location services.

Highlights (fetched from the data):

• Total rows: 1,513
• Unique places (city field): 1,497
• Rows with population > 0: 526 (≈34.8%)
• Coordinate coverage: 1513 / 1513 (100%) — directly usable with mapping libraries.

Column definitions (short):

• id — Internal numeric row id (unique integer).
• wikiDataId — Wikidata QID (e.g., Q####) for the place; use to fetch rich metadata.
• type — Administrative/place type (e.g., ADM1, ADM2, city, district, tehsil).
• city — Common/local city/place name (short label).
• name — Full name / official name of the place (may include “District”, “Tehsil”, etc.).
• country — Country name (Pakistan).
• countryCode — ISO country code (e.g., PK).
• region — Primary administrative region / province (e.g., Punjab, Sindh).
• regionCode — Short code for region (e.g., PB, KP depending on your encoding).
• regionWdId — Wikidata QID for the region.
• latitude — Latitude in decimal degrees (float).
• longitude — Longitude in decimal degrees (float).
• population — Integer population (0 or NA where unknown).

Typical & high-value use cases:

• Mapping & visualization: choropleth maps, point overlays, heatmaps of population or density.
• Geospatial analysis: distance calculations, nearest-neighbor queries, clustering of urban centers.
• Data enrichment: join with other datasets (OpenStreetMap, Wikidata, census data) using wikiDataId and coordinates.
• Machine learning & NLP: training geolocation models, geoparsing, toponym resolution, place name disambiguation.
• Urban planning & research: analyze distribution of population-ready places vs administrative units.
• Mobile / location-based apps: lookup & reverse geocoding fallback, seeding POI databases for Pakistan.
• Humanitarian & disaster response: baseline location lists for logistics and situational awareness.

MassGIS Level 3 Parcel Data: Data Fiscal Year: Aquinnah 2019, Chilmark 2021, Edgartown 2021, Gosnold 2015, Oak Bluffs 2021, Tisbury 2021, West Tisbury 2021.Building Info Table: Acquired by MVC from Town Assessors in FY20.Downloaded from MassGIS,, this polygon file represents the parcel bounds for the 7 towns in Dukes County MA (Aquinnah, Chilmark, Edgartown, Godnold, Oak Bluffs, Tisbury, West Tisbury). Each town has their own parcel data consultant and then the data are forwarded to MassGIS for final processing. All data comply with the MassGIS Level 3 Parcel Data Standard. This file geodatabase only includes the TaxPar feature class and Assess table for each town. All TaxPar feature classes were appended into one feature class (Parcels_duk) by the MVC.Each assess table is utilized in that town's respective relationship join (1 to Many) for linking the parcel polygon to the related record(s) in the Assess table. The Assess Table contains info about ownership and assessed values. This is not a detailed building table. If there are multiple owners associated with a property, then the Assess table will have multiple records for that property/parcel (such as for condo parcels).Each building table is utilized in that town's respective relationship join (1 to Many) for linking the parcel polygon to the related record(s) in the Bldg table. The Bldg (building) table contains info about each building on the parcel (such as number of bedrooms, number of bathrooms, the living area square footage, etc.). NOTES of CAUTION: The Living Area Square Footage may not represent the exact same thing in each town. As a generalization, Living Area is interior space that is heated. Regarding West Tisbury, their building table only contains info for one building on the parcel. It is uncertain at this time if the info is the most recent, most primary, or some kind of summarization where multiple buildings on a parcel exist.The field of [assess_mYB] represents the Minimum/Earliest Year Built for any building on the parcel and is appended to the TaxPar feature class based on an analysis of the info provided in the building table. This field [assess_mYB] is utilized in the Historic Structures App found in ArcGIS OnLine.

This feature class was derived from the GIS polygon dataset BLM Grazing Allotments which was downloaded from the Geospatial Gateway in April 2025. Fields were added to the feature classes and calculated as needed to allow the Rangeland Administration System (RAS) tabular data to be joined to the GIS datasets. RAS tabular data for Authorized allotments and pastures (as of April 2025) was provided by BLM Rangeland Management Specialist Josh Robbins in April 2025 and processed as dbfs, with fields added and calculated as needed to match the BLM GIS Grazing Allotments feature class. RAS tables and BLM GIS data for allotments were joined using the State Allotment Number, a concatenation of allotment number and BLM Administrative State for allotments (ST_ALLOT_NUM). RAS records for Authorized Allotments that did not match during a join operation were tracked in a separate excel sheet from the matching records. Matching records were then joined back to the BLM GIS Allotments grazing feature class and Allotment name fields were edited as necessary. A Status field was added to indicate if the data are either Billed or Authorized and a Source field was added to indicate that the data came from Allotments or Trailing Allotments. An additional field, TR_ALLOT_NUM, was added to designate any Trailing Allotments in the data. Trailing allotments were identified and processed separately for Nevada, since these allotments overlap portions of other allotments. Any overlaps in the data were removed via dissolve and Spatial Join.Input BLM GIS Grazing data:BLM Grazing Pastures and BLM Grazing Allotments are areas of land designated and managed for grazing of livestock. It may include private, state, and public lands under the jurisdiction of the Bureau of Land Management and/or other federal agencies. An allotment is derived from its pastures, where the grazing of livestock is occurring. The attributes of the BLM Grazing Allotment features may be duplicated in RAS, but are considered to be minimum information for unique identification and cartographic purposes.Input RAS Data:The Rangeland Administration System (RAS) provides grazing administrative support and management reports for the BLM and the public. The Rangeland Administration system serves as an electronic calendar for issuance of applications and grazing authorizations, including Permits, Leases, and Exchange-of-Use Agreements. The Authorized data is current as of April 2025 and was provided by BLM Rangeland Management Specialist Josh Robbins in April 2025.

This dataset is one of several segments of a regional high detailed stream flowpath dataset. The data was separated using the TOPO 50 map series extents.The stream network was originally created for the purpose of high detailed work along rivers and streams in the Wellington region. It was started as a pilot study for the Mangatarere subcatchment of the Waiohine River for the Environmental Sciences department who was attempting to measure riparian vegetation. The data was sourced from a modelled stream network created using the 2013 LiDAR digital elevation model. Once the Mangatarere was complete the process was expanded to cover the entire region on an as needed basis for each whaitua. This dataset is one of several that shows the finished stream datasets for the Wairarapa region.The base stream network was created using a mixture of tools found in ArcGIS Spatial Analyst under Hydrology along with processes located in the Arc Hydro downloadable add-on for ArcGIS. The initial workflow for the data was based on the information derived from the help files provided at the Esri ArcGIS 10.1 online help files. The updated process uses the core Spatial Analyst tools to generate the streamlines while digital dams are corrected using the DEM Reconditioning tool provided by the Arc Hydro toolset. The whaitua were too large for processing separated into smaller units according to the subcatchments within it. In select cases like the Taueru subcatchment of the Ruamahanga these subcatchments need to be further defined to allow processing. The catchment boundaries available are not as precise as the LiDAR information which causes overland flows that are on edges of the catchments to become disjointed from each other and required manual correction.Attributes were added to the stream network using the River Environment Classification (REC) stream network from NIWA. The Spatial Join tool in Arcmap was used to add the Reach ID to each segment of the generated flow path. This ID was used to join a table which had been created by intersecting stream names (generated from a point feature class available from LINZ) with the REC subcatchment dataset. Both of the REC datasets are available from NIWA's website.

Feature layer generated from running the Find Centroids solution for Join_Features_(2)_to_NYS_Civil_Boundaries_SHP_Villages.