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

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 map is designed to be used as a basemap by marine GIS professionals and as a reference map by anyone interested in ocean data. The basemap focuses on bathymetry. It also includes inland waters and roads, overlaid on land cover and shaded relief imagery.The Ocean Base map currently provides coverage for the world down to a scale of ~1:577k; coverage down to ~1:72k in United States coastal areas and various other areas; and coverage down to ~1:9k in limited regional areas.The World Ocean Reference is designed to be drawn on top of this map and provides selected city labels throughout the world. This web map lets you view the World Ocean Base with the Reference service drawn on top. Article in the Fall 2011 ArcUser about this basemap: "A Foundation for Ocean GIS".The map was compiled from a variety of best available sources from several data providers, including General Bathymetric Chart of the Oceans GEBCO_08 Grid version 20100927 and IHO-IOC GEBCO Gazetteer of Undersea Feature Names August 2010 version (https://www.gebco.net), National Oceanic and Atmospheric Administration (NOAA) and National Geographic for the oceans; and Garmin, and Esri for topographic content. You can contribute your bathymetric data to this service and have it served by Esri for the benefit of the Ocean GIS community. For details on the users who contributed bathymetric data for this map via the Community Maps Program, view the list of Contributors for the Ocean Basemap. The basemap was designed and developed by Esri. The GEBCO_08 Grid is largely based on a database of ship-track soundings with interpolation between soundings guided by satellite-derived gravity data. In some areas, data from existing grids are included. The GEBCO_08 Grid does not contain detailed information in shallower water areas, information concerning the generation of the grid can be found on GEBCO's website: https://www.gebco.net/data_and_products/gridded_bathymetry_data/. The GEBCO_08 Grid is accompanied by a Source Identifier (SID) Grid which indicates which cells in the GEBCO_08 Grid are based on soundings or existing grids and which have been interpolated. The latest version of both grids and accompanying documentation is available to download, on behalf of GEBCO, from the British Oceanographic Data Centre (BODC) https://www.bodc.ac.uk/data/online_delivery/gebco/.The names of the IHO (International Hydrographic Organization), IOC (intergovernmental Oceanographic Commission), GEBCO (General Bathymetric Chart of the Oceans), NERC (Natural Environment Research Council) or BODC (British Oceanographic Data Centre) may not be used in any way to imply, directly or otherwise, endorsement or support of either the Licensee or their mapping system.Tip: Here are some famous oceanic locations as they appear this map. Each URL launches this map at a particular location via parameters specified in the URL: Challenger Deep, Galapagos Islands, Hawaiian Islands, Maldive Islands, Mariana Trench, Tahiti, Queen Charlotte Sound, Notre Dame Bay, Labrador Trough, New York Bight, Massachusetts Bay, Mississippi Sound

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.

The Watershed Boundary Dataset (WBD) from The National Map (TNM) defines the perimeter of drainage areas formed by the terrain and other landscape characteristics. The drainage areas are nested within each other so that a large drainage area, such as the Upper Mississippi River, is composed of multiple smaller drainage areas, such as the Wisconsin River. Each of these smaller areas can further be subdivided into smaller and smaller drainage areas. The WBD uses six different levels in this hierarchy, with the smallest averaging about 30,000 acres. The WBD is made up of polygons nested into six levels of data respectively defined by Regions, Subregions, Basins, Subbasins, Watersheds, and Subwatersheds. For additional information on the WBD, go to https://nhd.usgs.gov/wbd.html. The USGS National Hydrography Dataset (NHD) service is a companion dataset to the WBD. The NHD is a comprehensive set of digital spatial data that encodes information about naturally occurring and constructed bodies of surface water (lakes, ponds, and reservoirs), paths through which water flows (canals, ditches, streams, and rivers), and related entities such as point features (springs, wells, stream gages, and dams). The information encoded about these features includes classification and other characteristics, delineation, geographic name, position and related measures, a "reach code" through which other information can be related to the NHD, and the direction of water flow. The network of reach codes delineating water and transported material flow allows users to trace movement in upstream and downstream directions. In addition to this geographic information, the dataset contains metadata that supports the exchange of future updates and improvements to the data. The NHD is available nationwide in two seamless datasets, one based on 1:24,000-scale maps and referred to as high resolution NHD, and the other based on 1:100,000-scale maps and referred to as medium resolution NHD. Additional selected areas in the United States are available based on larger scales, such as 1:5,000-scale or greater, and referred to as local resolution NHD. For more information on the NHD, go to https://nhd.usgs.gov/index.html. Hydrography data from The National Map supports many applications, such as making maps, geocoding observations, flow modeling, data maintenance, and stewardship. Hydrography data is commonly combined with other data themes, such as boundaries, elevation, structures, and transportation, to produce general reference base maps. The National Map viewer allows free downloads of public domain WBD and NHD data in either Esri File or Personal Geodatabase, or Shapefile formats. The Watershed Boundary Dataset is being developed under the leadership of the Subcommittee on Spatial Water Data, which is part of the Advisory Committee on Water Information (ACWI) and the Federal Geographic Data Committee (FGDC). The USDA Natural Resources Conservation Service (NRCS), along with many other federal agencies and national associations, have representatives on the Subcommittee on Spatial Water Data. As watershed boundary geographic information systems (GIS) coverages are completed, statewide and national data layers will be made available via the Geospatial Data Gateway to everyone, including federal, state, local government agencies, researchers, private companies, utilities, environmental groups, and concerned citizens. The database will assist in planning and describing water use and related land use activities. Resources in this dataset:Resource Title: Watershed Boundary Dataset (WBD). File Name: Web Page, url: https://www.nrcs.usda.gov/wps/portal/nrcs/detail/national/water/watersheds/dataset/?cid=nrcs143_021630 Web site for the Watershed Boundary Dataset (WBD), including links to:

Review Data Availability (Status Maps) Obtain Data by State, County, or Other Area Obtain Seamless National Data offsite link image
Geospatial Data Tools National Technical and State Coordinators Information about WBD dataset

Introduction

Geographical scale, in terms of spatial extent, provide a basis for other branches of science. This dataset contains newly proposed geographical and geological GIS boundaries for the Pan-Tibetan Highlands (new proposed name for the High Mountain Asia), based on geological and geomorphological features. This region comprises the Tibetan Plateau and three adjacent mountain regions: the Himalaya, Hengduan Mountains and Mountains of Central Asia, and boundaries are also given for each subregion individually. The dataset will benefit quantitative spatial analysis by providing a well-defined geographical scale for other branches of research, aiding cross-disciplinary comparisons and synthesis, as well as reproducibility of research results.

The dataset comprises three subsets, and we provide three data formats (.shp, .geojson and .kmz) for each of them. Shapefile format (.shp) was generated in ArcGIS Pro, and the other two were converted from shapefile, the conversion steps refer to 'Data processing' section below. The following is a description of the three subsets:

(1) The GIS boundaries we newly defined of the Pan-Tibetan Highlands and its four constituent sub-regions, i.e. the Tibetan Plateau, Himalaya, Hengduan Mountains and the Mountains of Central Asia. All files are placed in the "Pan-Tibetan Highlands (Liu et al._2022)" folder.

(2) We also provide GIS boundaries that were applied by other studies (cited in Fig. 3 of our work) in the folder "Tibetan Plateau and adjacent mountains (Others’ definitions)". If these data is used, please cite the relevent paper accrodingly. In addition, it is worthy to note that the GIS boundaries of Hengduan Mountains (Li et al. 1987a) and Mountains of Central Asia (Foggin et al. 2021) were newly generated in our study using Georeferencing toolbox in ArcGIS Pro.

(3) Geological assemblages and characters of the Pan-Tibetan Highlands, including Cratons and micro-continental blocks (Fig. S1), plus sutures, faults and thrusts (Fig. 4), are placed in the "Pan-Tibetan Highlands (geological files)" folder.

Note: High Mountain Asia: The name ‘High Mountain Asia’ is the only direct synonym of Pan-Tibetan Highlands, but this term is both grammatically awkward and somewhat misleading, and hence the term ‘Pan-Tibetan Highlands’ is here proposed to replace it. Third Pole: The first use of the term ‘Third Pole’ was in reference to the Himalaya by Kurz & Montandon (1933), but the usage was subsequently broadened to the Tibetan Plateau or the whole of the Pan-Tibetan Highlands. The mainstream scientific literature refer the ‘Third Pole’ to the region encompassing the Tibetan Plateau, Himalaya, Hengduan Mountains, Karakoram, Hindu Kush and Pamir. This definition was surpported by geological strcture (Main Pamir Thrust) in the western part, and generally overlaps with the ‘Tibetan Plateau’ sensu lato defined by some previous studies, but is more specific.

More discussion and reference about names please refer to the paper. The figures (Figs. 3, 4, S1) mentioned above were attached in the end of this document.

Data processing

We provide three data formats. Conversion of shapefile data to kmz format was done in ArcGIS Pro. We used the Layer to KML tool in Conversion Toolbox to convert the shapefile to kmz format. Conversion of shapefile data to geojson format was done in R. We read the data using the shapefile function of the raster package, and wrote it as a geojson file using the geojson_write function in the geojsonio package.

Version

Version 2022.1.

Acknowledgements

This study was supported by the Strategic Priority Research Program of Chinese Academy of Sciences (XDB31010000), the National Natural Science Foundation of China (41971071), the Key Research Program of Frontier Sciences, CAS (ZDBS-LY-7001). We are grateful to our coauthors insightful discussion and comments. We also want to thank professors Jed Kaplan, Yin An, Dai Erfu, Zhang Guoqing, Peter Cawood, Tobias Bolch and Marc Foggin for suggestions and providing GIS files.

Citation

Liu, J., Milne, R. I., Zhu, G. F., Spicer, R. A., Wambulwa, M. C., Wu, Z. Y., Li, D. Z. (2022). Name and scale matters: Clarifying the geography of Tibetan Plateau and adjacent mountain regions. Global and Planetary Change, In revision

Jie Liu & Guangfu Zhu. (2022). Geographical and geological GIS boundaries of the Tibetan Plateau and adjacent mountain regions (Version 2022.1). https://doi.org/10.5281/zenodo.6432940

Contacts

Dr. Jie LIU: E-mail: liujie@mail.kib.ac.cn;

Mr. Guangfu ZHU: zhuguangfu@mail.kib.ac.cn

Institution: Kunming Institute of Botany, Chinese Academy of Sciences

Address: 132# Lanhei Road, Heilongtan, Kunming 650201, Yunnan, China

Copyright

This dataset is available under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

This dataset contains raw GIS data sourced from the BAG (Basisregistratie Adressen en Gebouwen; Registry of Addresses and Buildings). It provides comprehensive information on buildings, including advanced height data and administrative details. It also contains geographic divisions within The Hague. Additionally, the dataset incorporates energy label data, offering insights into the energy efficiency and performance of these buildings. This combined dataset serves as the backbone of a Master's thesis in Industrial Ecology, analysing residential and office cooling and its environmental impacts in The Hague, Netherlands. The codebase of this analysis can be found in this Github repository: https://github.com/simonvanlierde/msc-thesis-ie

The dataset includes a background research spreadsheet containing supporting calculations. It also presents geopackages with results from the cooling demand model (CDM) for various scenarios: Status quo (SQ), 2030, and 2050 scenarios (Low, Medium, and High)

Background research data

The background_research_data.xlsx spreadsheet contains comprehensive background research calculations supporting the shaping of input parameters used in the model. It contains several sheets:

• Cooling Technologies: Details the various cooling technologies examined in the study, summarizing their characteristics and the market penetration mixes used in the analysis.
• LCA Results of Ventilation Systems: Provides an overview of the ecoinvent processes serving as proxies for the life-cycle impacts of cooling equipment, along with calculations of the weight of cooling systems and contribution tables from the LCA-based assessment.
• Material Scarcity: A detailed examination of the critical raw material content in the material footprint of ecoinvent processes, representing cooling equipment.
• Heat Plans per Neighbourhood: Forecasts of future heating solutions for each neighbourhood in The Hague.
• Building Stock: Analysis of the projected growth trends in residential and office building stocks in The Hague. AC Market: Market analysis covering air conditioner sales in the Netherlands from 2002 to 2022.
• Climate Change: Computations of climate-related parameters based on KNMI climate scenarios.
• Electricity Mix Analysis: Analysis of future projections for the Dutch electricity grid and calculations of life-cycle carbon intensities of the grid.

Input data

Geographic divisions

• The outline of The Hague municipality through the Municipal boundaries (Gemeenten) layer, sourced from the Administrative boundaries (Bestuurlijke Gemeenten) dataset on the PDOK WFS service.
• District (Wijken) and Neighbourhood (Buurten) layers were downloaded from the PDOK WFS service (from the CBS Wijken en Buurten 2022 data package) and clipped to the outline of The Hague.
• The 4-digit postcodes layer was downloaded from PDOK WFS service (CBS Postcode4 statistieken 2020) and clipped to The Hague's outline. The postcodes within The Hague were subsequently stored in a csv file.
• The census block layer was downloaded from the PDOK WFS service (from the CBS Vierkantstatistieken 100m 2021 data package) and also clipped to the outline of The Hague.
• These layers have been combined in the GeographicDivisions_TheHague GeoPackage.

BAG data

• BAG data was acquired through the download of a BAG GeoPackage from the BAG ATOM download page.
• In the resulting GeoPackage, the Residences (Verblijfsobject) and Building (Pand) layers were clipped to match The Hague's outline.
• The resulting residence data can be found in the BAG_buildings_TheHague GeoPackage.

3D BAG

• Due to limitations imposed by the PDOK WFS service, which restricts the number of downloadable buildings to 10,000, it was necessary to acquire 145 individual GeoPackages for tiles covering The Hague from the 3D BAG website.
• These GeoPackages were merged using the ogr2ogr append function from the GDAL library in bash.
• Roof elevation data was extracted from the LoD 1.2 2D layer from the resulting GeoPackage.
• Ground elevation data was obtained from the Pand layer.
• Both of these layers were clipped to match The Hague's outline.
• Roof and ground elevation data from the LoD 1.2 2D and Pand layers were joined to the Pand layer in the BAG dataset using the BAG ID of each building.
• The resulting data can be found in the BAG_buildings_TheHague GeoPackage.

Energy labels

• Energy labels were downloaded from the Energy label registry (EP-online) and stored in energy_labels_TheNetherlands.csv.

UHI effect data

• A bitmap with the UHI effect intensity in The Hague was retrieved from the from the Dutch Natural Capital Atlas (Atlas Natuurlijk Kapitaal) and stored in UHI_effect_TheHague.tiff.

Output data

• The residence-level data joined to the building layer is contained in the BAG_buildings_with_residence_data_full GeoPackage.
• The results for each building, according to different scenarios, are compiled in the buildings_with_CDM_results_[scenario]_full GeoPackages. The scenarios are abbreviated as follows:
  • SQ: Status Quo, covering the 2018-2022 reference period.
  • 2030: An average scenario projected for the year 2030.
  • 2050_L: A low-impact, best-case scenario for 2050.
  • 2050_M: A medium-impact, moderate scenario for 2050.
  • 2050_H: A high-impact, worst-case scenario for 2050.

Land cover has been interpreted from Satellite images and field checked, other information has been digitized from topographic maps

 Members informations:
 Attached Vector(s):
  MemberID: 1
 Vector Name: Land use
 Source Map Name: SPOT Pan
 Source Map Scale: 50000
 Source Map Date: 1989/90
 Projection: Polyconic on Modified Everest Ellipsoid
 Feature_type: polygon
 Vector 
 Land use maps, interpreted from SPOT panchromatic imagery and field
 checked (18 classes)

 Members informations:
 Attached Vector(s):
  MemberID: 2
 Vector Name: Administrative boundaries
 Source Map Name: topo sheets
 Source Map Scale: 50000
 Source Map Date: ?
 Feature_type: polygon
 Vector 
 Dzongkhags (Districts) and Gewogs

 Members informations:
 Attached Vector(s):
  MemberID: 3
 Vector Name: Roads
 Source Map Name: topo sheets
 Source Map Scale: 50000
 Source Map Date: ?
 Feature_type: lines
 Vector 
 Road network

 Attached Report(s)
 Member ID: 4
 Report Name: Atlas of Bhutan
 Report Authors: Land use planning section
 Report Publisher: Ministry of Agriculture, Thimpu
 Report Date: 1997-06-01
 Report 
 Land cover (1:250000) and area statistics of 20 Dzongkhags

The Cropland Data Layer (CDL), hosted on CropScape, provides a raster, geo-referenced, crop-specific land cover map for the continental United States. The CDL also includes a crop mask layer and planting frequency layers, as well as boundary, water and road layers. The Boundary Layer options provided are County, Agricultural Statistics Districts (ASD), State, and Region. The data is created annually using moderate resolution satellite imagery and extensive agricultural ground truth. Users can select a geographic area of interest or import one, then access acreage statistics for a specific year or view the change from one year to another. The data can be exported or added to the CDL. The information is useful for issues related to agricultural sustainability, biodiversity, and land cover monitoring, especially due to extreme weather events. Resources in this dataset:Resource Title: CropScape and Cropland Data Layer - National Download. File Name: Web Page, url: https://www.nass.usda.gov/Research_and_Science/Cropland/Release/index.php Downloads available as zipped files at https://www.nass.usda.gov/Research_and_Science/Cropland/Release/index.php --

National CDL's -- by year, 2008-2020. Cropland Data Layer provides a raster, geo-referenced, crop-specific land cover map for the continental United States. The CDL also includes a crop mask layer and planting frequency layers, as well as boundary, water and road layers. The Boundary Layer options provided are County, Agricultural Statistics Districts (ASD), State, and Region. National Cultivated Layer -- based on the most recent five years (2013-2020). National Frequency Layer -- the 2017 Crop Frequency Layer identifies crop specific planting frequency and are based on land cover information derived from the 2008 through 2020CDL's. There are currently four individual crop frequency data layers that represent four major crops: corn, cotton, soybeans, and wheat. National Confidence Layer -- the Confidence Layer spatially represents the predicted confidence that is associated with that output pixel, based upon the rule(s) that were used to classify it. Western/Eastern/Central U.S.

Visit https://nassgeodata.gmu.edu/CropScape/ for the interactive map including tutorials and basic instructions. These options include a "Demo Video", "Help", "Developer Guide", and "FAQ".

This dataset provides detailed information on road surfaces from OpenStreetMap (OSM) data, distinguishing between paved and unpaved surfaces across the region. This information is based on road surface prediction derived from hybrid deep learning approach. For more information on Methods, refer to the paper

Roughly 0.2839 million km of roads are mapped in OSM in this region. Based on AI-mapped estimates the share of paved and unpaved roads is approximately 0.026 and 0.0089 (in million kms), corressponding to 9.1664% and 3.1261% respectively of the total road length in the dataset region. 0.249 million km or 87.7075% of road surface information is missing in OSM. In order to fill this gap, Mapillary derived road surface dataset provides an additional 0.0003 million km of information (corressponding to 0.1046% of total missing information on road surface)

It is intended for use in transportation planning, infrastructure analysis, climate emissions and geographic information system (GIS) applications.

This dataset provides comprehensive information on road and urban area features, including location, surface quality, and classification metadata. This dataset includes attributes from OpenStreetMap (OSM) data, AI predictions for road surface, and urban classifications.

AI features:

• pred_class: Model-predicted class for the road surface, with values "paved" or "unpaved."

• pred_label: Binary label associated with pred_class (0 = paved, 1 = unpaved).

• osm_surface_class: Classification of the surface type from OSM, categorized as "paved" or "unpaved."

• combined_surface_osm_priority: Surface classification combining pred_label and surface(OSM) while prioritizing the OSM surface tag, classified as "paved" or "unpaved."

• combined_surface_DL_priority: Surface classification combining pred_label and surface(OSM) while prioritizing DL prediction pred_label, classified as "paved" or "unpaved."

• n_of_predictions_used: Number of predictions used for the feature length estimation.

• predicted_length: Predicted length based on the DL model’s estimations, in meters.

• DL_mean_timestamp: Mean timestamp of the predictions used, for comparison.

OSM features may have these attributes(Learn what tags mean here):

• name: Name of the feature, if available in OSM.

• name:en: Name of the feature in English, if available in OSM.

• name:* (in local language): Name of the feature in the local official language, where available.

• highway: Road classification based on OSM tags (e.g., residential, motorway, footway).

• surface: Description of the surface material of the road (e.g., asphalt, gravel, dirt).

• smoothness: Assessment of surface smoothness (e.g., excellent, good, intermediate, bad).

• width: Width of the road, where available.

• lanes: Number of lanes on the road.

• oneway: Indicates if the road is one-way (yes or no).

• bridge: Specifies if the feature is a bridge (yes or no).

• layer: Indicates the layer of the feature in cases where multiple features are stacked (e.g., bridges, tunnels).

• source: Source of the data, indicating the origin or authority of specific attributes.

Urban classification features may have these attributes:

• continent: The continent where the data point is located (e.g., Europe, Asia).

• country_iso_a2: The ISO Alpha-2 code representing the country (e.g., "US" for the United States).

• urban: Binary indicator for urban areas based on the GHSU Urban Layer 2019. (0 = rural, 1 = urban)

• urban_area: Name of the urban area or city where the data point is located.

• osm_id: Unique identifier assigned by OpenStreetMap (OSM) to each feature.

• osm_type: Type of OSM element (e.g., node, way, relation).

The data originates from OpenStreetMap (OSM) and is augmented with model predictions using images downloaded from Mapillary in combination with the GHSU Global Human Settlement Urban Layer 2019 and AFRICAPOLIS2020 urban layer.

This dataset is one of many HeiGIT exports on HDX. See the HeiGIT website for more information.

We are looking forward to hearing about your use-case! Feel free to reach out to us and tell us about your research at communications@heigit.org – we would be happy to amplify your work.

The USDA-ARS Southwest Watershed Research Center (SWRC) operates the Walnut Gulch Experimental Watershed (WGEW) in southeastern Arizona as an outdoor laboratory for studying semiarid rangeland hydrologic, ecosystem, climate, and erosion processes. Since its establishment in 1953, the SWRC in Tucson, Arizona, has collected, processed, managed, and disseminated high-resolution, spatially distributed hydrologic data in support of the center’s mission. Data management at the SWRC has evolved through time in response to new computing, storage, and data access technologies. In 1996, the SWRC initiated a multiyear project to upgrade rainfall and runoff sensors and convert analog systems to digital electronic systems supported by data loggers. This conversion was coupled with radio telemetry to remotely transmit recorded data to a central computer, thus greatly reducing operational overhead by reducing labor, maintenance, and data processing time. A concurrent effort was initiated to improve access to SWRC data by creating a system based on a relational database supporting access to the data via the Internet. An SWRC team made up of scientists, IT specialists, programmers, hydrologic technicians, and instrumentation specialists was formed. This effort is termed the Southwest Watershed Research Center Data Access Project (DAP). The goal of the SWRC DAP is to efficiently disseminate data to researchers; land owners, users, and managers; and to the public. Primary access to the data is provided through a Web-based user interface. In addition, data can be accessed directly from within the SWRC network. The first priority for the DAP was to assimilate and make available rainfall and runoff data collected from two instrumented field sites, the WGEW near Tombstone, Arizona, and the Santa Rita Experimental Range (SRER) south of Tucson, Arizona. This web map describes the associated GIS layers. Resources in this dataset:Resource Title: GeoData catalog record. File Name: Web Page, url: https://geodata.nal.usda.gov/geonetwork/srv/eng/catalog.search#/metadata/fe4ac74f13484a169899b166159e0bb5

MCGD_Rep is a sample of spatial data for China in the first half of twentieth century (1900-1949). The data was extracted from the MCGD Main Dataset. It is based mostly on the list of xian (county) seats in 1931 [Source: Zang, Lihe 臧励龢, ed. Zhongguo gujin diming da cidian 中国古今地名大辞典. Shanghai 上海: Commercial Press, 1931], with the addition of some external data [Source: Crow Newspaper Directories]. By and large, it presents a list of the major locations in China between 1900 and 1949. It contains 1,977 entries with the following variables: name in Chinese, name in pinyin; name of the province in Chinese and in pinyin; latitude and longitude, and Name ID and Location ID.

This dataset provides detailed information on road surfaces from OpenStreetMap (OSM) data, distinguishing between paved and unpaved surfaces across the region. This information is based on road surface prediction derived from hybrid deep learning approach. For more information on Methods, refer to the paper

Roughly 0.0497 million km of roads are mapped in OSM in this region. Based on AI-mapped estimates the share of paved and unpaved roads is approximately 0.0117 and 0.0111 (in million kms), corressponding to 23.4856% and 22.3095% respectively of the total road length in the dataset region. 0.0269 million km or 54.2049% of road surface information is missing in OSM. In order to fill this gap, Mapillary derived road surface dataset provides an additional 0.0008 million km of information (corressponding to 3.0011% of total missing information on road surface)

It is intended for use in transportation planning, infrastructure analysis, climate emissions and geographic information system (GIS) applications.

This dataset provides comprehensive information on road and urban area features, including location, surface quality, and classification metadata. This dataset includes attributes from OpenStreetMap (OSM) data, AI predictions for road surface, and urban classifications.

AI features:

• pred_class: Model-predicted class for the road surface, with values "paved" or "unpaved."

• pred_label: Binary label associated with pred_class (0 = paved, 1 = unpaved).

• osm_surface_class: Classification of the surface type from OSM, categorized as "paved" or "unpaved."

• combined_surface_osm_priority: Surface classification combining pred_label and surface(OSM) while prioritizing the OSM surface tag, classified as "paved" or "unpaved."

• combined_surface_DL_priority: Surface classification combining pred_label and surface(OSM) while prioritizing DL prediction pred_label, classified as "paved" or "unpaved."

• n_of_predictions_used: Number of predictions used for the feature length estimation.

• predicted_length: Predicted length based on the DL model’s estimations, in meters.

• DL_mean_timestamp: Mean timestamp of the predictions used, for comparison.

OSM features may have these attributes(Learn what tags mean here):

• name: Name of the feature, if available in OSM.

• name:en: Name of the feature in English, if available in OSM.

• name:* (in local language): Name of the feature in the local official language, where available.

• highway: Road classification based on OSM tags (e.g., residential, motorway, footway).

• surface: Description of the surface material of the road (e.g., asphalt, gravel, dirt).

• smoothness: Assessment of surface smoothness (e.g., excellent, good, intermediate, bad).

• width: Width of the road, where available.

• lanes: Number of lanes on the road.

• oneway: Indicates if the road is one-way (yes or no).

• bridge: Specifies if the feature is a bridge (yes or no).

• layer: Indicates the layer of the feature in cases where multiple features are stacked (e.g., bridges, tunnels).

• source: Source of the data, indicating the origin or authority of specific attributes.

Urban classification features may have these attributes:

• continent: The continent where the data point is located (e.g., Europe, Asia).

• country_iso_a2: The ISO Alpha-2 code representing the country (e.g., "US" for the United States).

• urban: Binary indicator for urban areas based on the GHSU Urban Layer 2019. (0 = rural, 1 = urban)

• urban_area: Name of the urban area or city where the data point is located.

• osm_id: Unique identifier assigned by OpenStreetMap (OSM) to each feature.

• osm_type: Type of OSM element (e.g., node, way, relation).

The data originates from OpenStreetMap (OSM) and is augmented with model predictions using images downloaded from Mapillary in combination with the GHSU Global Human Settlement Urban Layer 2019 and AFRICAPOLIS2020 urban layer.

This dataset is one of many HeiGIT exports on HDX. See the HeiGIT website for more information.

We are looking forward to hearing about your use-case! Feel free to reach out to us and tell us about your research at communications@heigit.org – we would be happy to amplify your work.

This dataset provides detailed information on road surfaces from OpenStreetMap (OSM) data, distinguishing between paved and unpaved surfaces across the region. This information is based on road surface prediction derived from hybrid deep learning approach. For more information on Methods, refer to the paper

Roughly 4.8023 million km of roads are mapped in OSM in this region. Based on AI-mapped estimates the share of paved and unpaved roads is approximately 0.5281 and 0.2874 (in million kms), corressponding to 10.9979% and 5.9838% respectively of the total road length in the dataset region. 3.9868 million km or 83.0183% of road surface information is missing in OSM. In order to fill this gap, Mapillary derived road surface dataset provides an additional 0.0218 million km of information (corressponding to 0.5461% of total missing information on road surface)

It is intended for use in transportation planning, infrastructure analysis, climate emissions and geographic information system (GIS) applications.

This dataset provides comprehensive information on road and urban area features, including location, surface quality, and classification metadata. This dataset includes attributes from OpenStreetMap (OSM) data, AI predictions for road surface, and urban classifications.

AI features:

• pred_class: Model-predicted class for the road surface, with values "paved" or "unpaved."

• pred_label: Binary label associated with pred_class (0 = paved, 1 = unpaved).

• osm_surface_class: Classification of the surface type from OSM, categorized as "paved" or "unpaved."

• combined_surface_osm_priority: Surface classification combining pred_label and surface(OSM) while prioritizing the OSM surface tag, classified as "paved" or "unpaved."

• combined_surface_DL_priority: Surface classification combining pred_label and surface(OSM) while prioritizing DL prediction pred_label, classified as "paved" or "unpaved."

• n_of_predictions_used: Number of predictions used for the feature length estimation.

• predicted_length: Predicted length based on the DL model’s estimations, in meters.

• DL_mean_timestamp: Mean timestamp of the predictions used, for comparison.

OSM features may have these attributes(Learn what tags mean here):

• name: Name of the feature, if available in OSM.

• name:en: Name of the feature in English, if available in OSM.

• name:* (in local language): Name of the feature in the local official language, where available.

• highway: Road classification based on OSM tags (e.g., residential, motorway, footway).

• surface: Description of the surface material of the road (e.g., asphalt, gravel, dirt).

• smoothness: Assessment of surface smoothness (e.g., excellent, good, intermediate, bad).

• width: Width of the road, where available.

• lanes: Number of lanes on the road.

• oneway: Indicates if the road is one-way (yes or no).

• bridge: Specifies if the feature is a bridge (yes or no).

• layer: Indicates the layer of the feature in cases where multiple features are stacked (e.g., bridges, tunnels).

• source: Source of the data, indicating the origin or authority of specific attributes.

Urban classification features may have these attributes:

• continent: The continent where the data point is located (e.g., Europe, Asia).

• country_iso_a2: The ISO Alpha-2 code representing the country (e.g., "US" for the United States).

• urban: Binary indicator for urban areas based on the GHSU Urban Layer 2019. (0 = rural, 1 = urban)

• urban_area: Name of the urban area or city where the data point is located.

• osm_id: Unique identifier assigned by OpenStreetMap (OSM) to each feature.

• osm_type: Type of OSM element (e.g., node, way, relation).

The data originates from OpenStreetMap (OSM) and is augmented with model predictions using images downloaded from Mapillary in combination with the GHSU Global Human Settlement Urban Layer 2019 and AFRICAPOLIS2020 urban layer.

This dataset is one of many HeiGIT exports on HDX. See the HeiGIT website for more information.

We are looking forward to hearing about your use-case! Feel free to reach out to us and tell us about your research at communications@heigit.org – we would be happy to amplify your work.

Displays data from CARTO.PRIV_SCH. Labels based on the attribute NAME. Data is downloaded from website as an .xlsx, then queried for City = Seattle, then geocoded.

Updated as needed, last update October 2025.

This is a collection of 124 global and free datasets allowing for spatial (and temporal) analyses of floods, droughts and their interactions with human societies. We have structured the datasets into seven categories: hydrographic baseline, hydrological dynamics, hydrological extremes, land cover & agriculture, human presence, water management, and vulnerability. Please refer to Lindersson et al. (in preparation) for further information about review methodology.

The collection is a descriptive list, holding the following information for each dataset:

• Category - as structured in Lindersson et al. (in preparation).
• Sub-category- as structured in Lindersson et al. (in preparation).
• Abbreviation - official or as specified in Lindersson et al. (in preparation).
• Title - full title of dataset.
• Product(s) - type of product(s) offered by the dataset.
• Period - time period covered by the dataset, not defined for all datasets.
• Temporal resolution - not defined for static datasets.
• Angular spatial resolution - only defined for gridded datasets.
• Metric spatial resolution - only defined for gridded datasets.
• Map scale
• Extent - geographic coverage of dataset given in latitude limits.
• Description
• Creating institute(s)
• Data type - raster, vector or tabular.
• File format
• Primary EO type - specifies if the product primarily is based on remote sensing, ground-based data, or a hybrid between remote sensing and ground-based data.
• Data sources - lists the data sources behind the dataset, to the extent this is feasible.
• Data sources also in this table - data sources that are also included as datasets in this collection.
• Intentionally compatible with - defines other datasets in this collection that the dataset is intentinoally compatible with.
• Citation - dataset reference or credit.
• Documentation - dataset documentation.
• Web address - dataset access link.

NOTE: Carefully consult the data usage licenses as given by the data providers, to assure that the exact permissions and restrictions are followed.

Geotweet Archive v2.0 The Harvard Center for Geographic Analysis (CGA) maintains the Geotweet Archive, a global record of tweets spanning time, geography, and language. The primary purpose of the Archive is to make a comprehensive collection of geo-located tweets available to the academic research community. The Archive extends from 2010 to the present and is updated daily. The number of tweets in the collection totals approximately 10 billion, and it is stored on Harvard University’s High Performance Computing (HPC) cluster. The Harvard HPC supports many applications for working with big spatio-temporal datasets, including two geospatial tools recently deployed by the CGA: OmniSci Immerse, and PostGIS. The Geotweet Archive consists of tweets which carry two types of geospatial signature: 1) GPS-based longitude/latitude generated by the originating device 2) Place-name-centroid-based longitude/latitude from the bounding box provided by Twitter, based on the user-define place designation (typically a town name). Any tweet which carries one or both of these signatures is included in the Archive. Approximately 1-2% of all tweets contain such geographic coordinates, (this percentage needs verification and may vary over time). The current version of the Archive is Version 2.0. The original Version 1.0 archive began in 2012 as part of a project with Ben Lewis of CGA and then Harvard graduate student Todd Mostak, to develop a GPU-powered spatial database called GEOPS. GEOPS formed the basis for technology startup MapD Technologies, which is now OmniSci. OmniSci Immerse software now runs on Harvard’s High Performance Computing (HPC) environment to support interactive exploration and analytics with the Geotweet Archive and any other large datasets. Version 2.0 of the archive represents the results of a merge between the CGA archive, and an archive developed by the Department of Geoinformatics at the University of Salzburg in Austria, as well as several other archives. Clemens Havas and Bernd Resch at University of Salzburg, and Devika Kakkar of Harvard CGA collaborated to deploy Version 2.0. ======================================================== Schema of Geotweet Archive v2.0 Field name_TYPE_Description message_id----BIGINT----Tweet ID tweet_date----TIMESTAMP----Date and time of tweet from Twitter (utc) tweet_text----TEXT ENCODING----Text content of tweet tags----TEXT ENCODING DICT----Tweet hashtags tweet_lang----TEXT ENCODING DICT----Language that the tweet is in source ----TEXT ENCODING DICT----Operating system or application type used to create the tweet place*----TEXT ENCODING NONE----The geographic place as defined by the user, usually a town name. A bounding box determined by Twitter based on this field, from which centroids (see longitude and latitude fields) and the spatial_error field are derived, and used when not overridden by a GPS coordinate. See Twitter tweet object for place. retweets ----SMALLINT----Number of retweets as of last time it was checked tweet_favorites----SMALLINT----Now known as ‘likes’ photo_url----TEXT ENCODING DICT----URL of any image referenced quoted_status_id ----BIGINT----ID number for quote status user_id ----BIGINT----User ID number user_name----TEXT ENCODING NONE----User name user_location*----TEXT ENCODING NONE----User defined location, usually a city or town. See Twitter user object. followers ----SMALLINT----Followers as of the last time checked friends ----SMALLINT----Number of users followed by this user user_favorites----INT----Number of topics the user is interested in status----INT----Code for what user is doing as of last time it was checked user_lang----TEXT ENCODING DICT----User defined language latitude----FLOAT----Latitude from GPS or bounding box based on Place field longitude----FLOAT----Longitude from GPS or bounding box based on Place field data_source*----TEXT ENCODING DICT----The source crawler or dataset for the tweet gps----TEXT ENCODING DICT----Flag for whether lon/lat is from GPS or town name bounding box (SRID – 4326). When both are present, the GPS coordinate takes priority. spatialerror----FLOAT----Estimate in meters horizontal error for lon/lat coordinate. 10m for GPS coordinates, error for bounding boxes calculated as radius of circle with area of bounding box. ===================================================== *data_source_Code U. Salzburg REST API crawler----1 Harvard CGA streaming crawler----2 U. Salzburg streaming API crawler----3 Ryan Qi Wang and Harvard Medical School datasets----4 U. Heidelberg dataset----5 Archive.org dataset----6 ---------------------------------------------------------------------------------------------- Note: Before April of 2015 the default for GPS coordinate capture was turned on for Twitter users. After this date users have had to opt-in to share their precise location. This is one reason for the large decrease in volume of geotweets after this date. A number of automated...

