Overview The Office of the Geographer and Global Issues at the U.S. Department of State produces the Large Scale International Boundaries (LSIB) dataset. The current edition is version 11.4 (published 24 February 2025). The 11.4 release contains updated boundary lines and data refinements designed to extend the functionality of the dataset. These data and generalized derivatives are the only international boundary lines approved for U.S. Government use. The contents of this dataset reflect U.S. Government policy on international boundary alignment, political recognition, and dispute status. They do not necessarily reflect de facto limits of control. National Geospatial Data Asset This dataset is a National Geospatial Data Asset (NGDAID 194) managed by the Department of State. It is a part of the International Boundaries Theme created by the Federal Geographic Data Committee. Dataset Source Details Sources for these data include treaties, relevant maps, and data from boundary commissions, as well as national mapping agencies. Where available and applicable, the dataset incorporates information from courts, tribunals, and international arbitrations. The research and recovery process includes analysis of satellite imagery and elevation data. Due to the limitations of source materials and processing techniques, most lines are within 100 meters of their true position on the ground. Cartographic Visualization The LSIB is a geospatial dataset that, when used for cartographic purposes, requires additional styling. The LSIB download package contains example style files for commonly used software applications. The attribute table also contains embedded information to guide the cartographic representation. Additional discussion of these considerations can be found in the Use of Core Attributes in Cartographic Visualization section below. Additional cartographic information pertaining to the depiction and description of international boundaries or areas of special sovereignty can be found in Guidance Bulletins published by the Office of the Geographer and Global Issues: https://data.geodata.state.gov/guidance/index.html Contact Direct inquiries to internationalboundaries@state.gov. Direct download: https://data.geodata.state.gov/LSIB.zip Attribute Structure The dataset uses the following attributes divided into two categories: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | Core CC1_GENC3 | Extension CC1_WPID | Extension COUNTRY1 | Core CC2 | Core CC2_GENC3 | Extension CC2_WPID | Extension COUNTRY2 | Core RANK | Core LABEL | Core STATUS | Core NOTES | Core LSIB_ID | Extension ANTECIDS | Extension PREVIDS | Extension PARENTID | Extension PARENTSEG | Extension These attributes have external data sources that update separately from the LSIB: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | GENC CC1_GENC3 | GENC CC1_WPID | World Polygons COUNTRY1 | DoS Lists CC2 | GENC CC2_GENC3 | GENC CC2_WPID | World Polygons COUNTRY2 | DoS Lists LSIB_ID | BASE ANTECIDS | BASE PREVIDS | BASE PARENTID | BASE PARENTSEG | BASE The core attributes listed above describe the boundary lines contained within the LSIB dataset. Removal of core attributes from the dataset will change the meaning of the lines. An attribute status of “Extension” represents a field containing data interoperability information. Other attributes not listed above include “FID”, “Shape_length” and “Shape.” These are components of the shapefile format and do not form an intrinsic part of the LSIB. Core Attributes The eight core attributes listed above contain unique information which, when combined with the line geometry, comprise the LSIB dataset. These Core Attributes are further divided into Country Code and Name Fields and Descriptive Fields. County Code and Country Name Fields “CC1” and “CC2” fields are machine readable fields that contain political entity codes. These are two-character codes derived from the Geopolitical Entities, Names, and Codes Standard (GENC), Edition 3 Update 18. “CC1_GENC3” and “CC2_GENC3” fields contain the corresponding three-character GENC codes and are extension attributes discussed below. The codes “Q2” or “QX2” denote a line in the LSIB representing a boundary associated with areas not contained within the GENC standard. The “COUNTRY1” and “COUNTRY2” fields contain the names of corresponding political entities. These fields contain names approved by the U.S. Board on Geographic Names (BGN) as incorporated in the ‘"Independent States in the World" and "Dependencies and Areas of Special Sovereignty" lists maintained by the Department of State. To ensure maximum compatibility, names are presented without diacritics and certain names are rendered using common cartographic abbreviations. Names for lines associated with the code "Q2" are descriptive and not necessarily BGN-approved. Names rendered in all CAPITAL LETTERS denote independent states. Names rendered in normal text represent dependencies, areas of special sovereignty, or are otherwise presented for the convenience of the user. Descriptive Fields The following text fields are a part of the core attributes of the LSIB dataset and do not update from external sources. They provide additional information about each of the lines and are as follows: ATTRIBUTE NAME | CONTAINS NULLS RANK | No STATUS | No LABEL | Yes NOTES | Yes Neither the "RANK" nor "STATUS" fields contain null values; the "LABEL" and "NOTES" fields do. The "RANK" field is a numeric expression of the "STATUS" field. Combined with the line geometry, these fields encode the views of the United States Government on the political status of the boundary line. ATTRIBUTE NAME | | VALUE | RANK | 1 | 2 | 3 STATUS | International Boundary | Other Line of International Separation | Special Line A value of “1” in the “RANK” field corresponds to an "International Boundary" value in the “STATUS” field. Values of ”2” and “3” correspond to “Other Line of International Separation” and “Special Line,” respectively. The “LABEL” field contains required text to describe the line segment on all finished cartographic products, including but not limited to print and interactive maps. The “NOTES” field contains an explanation of special circumstances modifying the lines. This information can pertain to the origins of the boundary lines, limitations regarding the purpose of the lines, or the original source of the line. Use of Core Attributes in Cartographic Visualization Several of the Core Attributes provide information required for the proper cartographic representation of the LSIB dataset. The cartographic usage of the LSIB requires a visual differentiation between the three categories of boundary lines. Specifically, this differentiation must be between: International Boundaries (Rank 1); Other Lines of International Separation (Rank 2); and Special Lines (Rank 3). Rank 1 lines must be the most visually prominent. Rank 2 lines must be less visually prominent than Rank 1 lines. Rank 3 lines must be shown in a manner visually subordinate to Ranks 1 and 2. Where scale permits, Rank 2 and 3 lines must be labeled in accordance with the “Label” field. Data marked with a Rank 2 or 3 designation does not necessarily correspond to a disputed boundary. Please consult the style files in the download package for examples of this depiction. The requirement to incorporate the contents of the "LABEL" field on cartographic products is scale dependent. If a label is legible at the scale of a given static product, a proper use of this dataset would encourage the application of that label. Using the contents of the "COUNTRY1" and "COUNTRY2" fields in the generation of a line segment label is not required. The "STATUS" field contains the preferred description for the three LSIB line types when they are incorporated into a map legend but is otherwise not to be used for labeling. Use of the “CC1,” “CC1_GENC3,” “CC2,” “CC2_GENC3,” “RANK,” or “NOTES” fields for cartographic labeling purposes is prohibited. Extension Attributes Certain elements of the attributes within the LSIB dataset extend data functionality to make the data more interoperable or to provide clearer linkages to other datasets. The fields “CC1_GENC3” and “CC2_GENC” contain the corresponding three-character GENC code to the “CC1” and “CC2” attributes. The code “QX2” is the three-character counterpart of the code “Q2,” which denotes a line in the LSIB representing a boundary associated with a geographic area not contained within the GENC standard. To allow for linkage between individual lines in the LSIB and World Polygons dataset, the “CC1_WPID” and “CC2_WPID” fields contain a Universally Unique Identifier (UUID), version 4, which provides a stable description of each geographic entity in a boundary pair relationship. Each UUID corresponds to a geographic entity listed in the World Polygons dataset. These fields allow for linkage between individual lines in the LSIB and the overall World Polygons dataset. Five additional fields in the LSIB expand on the UUID concept and either describe features that have changed across space and time or indicate relationships between previous versions of the feature. The “LSIB_ID” attribute is a UUID value that defines a specific instance of a feature. Any change to the feature in a lineset requires a new “LSIB_ID.” The “ANTECIDS,” or antecedent ID, is a UUID that references line geometries from which a given line is descended in time. It is used when there is a feature that is entirely new, not when there is a new version of a previous feature. This is generally used to reference countries that have dissolved. The “PREVIDS,” or Previous ID, is a UUID field that contains old versions of a line. This is an additive field, that houses all Previous IDs. A new version of a feature is defined by any change to the
The USGS Governmental Unit Boundaries dataset from The National Map (TNM) represents major civil areas for the Nation, including States or Territories, counties (or equivalents), Federal and Native American areas, congressional districts, minor civil divisions, incorporated places (such as cities and towns), and unincorporated places. Boundaries data are useful for understanding the extent of jurisdictional or administrative areas for a wide range of applications, including mapping or managing resources, and responding to natural disasters. Boundaries data also include extents of forest, grassland, park, wilderness, wildlife, and other reserve areas useful for recreational activities, such as hiking and backpacking. Boundaries data are acquired from a variety of government sources. The data represents the source data with minimal editing or review by USGS. Please refer to the feature-level metadata for information on the data source. The National Map boundaries data is commonly combined with other data themes, such as elevation, hydrography, structures, and transportation, to produce general reference base maps. The National Map viewer allows free downloads of public domain boundaries data in either Esri File Geodatabase or Shapefile formats. For additional information on the boundaries data model, go to https://nationalmap.gov/boundaries.html.
The dataset is available to download in Geotiff format at a resolution of 3 arc-second (approximately 100m at the equator). The projection is Geographic Coordinate System, WGS84. Grid cell values represent International Standard 3-digit numerical ISO 3166 Country Codes corresponding to country and territory names as designated by the United Nations (ISO, 2017). It is important to note that these data are not official representations of country boundaries, some of which are disputed, but simply represent the source of the population count data.Data Source: Global national level input population data-summaryMethodology: Lloyd, C. T., H. Chamberlain, D. Kerr, G. Yetman, L. Pistolesi, F. R. Stevens, A. E. Gaughan, J. J. Nieves, G. Hornby, K. MacManus, P. Sinha, M. Bondarenko, A. Sorichetta, and A. J. Tatem, 2019. “Global Spatio-temporally Harmonised Datasets for Producing High-resolution Gridded Population Distribution Datasets”. Big Earth Data (https://doi.org/10.1080/20964471.2019.1625151).
ATTOM’s census boundary data includes various geographies with a large range of sizes, population, and governmental functions. These datasets enable property searches for familiar named areas such as counties, cities, and townships. The included boundaries can be utilized for census boundary map overlays.
Attribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
World Bank-approved administrative boundaries (Admin 0) (and polygons) including international boundaries, disputed areas, coastlines, and lakes. Boundaries are available as an ESRI GeoDatabase, in GeoJSON, a shapefile and API endpoints for interactive maps.
This line feature layer contains Legal City boundaries within Los Angeles County.
The principal attribute is BDRY_TYPE which represents the boundary feature types. Use its values below for definition queries and layer symbology for your mapping needs.
Coast - This value represents the coastline. This data is carefully maintained by DPW staff, based Los Angeles Region Imagery Acquisition Consortium data.
Land City - This value represents city boundaries on land.
Land County - This value represents the county boundary on land.
Pier - One example is the Santa Monica Pier. Man-made features may be regarded as extensions of the coastline.
Breakwater - Examples include the breakwater barriers that protect the Los Angeles Harbor.
Water - This value is used to separate features representing internal navigable waters and the ocean. Examples of internal waters are found in the Long Beach Harbor and in Marina del Rey.
Ocean - This value is used to represent ocean boundaries between cities in addition to the seaward boundaries of coastal cities. Per the Submerged Lands Act, the seaward boundaries of coastal cities and unincorporated county areas are three nautical miles (a nautical mile is 1852 meters) from the coastline.
An in-depth description of the various Political Boundaries GIS data layers outlining terms of use, update frequency, attribute explanations, and more. District data layers include: Lake County Boundary, County Board, Judicial Circuit Court Subcircuits, Political Townships, State Representative Districts, State Senate, Congressional Districts, and Voting Precincts.
MIT Licensehttps://opensource.org/licenses/MIT
License information was derived automatically
This is a layer of water service boundaries for 45,973 community water systems that deliver tap water to 307.7 million people in the US. This amounts to 97% of the population reportedly served by active community water systems and 93% of active community water systems. The layer is based on multiple data sources and a methodology developed by SimpleLab and collaborators called a Tiered, Explicit, Match, and Model approach–or TEMM, for short. The name of the approach reflects exactly how the nationwide data layer was developed. The TEMM is composed of three hierarchical tiers, arranged by data and model fidelity. First, we use explicit water service boundaries provided by states. These are spatial polygon data, typically provided at the state-level. We call systems with explicit boundaries Tier 1. In the absence of explicit water service boundary data, we use a matching algorithm to match water systems to the boundary of a town or city (Census Place TIGER polygons). When multiple water systems match to the same TIGER boundary, we employ a "best match" algorithm that assigns one water system to one TIGER place based on features like population served and other locational information about the water system. Finally, in the absence of an explicit water service boundary (Tier 1) or a TIGER place polygon match (Tier 2), a statistical model trained on explicit water service boundary data (Tier 1) is used to estimate a reasonable radius at provided water system centroids, and model a spherical water system boundary (Tier 3). Water system centroids are taken from the ECHO database; however, where a system centroid is labeled as a county or state centroid, we take several steps to assign a better centroid (using sources like UCMR or TIGER). A summary of the systems and population assigned to different tiers is as follows:
Population coverage rates per Tier, for systems with population reported: - Tier 1: 49.3% population covered (155,869,771 people) - Tier 2: 35.13% population covered (111,074,087 people) - Tier 3: 12.9% population covered (40,771,645 people)
Active community water systems coverage rates per Tier: - Tier 1: 35.7% system covered (17645 systems) - Tier 2: 22.42% system covered (11079 systems) - Tier 3: 34.9% system covered (17249 systems) - No Tier/Geometry: 6.98% system covered (3451 systems)
Several limitations to this data exist–and the layer should be used with these in mind. The case of assigning a Census Place TIGER polygon to the "best match" water system first introduced in v2.0.0 requires further validation. Tier 3 boundaries have modeled radii stemming from a lat/long centroid of a water system facility; but the underlying lat/long centroids for water system facilities are of variable quality. It is critical to evaluate the "geometry quality" column (included from the EPA ECHO data source) when looking at Tier 3 boundaries; fidelity is very low when geometry quality is a county or state centroid– but we did not exclude the data from the layer. Since v 2.0.0 we have improved the percentage of Tier 3 geometries with state centroids and county centroids from 50% of Tier 3 boundaries to 30% of Tier 3 boundaries. Missing water systems are typically those without a centroid, in a U.S. territory, or missing population and connection data. Finally, Tier 1 systems are assumed to be high fidelity, but rely on the accuracy of state data collection and maintenance.
Changelog:
geometry_source_detail
column to, where possible, include notes provided by the data sources themselves about how the geometry was sourcedMIT Licensehttps://opensource.org/licenses/MIT
License information was derived automatically
(Link to Metadata) The BNDHASH dataset depicts Vermont village, town, county, and Regional Planning Commission (RPC) boundaries. It is a composite of generally 'best available' boundaries from various data sources (refer to ARC_SRC and SRC_NOTES attributes). However, this dataset DOES NOT attempt to provide a legally definitive boundary. The layer was originally developed from TBHASH, which was the master VGIS town boundary layer prior to the development and release of BNDHASH. By integrating village, town, county, RPC, and state boundaries into a single layer, VCGI has assured vertical integration of these boundaries and simplified maintenance. BNDHASH also includes annotation text for town, county, and RPC names. BNDHASH includes the following feature classes: 1) BNDHASH_POLY_VILLAGES = Vermont villages 2) BNDHASH_POLY_TOWNS = Vermont towns 3) BNDHASH_POLY_COUNTIES = Vermont counties 4) BNDHASH_POLY_RPCS = Vermont's Regional Planning Commissions 5) BNDHASH_POLY_VTBND = Vermont's state boundary 6) BNDHASH_LINE = Lines on which all POLY feature classes are built The master BNDHASH data is managed as an ESRI geodatabase feature dataset by VCGI. The dataset stores village, town, county, RPC, and state boundaries as seperate feature classes with a set of topology rules which binds the features. This arrangement assures vertical integration of the various boundaries. VCGI will update this layer on an annual basis by reviewing records housed in the VT State Archives - Secretary of State's Office. VCGI also welcomes documented information from VGIS users which identify boundary errors. NOTE - VCGI has NOT attempted to create a legally definitive boundary layer. Instead the idea is to maintain an integrated village/town/county/RPC/state boundary layer which provides for a reasonably accurate representation of these boundaries (refer to ARC_SRC and SRC_NOTES). BNDHASH includes all counties, towns, and villages listed in "Population and Local Government - State of Vermont - 2000" published by the Secretary of State. BNDHASH may include changes endorsed by the Legislature since the publication of this document in 2000 (eg: villages merged with towns). Utlimately the Vermont Secratary of State's Office and the VT Legislature are responsible for maintaining information which accurately describes the locations of these boundaries. BNDHASH should be used for general mapping purposes only. * Users who wish to determine which boundaries are different from the original TBHASH boundaries should refer to the ORIG_ARC field in the BOUNDARY_BNDHASH_LINE (line feature with attributes). Also, updates to BNDHASH are tracked by version number (ex: 2003A). The UPDACT field is used to track changes between versions. The UPDACT field is flushed between versions.
In 2014 and 2015, The LA County Enterprise GIS team under the Geographic Information Officer worked with the Unincorporated Area Deputies and Field Deputies of each Board Office to establish names that reflect the desires of residents. CSAs differ from the more informal Community geographies because:They are focused on broad statistics and reporting, not mapping of communities.They represent board approved names assigned to Census block groups and city boundaries.They cover the entire unincorporated County (no gaps).There are not overlapping areas. Additionally, CSAs use the following naming conventions:All names are assumed to begin with Unincorporated (e.g. Unincorporated El Camino Village) which will not be part of the CSA Name (so the name of the Statistical Area would be El Camino Village).Names will not contain “Island.” Beginning each name with Unincorporated will distinguish an area from any surrounding cities. There may be one or more exceptions for certain small areas (e.g. Bandini Islands)A forward slash implies an undetermined boundary between two areas within a statistical geography (e.g. Westfield/Academy Hills or View Park/Windsor Hills)Certain established names may include hyphens (e.g. Florence-Firestone)Aliases may be defined in parentheses (e.g. Unincorporated Long Beach (Bonner/Carson Park))The original set of names were derived from community names used in the 2011 Redistricting process, chosen with the assistance of the Board of Supervisors.Updates: 2025 March: CSA update for Duarte City annexation; and Arcadia City detachment and Monrovia City annexation (effective date 3/17/2025).2024 December: CSA data update to include Whittier City annexation (effective date 11/13/2024).2024 April: CSA data updated to include La Verne City annexation (effective date 4/1/2024).2023 December: CSA data updated to include "Unincorporated Charter Oak" (south of 10 Freeway) into "Unincorporated Covina".2023 June: CSA data was updated to include "Kinneloa Mesa" community, which was a part of Unincorporated East Pasadena.2023 January: Updated layer schema to include feature type (“FEAT_TYPE”) field, which can be one of land, water, breakwater, or pier (consistent with the City Boundaries layer).2022 December: CSA data was updated to incorporate the “Tesoro Del Valle” annexation to the city of Santa Clarita. Unincorporated Valencia is now completely annexed to the City of Santa Clarita. In addition to land area, this data also includes other feature types such as piers, breakwater and water area. 2022 September: CSA data was updated to match with city boundaries along shoreline/coastal area and minor boundary adjusted in some other areas.
Our World Administrative Boundaries Database offers comprehensive postal code data for spatial analysis, including postal and administrative areas. This dataset contains accurate and up-to-date information on all administrative divisions, cities, and zip codes, making it an invaluable resource for various applications such as address capture and validation, map and visualization, reporting and business intelligence (BI), master data management, logistics and supply chain management, and sales and marketing. Our location data packages are available in various formats, including CSV, optimized for seamless integration with popular systems like Esri ArcGIS, Snowflake, QGIS, and more. Product features include fully and accurately geocoded data, multi-language support with address names in local and foreign languages, comprehensive city definitions, and the option to combine map data with UNLOCODE and IATA codes, time zones, and daylight saving times. Companies choose our location databases for their enterprise-grade service, reduction in integration time and cost by 30%, and weekly updates to ensure the highest quality.
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.
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:
Point of Contact
California Department of Technology, Office of Digital Services, odsdataservices@state.ca.gov
Field and Abbreviation Definitions
This layer represents current city boundaries within Los Angeles County. The Los Angeles County Department of Public Works provides the most current shapefiles representing city boundaries and city annexations on the Los Angeles County GIS Data Portal. True, legal boundaries are only determined on the ground by surveyors licensed in the State of California. Numerous records are freely available at the Land Records Information website, hosted by the Department of Public Works.Principal attributes include:CITY_NAME: represents the city's name.CITY_TYPE: may be used for definition queries; "Unincorporated" or "City".FEAT_TYPE: identifies the feature that each polygon represents:Land - This value is used for polygons representing the land masses, if you want to see only land features on your map.Pier - This value is used for polygons representing piers along the coastline. One example is the Santa Monica Pier.Breakwater - This value is used for polygons representing man-made barriers that protect the harbors.Water - This value is used for polygons representing navigable waters inside the harbors and marinas.3NM Buffer - This value is used for polygons representing the three seaward nautical miles within the cities' limits, per the Submerged Lands Act.POPULATION: Information in this field is supplied by Mark Greninger (mgreninger@cio.lacounty.gov).Reference Date: 2021
This layer contains 2010-2014 American Community Survey (ACS) 5-year data, and contains estimates and margins of error. The layer shows median age broken down by sex and race group. This is shown by tract, county, and state boundaries. There are also additional calculated attributes related to this topic, which can be mapped or used within analysis. This layer is symbolized to show the median age of the population. To see the full list of attributes available in this service, go to the "Data" tab, and choose "Fields" at the top right. Vintage: 2010-2014ACS Table(s): B01001, B01002, B01002B, B01002C, B01002D, B01002E, B01002F, B01002G, B01002H, B01002I (Not all lines of ACS table B01001 are available in this feature layer.)Data downloaded from: Census Bureau's API for American Community Survey Date of API call: November 11, 2020National Figures: data.census.govThe United States Census Bureau's American Community Survey (ACS):About the SurveyGeography & ACSTechnical DocumentationNews & UpdatesThis ready-to-use layer can be used within ArcGIS Pro, ArcGIS Online, its configurable apps, dashboards, Story Maps, custom apps, and mobile apps. Data can also be exported for offline workflows. For more information about ACS layers, visit the FAQ. Please cite the Census and ACS when using this data.Data Note from the Census:Data are based on a sample and are subject to sampling variability. The degree of uncertainty for an estimate arising from sampling variability is represented through the use of a margin of error. The value shown here is the 90 percent margin of error. The margin of error can be interpreted as providing a 90 percent probability that the interval defined by the estimate minus the margin of error and the estimate plus the margin of error (the lower and upper confidence bounds) contains the true value. In addition to sampling variability, the ACS estimates are subject to nonsampling error (for a discussion of nonsampling variability, see Accuracy of the Data). The effect of nonsampling error is not represented in these tables.Data Processing Notes:This layer has associated layers containing the most recent ACS data available by the U.S. Census Bureau. Click here to learn more about ACS data releases and click here for the associated boundaries layer. The reason this data is 5+ years different from the most recent vintage is due to the overlapping of survey years. It is recommended by the U.S. Census Bureau to compare non-overlapping datasets.Boundaries come from the US Census TIGER geodatabases. Boundary vintage (2014) appropriately matches the data vintage as specified by the Census. These are Census boundaries with water and/or coastlines clipped for cartographic purposes. For census tracts, the water cutouts are derived from a subset of the 2010 AWATER (Area Water) boundaries offered by TIGER. For state and county boundaries, the water and coastlines are derived from the coastlines of the 500k TIGER Cartographic Boundary Shapefiles. The original AWATER and ALAND fields are still available as attributes within the data table (units are square meters). The States layer contains 52 records - all US states, Washington D.C., and Puerto RicoCensus tracts with no population that occur in areas of water, such as oceans, are removed from this data service (Census Tracts beginning with 99).Percentages and derived counts, and associated margins of error, are calculated values (that can be identified by the "_calc_" stub in the field name), and abide by the specifications defined by the American Community Survey.Field alias names were created based on the Table Shells file available from the American Community Survey Summary File Documentation page.Negative values (e.g., -4444...) have been set to null, with the exception of -5555... which has been set to zero. These negative values exist in the raw API data to indicate the following situations:The margin of error column indicates that either no sample observations or too few sample observations were available to compute a standard error and thus the margin of error. A statistical test is not appropriate.Either no sample observations or too few sample observations were available to compute an estimate, or a ratio of medians cannot be calculated because one or both of the median estimates falls in the lowest interval or upper interval of an open-ended distribution.The median falls in the lowest interval of an open-ended distribution, or in the upper interval of an open-ended distribution. A statistical test is not appropriate.The estimate is controlled. A statistical test for sampling variability is not appropriate.The data for this geographic area cannot be displayed because the number of sample cases is too small.
This layer shows median household income by race and by age of householder. This is shown by tract, county, and state boundaries. This service is updated annually to contain the most currently released American Community Survey (ACS) 5-year data, and contains estimates and margins of error. There are also additional calculated attributes related to this topic, which can be mapped or used within analysis. Median income and income source is based on income in past 12 months of survey. This layer is symbolized to show median household income. To see the full list of attributes available in this service, go to the "Data" tab, and choose "Fields" at the top right. Current Vintage: 2015-2019ACS Table(s): B19013B, B19013C, B19013D, B19013E, B19013F, B19013G, B19013H, B19013I, B19049, B19053Data downloaded from: Census Bureau's API for American Community Survey Date of API call: December 10, 2020National Figures: data.census.govThe United States Census Bureau's American Community Survey (ACS):About the SurveyGeography & ACSTechnical DocumentationNews & UpdatesThis ready-to-use layer can be used within ArcGIS Pro, ArcGIS Online, its configurable apps, dashboards, Story Maps, custom apps, and mobile apps. Data can also be exported for offline workflows. Please cite the Census and ACS when using this data.Data Note from the Census:Data are based on a sample and are subject to sampling variability. The degree of uncertainty for an estimate arising from sampling variability is represented through the use of a margin of error. The value shown here is the 90 percent margin of error. The margin of error can be interpreted as providing a 90 percent probability that the interval defined by the estimate minus the margin of error and the estimate plus the margin of error (the lower and upper confidence bounds) contains the true value. In addition to sampling variability, the ACS estimates are subject to nonsampling error (for a discussion of nonsampling variability, see Accuracy of the Data). The effect of nonsampling error is not represented in these tables.Data Processing Notes:This layer is updated automatically when the most current vintage of ACS data is released each year, usually in December. The layer always contains the latest available ACS 5-year estimates. It is updated annually within days of the Census Bureau's release schedule. Click here to learn more about ACS data releases.Boundaries come from the US Census TIGER geodatabases. Boundaries are updated at the same time as the data updates (annually), and the boundary vintage appropriately matches the data vintage as specified by the Census. These are Census boundaries with water and/or coastlines clipped for cartographic purposes. For census tracts, the water cutouts are derived from a subset of the 2010 AWATER (Area Water) boundaries offered by TIGER. For state and county boundaries, the water and coastlines are derived from the coastlines of the 500k TIGER Cartographic Boundary Shapefiles. The original AWATER and ALAND fields are still available as attributes within the data table (units are square meters). The States layer contains 52 records - all US states, Washington D.C., and Puerto RicoCensus tracts with no population that occur in areas of water, such as oceans, are removed from this data service (Census Tracts beginning with 99).Percentages and derived counts, and associated margins of error, are calculated values (that can be identified by the "_calc_" stub in the field name), and abide by the specifications defined by the American Community Survey.Field alias names were created based on the Table Shells file available from the American Community Survey Summary File Documentation page.Negative values (e.g., -4444...) have been set to null, with the exception of -5555... which has been set to zero. These negative values exist in the raw API data to indicate the following situations:The margin of error column indicates that either no sample observations or too few sample observations were available to compute a standard error and thus the margin of error. A statistical test is not appropriate.Either no sample observations or too few sample observations were available to compute an estimate, or a ratio of medians cannot be calculated because one or both of the median estimates falls in the lowest interval or upper interval of an open-ended distribution.The median falls in the lowest interval of an open-ended distribution, or in the upper interval of an open-ended distribution. A statistical test is not appropriate.The estimate is controlled. A statistical test for sampling variability is not appropriate.The data for this geographic area cannot be displayed because the number of sample cases is too small.
Historical National Boundaries displays global national boundaries for the following dates in history: 1800, 1914, 1918, 1939, 1945, 1970, 1990, 2000. Boundary changes associated with World War I (1914 - 1918) and World War II (1939 - 1945) can be viewed by turning off all other layers and toggling between the two. Data for each layer comes from a variety of sources, including historical atlases and the Library of Congress website - https://www.loc.gov/maps/. Suggested CitationKropelnicki, Jeffrey; Johnson, Grace; Kne, Len; Lindberg, Mark. (2022). Historical National Boundaries. Retrieved from the Data Repository for the University of Minnesota, https://doi.org/10.13020/146x-1412.
This city boundary shapefile was extracted from Esri Data and Maps for ArcGIS 2014 - U.S. Populated Place Areas. This shapefile can be joined to 500 Cities city-level Data (GIS Friendly Format) in a geographic information system (GIS) to make city-level maps.
This file contains the digital vector boundaries for the Countries in the England and Wales, as at Census 1961. The boundaries available are:
CC0 1.0 Universal Public Domain Dedicationhttps://creativecommons.org/publicdomain/zero/1.0/
License information was derived automatically
Northeastern United States Town Boundary data are intended for geographic display of state, county and town (municipal) boundaries at statewide and regional levels. Use it to map and label towns on a map. These data are derived from Northeastern United States Political Boundary Master layer. This information should be displayed and analyzed at scales appropriate for 1:24,000-scale data. The State of Connecticut, Department of Environmental Protection (CTDEP) assembled this regional data layer using data from other states in order to create a single, seamless representation of political boundaries within the vicinity of Connecticut that could be easily incorporated into mapping applications as background information. More accurate and up-to-date information may be available from individual State government Geographic Information System (GIS) offices. Not intended for maps printed at map scales greater or more detailed than 1:24,000 scale (1 inch = 2,000 feet.)
Washington State County Boundaries including Department of Natural Resources (DNR) county codes. This data is created from the WA Public Land Survey source data maintained by the DNR.WA County Boundaries Metadata
Overview The Office of the Geographer and Global Issues at the U.S. Department of State produces the Large Scale International Boundaries (LSIB) dataset. The current edition is version 11.4 (published 24 February 2025). The 11.4 release contains updated boundary lines and data refinements designed to extend the functionality of the dataset. These data and generalized derivatives are the only international boundary lines approved for U.S. Government use. The contents of this dataset reflect U.S. Government policy on international boundary alignment, political recognition, and dispute status. They do not necessarily reflect de facto limits of control. National Geospatial Data Asset This dataset is a National Geospatial Data Asset (NGDAID 194) managed by the Department of State. It is a part of the International Boundaries Theme created by the Federal Geographic Data Committee. Dataset Source Details Sources for these data include treaties, relevant maps, and data from boundary commissions, as well as national mapping agencies. Where available and applicable, the dataset incorporates information from courts, tribunals, and international arbitrations. The research and recovery process includes analysis of satellite imagery and elevation data. Due to the limitations of source materials and processing techniques, most lines are within 100 meters of their true position on the ground. Cartographic Visualization The LSIB is a geospatial dataset that, when used for cartographic purposes, requires additional styling. The LSIB download package contains example style files for commonly used software applications. The attribute table also contains embedded information to guide the cartographic representation. Additional discussion of these considerations can be found in the Use of Core Attributes in Cartographic Visualization section below. Additional cartographic information pertaining to the depiction and description of international boundaries or areas of special sovereignty can be found in Guidance Bulletins published by the Office of the Geographer and Global Issues: https://data.geodata.state.gov/guidance/index.html Contact Direct inquiries to internationalboundaries@state.gov. Direct download: https://data.geodata.state.gov/LSIB.zip Attribute Structure The dataset uses the following attributes divided into two categories: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | Core CC1_GENC3 | Extension CC1_WPID | Extension COUNTRY1 | Core CC2 | Core CC2_GENC3 | Extension CC2_WPID | Extension COUNTRY2 | Core RANK | Core LABEL | Core STATUS | Core NOTES | Core LSIB_ID | Extension ANTECIDS | Extension PREVIDS | Extension PARENTID | Extension PARENTSEG | Extension These attributes have external data sources that update separately from the LSIB: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | GENC CC1_GENC3 | GENC CC1_WPID | World Polygons COUNTRY1 | DoS Lists CC2 | GENC CC2_GENC3 | GENC CC2_WPID | World Polygons COUNTRY2 | DoS Lists LSIB_ID | BASE ANTECIDS | BASE PREVIDS | BASE PARENTID | BASE PARENTSEG | BASE The core attributes listed above describe the boundary lines contained within the LSIB dataset. Removal of core attributes from the dataset will change the meaning of the lines. An attribute status of “Extension” represents a field containing data interoperability information. Other attributes not listed above include “FID”, “Shape_length” and “Shape.” These are components of the shapefile format and do not form an intrinsic part of the LSIB. Core Attributes The eight core attributes listed above contain unique information which, when combined with the line geometry, comprise the LSIB dataset. These Core Attributes are further divided into Country Code and Name Fields and Descriptive Fields. County Code and Country Name Fields “CC1” and “CC2” fields are machine readable fields that contain political entity codes. These are two-character codes derived from the Geopolitical Entities, Names, and Codes Standard (GENC), Edition 3 Update 18. “CC1_GENC3” and “CC2_GENC3” fields contain the corresponding three-character GENC codes and are extension attributes discussed below. The codes “Q2” or “QX2” denote a line in the LSIB representing a boundary associated with areas not contained within the GENC standard. The “COUNTRY1” and “COUNTRY2” fields contain the names of corresponding political entities. These fields contain names approved by the U.S. Board on Geographic Names (BGN) as incorporated in the ‘"Independent States in the World" and "Dependencies and Areas of Special Sovereignty" lists maintained by the Department of State. To ensure maximum compatibility, names are presented without diacritics and certain names are rendered using common cartographic abbreviations. Names for lines associated with the code "Q2" are descriptive and not necessarily BGN-approved. Names rendered in all CAPITAL LETTERS denote independent states. Names rendered in normal text represent dependencies, areas of special sovereignty, or are otherwise presented for the convenience of the user. Descriptive Fields The following text fields are a part of the core attributes of the LSIB dataset and do not update from external sources. They provide additional information about each of the lines and are as follows: ATTRIBUTE NAME | CONTAINS NULLS RANK | No STATUS | No LABEL | Yes NOTES | Yes Neither the "RANK" nor "STATUS" fields contain null values; the "LABEL" and "NOTES" fields do. The "RANK" field is a numeric expression of the "STATUS" field. Combined with the line geometry, these fields encode the views of the United States Government on the political status of the boundary line. ATTRIBUTE NAME | | VALUE | RANK | 1 | 2 | 3 STATUS | International Boundary | Other Line of International Separation | Special Line A value of “1” in the “RANK” field corresponds to an "International Boundary" value in the “STATUS” field. Values of ”2” and “3” correspond to “Other Line of International Separation” and “Special Line,” respectively. The “LABEL” field contains required text to describe the line segment on all finished cartographic products, including but not limited to print and interactive maps. The “NOTES” field contains an explanation of special circumstances modifying the lines. This information can pertain to the origins of the boundary lines, limitations regarding the purpose of the lines, or the original source of the line. Use of Core Attributes in Cartographic Visualization Several of the Core Attributes provide information required for the proper cartographic representation of the LSIB dataset. The cartographic usage of the LSIB requires a visual differentiation between the three categories of boundary lines. Specifically, this differentiation must be between: International Boundaries (Rank 1); Other Lines of International Separation (Rank 2); and Special Lines (Rank 3). Rank 1 lines must be the most visually prominent. Rank 2 lines must be less visually prominent than Rank 1 lines. Rank 3 lines must be shown in a manner visually subordinate to Ranks 1 and 2. Where scale permits, Rank 2 and 3 lines must be labeled in accordance with the “Label” field. Data marked with a Rank 2 or 3 designation does not necessarily correspond to a disputed boundary. Please consult the style files in the download package for examples of this depiction. The requirement to incorporate the contents of the "LABEL" field on cartographic products is scale dependent. If a label is legible at the scale of a given static product, a proper use of this dataset would encourage the application of that label. Using the contents of the "COUNTRY1" and "COUNTRY2" fields in the generation of a line segment label is not required. The "STATUS" field contains the preferred description for the three LSIB line types when they are incorporated into a map legend but is otherwise not to be used for labeling. Use of the “CC1,” “CC1_GENC3,” “CC2,” “CC2_GENC3,” “RANK,” or “NOTES” fields for cartographic labeling purposes is prohibited. Extension Attributes Certain elements of the attributes within the LSIB dataset extend data functionality to make the data more interoperable or to provide clearer linkages to other datasets. The fields “CC1_GENC3” and “CC2_GENC” contain the corresponding three-character GENC code to the “CC1” and “CC2” attributes. The code “QX2” is the three-character counterpart of the code “Q2,” which denotes a line in the LSIB representing a boundary associated with a geographic area not contained within the GENC standard. To allow for linkage between individual lines in the LSIB and World Polygons dataset, the “CC1_WPID” and “CC2_WPID” fields contain a Universally Unique Identifier (UUID), version 4, which provides a stable description of each geographic entity in a boundary pair relationship. Each UUID corresponds to a geographic entity listed in the World Polygons dataset. These fields allow for linkage between individual lines in the LSIB and the overall World Polygons dataset. Five additional fields in the LSIB expand on the UUID concept and either describe features that have changed across space and time or indicate relationships between previous versions of the feature. The “LSIB_ID” attribute is a UUID value that defines a specific instance of a feature. Any change to the feature in a lineset requires a new “LSIB_ID.” The “ANTECIDS,” or antecedent ID, is a UUID that references line geometries from which a given line is descended in time. It is used when there is a feature that is entirely new, not when there is a new version of a previous feature. This is generally used to reference countries that have dissolved. The “PREVIDS,” or Previous ID, is a UUID field that contains old versions of a line. This is an additive field, that houses all Previous IDs. A new version of a feature is defined by any change to the