The Human Geography Dark Map (World Edition) web map provides a detailed world basemap with a dark monochromatic style and content adjusted to support human geography information. Where possible, the map content has been adjusted so that it observes WCAG contrast criteria.This basemap, included in the ArcGIS Living Atlas of the World, uses 3 vector tile layers:Human Geography Dark Label, a label reference layer including cities and communities, countries, administrative units, and at larger scales street names.Human Geography Dark Detail, a detail reference layer including administrative boundaries, roads and highways, and larger bodies of water. This layer is designed to be used with a high degree of transparency so that the detail does not compete with your information. It is set at approximately 50% in this web map, but can be adjusted.Human Geography Dark Base, a simple basemap consisting of land areas in a very dark gray only.The vector tile layers in this web map are built using the same data sources used for other Esri Vector Basemaps. For details on data sources contributed by the GIS community, view the map of Community Maps Basemap Contributors. Esri Vector Basemaps are updated monthly.Learn more about this basemap from the cartographic designer in A Dark Version of the Human Geography Basemap.Use this MapThis map is designed to be used as a basemap for overlaying other layers of information or as a stand-alone reference map. You can add layers to this web map and save as your own map. If you like, you can add this web map to a custom basemap gallery for others in your organization to use in creating web maps. If you would like to add this map as a layer in other maps you are creating, you may use the tile layers referenced in this map.

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