A. SUMMARY This dataset is derived from parcels and several other overlay administrative boundaries (listed below). The dataset was developed by DataSF as a convenience for matching parcels to districts where appropriate. This can be simpler than running a geospatial process every time you want to join parcels to a boundary. The districts provided here run along streets and are non-overlapping so that the parcels will be contained within a single district.

The boundaries included are: 1. Analysis Neighborhoods 2. Supervisor Districts 3. Police Districts 4. Planning Districts

B. HOW THE DATASET IS CREATED A script runs daily that overlays parcels with each of the boundaries to produce the composite dataset.

C. UPDATE PROCESS Updated daily by a script based on the upstream parcels dataset which is also updated daily.

D. HOW TO USE THIS DATASET You can use this dataset to match to administrative districts provided here to datasets that contain a parcel number. This can be a simpler process than running these joins spatially.

In short, we pre-process the spatial overlays to make joins simpler and more performant.

Note: The schema changed in February 2025 - please see below. We will post a roadmap of upcoming changes, but service URLs and schema are now stable. For deployment status of new services beginning in February 2025, see https://gis.data.ca.gov/pages/city-and-county-boundary-data-status. Additional roadmap and status links at the bottom of this metadata.This dataset is regularly updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications. PurposeCounty boundaries along with third party identifiers used to join in external data. Boundaries are from the California Department of Tax and Fee Administration (CDTFA). These boundaries are the best available statewide data source in that CDTFA receives changes in incorporation and boundary lines from the Board of Equalization, who receives them from local jurisdictions for tax purposes. Boundary accuracy is not guaranteed, and though CDTFA works to align boundaries based on historical records and local changes, errors will exist. If you require a legal assessment of boundary location, contact a licensed surveyor.This dataset joins in multiple attributes and identifiers from the US Census Bureau and Board on Geographic Names to facilitate adding additional third party data sources. In addition, we attach attributes of our own to ease and reduce common processing needs and questions. Finally, coastal buffers are separated into separate polygons, leaving the land-based portions of jurisdictions and coastal buffers in adjacent polygons. This feature layer is for public use. Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal BuffersCounties: Full county boundaries and attributes, including all cities within as a single polygonWith Coastal Buffers (this dataset)Without Coastal BuffersCities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.With Coastal BuffersWithout Coastal BuffersCity and County AbbreviationsUnincorporated Areas (Coming Soon)Census Designated PlacesCartographic CoastlinePolygonLine source (Coming Soon) Working with Coastal Buffers The dataset you are currently viewing includes the coastal buffers for cities and counties that have them in the source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except OFFSHORE and AREA_SQMI to get a version with the correct identifiers. Point of ContactCalifornia Department of Technology, Office of Digital Services, odsdataservices@state.ca.gov Field and Abbreviation DefinitionsCDTFA_COUNTY: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.CDTFA_COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system. The boundary data originate with CDTFA's teams managing tax rate information, so this field is preserved and flows into this dataset.CENSUS_GEOID: numeric geographic identifiers from the US Census BureauCENSUS_PLACE_TYPE: City, County, or Town, stripped off the census name for identification purpose.GNIS_PLACE_NAME: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.CDT_COUNTY_ABBR: Abbreviations of county names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 3 characters.CDT_NAME_SHORT: The name of the jurisdiction (city or county) with the word "City" or "County" stripped off the end. Some changes may come to how we process this value to make it more consistent.AREA_SQMI: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.OFFSHORE: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".PRIMARY_DOMAIN: Currently empty/null for all records. Placeholder field for official URL of the city or countyCENSUS_POPULATION: Currently null for all records. In the future, it will include the most recent US Census population estimate for the jurisdiction.GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead. Boundary AccuracyCounty boundaries were originally derived from a 1:24,000 accuracy dataset, with improvements made in some places to boundary alignments based on research into historical records and boundary changes as CDTFA learns of them. City boundary data are derived from pre-GIS tax maps, digitized at BOE and CDTFA, with adjustments made directly in GIS for new annexations, detachments, and corrections.Boundary accuracy within the dataset varies. While CDTFA strives to correctly include or exclude parcels from jurisdictions for accurate tax assessment, this dataset does not guarantee that a parcel is placed in the correct jurisdiction. When a parcel is in the correct jurisdiction, this dataset cannot guarantee accurate placement of boundary lines within or between parcels or rights of way. This dataset also provides no information on parcel boundaries. For exact jurisdictional or parcel boundary locations, please consult the county assessor's office and a licensed surveyor. CDTFA's data is used as the best available source because BOE and CDTFA receive information about changes in jurisdictions which otherwise need to be collected independently by an agency or company to compile into usable map boundaries. CDTFA maintains the best available statewide boundary information. CDTFA's source data notes the following about accuracy: City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties. In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose. SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More information on this algorithm will be provided soon. Coastline CaveatsSome cities have buffers extending into water bodies that we do not cut at the shoreline. These include South Lake Tahoe and Folsom, which extend into neighboring lakes, and San Diego and surrounding cities that extend into San Diego Bay, which our shoreline encloses. If you have feedback on the exclusion of these items, or others, from the shoreline

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://res1gisd-o-tdatad-o-tcad-o-tgov.vcapture.xyz/pages/city-and-county-boundary-data-status. Additional roadmap and status links at the bottom of this metadata.This dataset is continuously updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications.PurposeCity boundaries along with third party identifiers used to join in external data. Boundaries are from the California Department of Tax and Fee Administration (CDTFA). These boundaries are the best available statewide data source in that CDTFA receives changes in incorporation and boundary lines from the Board of Equalization, who receives them from local jurisdictions for tax purposes. Boundary accuracy is not guaranteed, and though CDTFA works to align boundaries based on historical records and local changes, errors will exist. If you require a legal assessment of boundary location, contact a licensed surveyor.This dataset joins in multiple attributes and identifiers from the US Census Bureau and Board on Geographic Names to facilitate adding additional third party data sources. In addition, we attach attributes of our own to ease and reduce common processing needs and questions. Finally, coastal buffers are separated into separate polygons, leaving the land-based portions of jurisdictions and coastal buffers in adjacent polygons. This feature layer is for public use.Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal Buffers (this dataset)Counties: 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 BuffersCity and County AbbreviationsUnincorporated Areas (Coming Soon)Census Designated PlacesCartographic 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 source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except OFFSHORE and AREA_SQMI to get a version with the correct identifiers.Point of ContactCalifornia Department of Technology, Office of Digital Services, odsdataservices@state.ca.govField and Abbreviation DefinitionsCDTFA_CITY: CDTFA incorporated city nameCDTFA_COUNTY: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.CDTFA_COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system. The boundary data originate with CDTFA's teams managing tax rate information, so this field is preserved and flows into this dataset.CENSUS_GEOID: numeric geographic identifiers from the US Census BureauCENSUS_PLACE_TYPE: City, County, or Town, stripped off the census name for identification purpose.GNIS_PLACE_NAME: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.CDT_CITY_ABBR: Abbreviations of incorporated area names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 4 characters. Not present in the county-specific layers.CDT_COUNTY_ABBR: Abbreviations of county names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 3 characters.CDT_NAME_SHORT: The name of the jurisdiction (city or county) with the word "City" or "County" stripped off the end. Some changes may come to how we process this value to make it more consistent.AREA_SQMI: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.OFFSHORE: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".PRIMARY_DOMAIN: Currently empty/null for all records. Placeholder field for official URL of the city or countyCENSUS_POPULATION: Currently null for all records. In the future, it will include the most recent US Census population estimate for the jurisdiction.GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.Boundary AccuracyCounty boundaries were originally derived from a 1:24,000 accuracy dataset, with improvements made in some places to boundary alignments based on research into historical records and boundary changes as CDTFA learns of them. City boundary data are derived from pre-GIS tax maps, digitized at BOE and CDTFA, with adjustments made directly in GIS for new annexations, detachments, and corrections. Boundary accuracy within the dataset varies. While CDTFA strives to correctly include or exclude parcels from jurisdictions for accurate tax assessment, this dataset does not guarantee that a parcel is placed in the correct jurisdiction. When a parcel is in the correct jurisdiction, this dataset cannot guarantee accurate placement of boundary lines within or between parcels or rights of way. This dataset also provides no information on parcel boundaries. For exact jurisdictional or parcel boundary locations, please consult the county assessor's office and a licensed surveyor.CDTFA's data is used as the best available source because BOE and CDTFA receive information about changes in jurisdictions which otherwise need to be collected independently by an agency or company to compile into usable map boundaries. CDTFA maintains the best available statewide boundary information.CDTFA's source data notes the following about accuracy:City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties.In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose.SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More

A major objective of plant ecology research is to determine the underlying processes responsible for the observed spatial distribution patterns of plant species. Plants can be approximated as points in space for this purpose, and thus, spatial point pattern analysis has become increasingly popular in ecological research. The basic piece of data for point pattern analysis is a point location of an ecological object in some study region. Therefore, point pattern analysis can only be performed if data can be collected. However, due to the lack of a convenient sampling method, a few previous studies have used point pattern analysis to examine the spatial patterns of grassland species. This is unfortunate because being able to explore point patterns in grassland systems has widespread implications for population dynamics, community-level patterns and ecological processes. In this study, we develop a new method to measure individual coordinates of species in grassland communities. This method records plant growing positions via digital picture samples that have been sub-blocked within a geographical information system (GIS). Here, we tested out the new method by measuring the individual coordinates of Stipa grandis in grazed and ungrazed S. grandis communities in a temperate steppe ecosystem in China. Furthermore, we analyzed the pattern of S. grandis by using the pair correlation function g(r) with both a homogeneous Poisson process and a heterogeneous Poisson process. Our results showed that individuals of S. grandis were overdispersed according to the homogeneous Poisson process at 0-0.16 m in the ungrazed community, while they were clustered at 0.19 m according to the homogeneous and heterogeneous Poisson processes in the grazed community. These results suggest that competitive interactions dominated the ungrazed community, while facilitative interactions dominated the grazed community. In sum, we successfully executed a new sampling method, using digital photography and a Geographical Information System, to collect experimental data on the spatial point patterns for the populations in this grassland community.

Methods 1. Data collection using digital photographs and GIS

A flat 5 m x 5 m sampling block was chosen in a study grassland community and divided with bamboo chopsticks into 100 sub-blocks of 50 cm x 50 cm (Fig. 1). A digital camera was then mounted to a telescoping stake and positioned in the center of each sub-block to photograph vegetation within a 0.25 m2 area. Pictures were taken 1.75 m above the ground at an approximate downward angle of 90° (Fig. 2). Automatic camera settings were used for focus, lighting and shutter speed. After photographing the plot as a whole, photographs were taken of each individual plant in each sub-block. In order to identify each individual plant from the digital images, each plant was uniquely marked before the pictures were taken (Fig. 2 B).

Digital images were imported into a computer as JPEG files, and the position of each plant in the pictures was determined using GIS. This involved four steps: 1) A reference frame (Fig. 3) was established using R2V software to designate control points, or the four vertexes of each sub-block (Appendix S1), so that all plants in each sub-block were within the same reference frame. The parallax and optical distortion in the raster images was then geometrically corrected based on these selected control points; 2) Maps, or layers in GIS terminology, were set up for each species as PROJECT files (Appendix S2), and all individuals in each sub-block were digitized using R2V software (Appendix S3). For accuracy, the digitization of plant individual locations was performed manually; 3) Each plant species layer was exported from a PROJECT file to a SHAPE file in R2V software (Appendix S4); 4) Finally each species layer was opened in Arc GIS software in the SHAPE file format, and attribute data from each species layer was exported into Arc GIS to obtain the precise coordinates for each species. This last phase involved four steps of its own, from adding the data (Appendix S5), to opening the attribute table (Appendix S6), to adding new x and y coordinate fields (Appendix S7) and to obtaining the x and y coordinates and filling in the new fields (Appendix S8).

1. Data reliability assessment

To determine the accuracy of our new method, we measured the individual locations of Leymus chinensis, a perennial rhizome grass, in representative community blocks 5 m x 5 m in size in typical steppe habitat in the Inner Mongolia Autonomous Region of China in July 2010 (Fig. 4 A). As our standard for comparison, we used a ruler to measure the individual coordinates of L. chinensis. We tested for significant differences between (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler (see section 3.2 Data Analysis). If (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler, did not differ significantly, then we could conclude that our new method of measuring the coordinates of L. chinensis was reliable.

We compared the results using a t-test (Table 1). We found no significant differences in either (1) the coordinates of L. chinensis or (2) the pair correlation function g of L. chinensis. Further, we compared the pattern characteristics of L. chinensis when measured by our new method against the ruler measurements using a null model. We found that the two pattern characteristics of L. chinensis did not differ significantly based on the homogenous Poisson process or complete spatial randomness (Fig. 4 B). Thus, we concluded that the data obtained using our new method was reliable enough to perform point pattern analysis with a null model in grassland communities.

Analysis of ‘King County Tax Parcel Centroids with select City of Seattle geographic overlays’ provided by Analyst-2 (analyst-2.ai), based on source dataset retrieved from https://catalog.data.gov/dataset/360b2b98-85f4-4a30-ae63-1b047824ef61 on 13 February 2022.

--- Dataset description provided by original source is as follows ---

--- Original source retains full ownership of the source dataset ---

These collections of NetMap stream reaches, confluence-to-confluence streamlines, reach contributing areas, and reach contributing area valley bottoms within the YK basin are organized by major river region, and by HUC8 hydrologic units within those river regions. These files form the basis of the main data release items covering the entire YK basin, and were included as a separate zip files here for users with a specific area of interest who do not wish to download the entire YK dataset. Attribute fields are identical to the YK dataset, and include uRCA fields for all HUC8-level features. The field representing the uRCA ID in the shapefile facilitates join operations between tables of various stream attribute data and habitat potential model results. These attributes can be used for further analysis and/or visualization in a GIS. Users who download spatial data for an individual region should therefore also download the tabular data for the full YK dataset to join model results. For detailed metadata for the files in each major river region zip, please reference metadata for analogous data items in the full YK dataset. Attributes, processing steps, and and other information will be identical, since the full YK dataset is simply the combination of all the individual files found in the major river region zips.

Soil map units are the basic geographic unit of the Soil Survey Geographic Database (SSURGO). The SSURGO dataset is a compilation of soils information collected over the last century by the Natural Resources Conservation Service (NRCS). Map units delineate the extent of different soils. Data for each map unit contains descriptions of the soil’s components, productivity, unique properties, and suitability interpretations. Each soil type has a unique combination of physical, chemical, nutrient and moisture properties. Soil type has ramifications for engineering and construction activities, natural hazards such as landslides, agricultural productivity, the distribution of native plant and animal life and hydrologic and other physical processes. Soil types in the context of climate and terrain can be used as a general indicator of engineering constraints, agriculture suitability, biological productivity and the natural distribution of plants and animals. Data from thegSSURGO databasewas used to create this layer. To download ready-to-use project packages of useful soil data derived from the SSURGO dataset, please visit the USA SSURGO Downloader app. Dataset Summary Phenomenon Mapped:Soils of the United States and associated territoriesGeographic Extent:The 50 United States, Puerto Rico, Guam, US Virgin Islands, Marshall Islands, Northern Marianas Islands, Palau, Federated States of Micronesia, and American SamoaCoordinate System:Web Mercator Auxiliary SphereVisible Scale:1:144,000 to 1:1,000Source:USDA Natural Resources Conservation Service Update Frequency:AnnualPublication Date:December 2024 What can you do with this layer?Feature layers work throughout the ArcGIS system. Generally your work flow with feature layers will begin in ArcGIS Online or ArcGIS Pro. Below are just a few of the things you can do with a feature service in Online and Pro.ArcGIS Online Add this layer to a map in the map viewer. The layer is limited to scales of approximately 1:144,000 or larger but avector tile layercreated from the same data can be used at smaller scales to produce awebmapthat displays across the full scale range. The layer or a map containing it can be used in an application.Change the layer’s transparency and set its visibility rangeOpen the layer’s attribute table and make selections and apply filters. Selections made in the map or table are reflected in the other. Center on selection allows you to zoom to features selected in the map or table and show selected records allows you to view the selected records in the table.Change the layer’s style and filter the data. For example, you could set a filter forFarmland Class= "All areas are prime farmland" to create a map of only prime farmland.Add labels and set their propertiesCustomize the pop-upArcGIS Pro Add this layer to a 2d or 3d map. The same scale limit as Online applies in ProUse as an input to geoprocessing. For example, copy features allows you to select then export portions of the data to a new feature class.Change the symbology and the attribute field used to symbolize the dataOpen table and make interactive selections with the mapModify the pop-upsApply Definition Queries to create sub-sets of the layerThis layer is part of theLiving Atlas of the Worldthat provides an easy way to explore the landscape layers and many other beautiful and authoritative maps on hundreds of topics. Data DictionaryAttributesKey fields from nine commonly used SSURGO tables were compiled to create the 173 attribute fields in this layer. Some fields were joined directly to the SSURGO Map Unit polygon feature class while others required summarization and other processing to create a 1:1 relationship between the attributes and polygons prior to joining the tables. Attributes of this layer are listed below in their order of occurrence in the attribute table and are organized by the SSURGO table they originated from and the processing methods used on them. Map Unit Polygon Feature Class Attribute TableThe fields in this table are from the attribute table of the Map Unit polygon feature class which provides the geographic extent of the map units. Area SymbolSpatial VersionMap Unit Symbol Map Unit TableThe fields in this table have a 1:1 relationship with the map unit polygons and were joined to the table using the Map Unit Key field. Map Unit NameMap Unit KindFarmland ClassInterpretive FocusIntensity of MappingIowa Corn Suitability Rating Legend TableThis table has 1:1 relationship with the Map Unit table and was joined using the Legend Key field. Project Scale Survey Area Catalog TableThe fields in this table have a 1:1 relationship with the polygons and were joined to the Map Unit table using the Survey Area Catalog Key and Legend Key fields. Survey Area VersionTabular Version Map Unit Aggregated Attribute TableThe fields in this table have a 1:1 relationship with the map unit polygons and were joined to the Map Unit attribute table using the Map Unit Key field. Slope Gradient - Dominant ComponentSlope Gradient - Weighted AverageBedrock Depth - MinimumWater Table Depth - Annual MinimumWater Table Depth - April to June MinimumFlooding Frequency - Dominant ConditionFlooding Frequency - MaximumPonding Frequency - PresenceAvailable Water Storage 0-25 cm - Weighted AverageAvailable Water Storage 0-50 cm - Weighted AverageAvailable Water Storage 0-100 cm - Weighted AverageAvailable Water Storage 0-150 cm - Weighted AverageDrainage Class - Dominant ConditionDrainage Class - WettestHydrologic Group - Dominant ConditionIrrigated Capability Class - Dominant ConditionIrrigated Capability Class - Proportion of Mapunit with Dominant ConditionNon-Irrigated Capability Class - Dominant ConditionNon-Irrigated Capability Class - Proportion of Mapunit with Dominant ConditionRating for Buildings without Basements - Dominant ConditionRating for Buildings with Basements - Dominant ConditionRating for Buildings with Basements - Least LimitingRating for Buildings with Basements - Most LimitingRating for Septic Tank Absorption Fields - Dominant ConditionRating for Septic Tank Absorption Fields - Least LimitingRating for Septic Tank Absorption Fields - Most LimitingRating for Sewage Lagoons - Dominant ConditionRating for Sewage Lagoons - Dominant ComponentRating for Roads and Streets - Dominant ConditionRating for Sand Source - Dominant ConditionRating for Sand Source - Most ProbableRating for Paths and Trails - Dominant ConditionRating for Paths and Trails - Weighted AverageErosion Hazard of Forest Roads and Trails - Dominant ComponentHydric Classification - Presence Rating for Manure and Food Processing Waste - Weighted Average Component Table – Dominant ComponentMap units have one or more components. To create a 1:1 join component data must be summarized by map unit. For these fields a custom script was used to select the component with the highest value for the Component Percentage Representative Value field (comppct_r). Ties were broken with the Slope Representative Value field (slope_r). Components with lower average slope were selected as dominant. If both soil order and slope were tied, the first value in the table was selected. Component Percentage - Low ValueComponent Percentage - Representative ValueComponent Percentage - High ValueComponent NameComponent KindOther Criteria Used to Identify ComponentsCriteria Used to Identify Components at the Local LevelRunoff ClassSoil loss tolerance factorWind Erodibility IndexWind Erodibility GroupErosion ClassEarth Cover 1Earth Cover 2Hydric ConditionHydric RatingAspect Range - Counter Clockwise LimitAspect - Representative ValueAspect Range - Clockwise LimitGeomorphic DescriptionNon-Irrigated Capability SubclassNon-Irrigated Unit Capability ClassIrrigated Capability SubclassIrrigated Unit Capability ClassConservation Tree Shrub GroupGrain Wildlife HabitatGrass Wildlife HabitatHerbaceous Wildlife HabitatShrub Wildlife HabitatConifer Wildlife HabitatHardwood Wildlife HabitatWetland Wildlife HabitatShallow Water Wildlife HabitatRangeland Wildlife HabitatOpenland Wildlife HabitatWoodland Wildlife HabitatWetland Wildlife HabitatSoil Slip PotentialSusceptibility to Frost HeavingConcrete CorrosionSteel CorrosionTaxonomic ClassTaxonomic OrderTaxonomic SuborderGreat GroupSubgroupParticle SizeParticle Size ModCation Exchange Activity ClassCarbonate ReactionTemperature ClassMoist SubclassSoil Temperature RegimeEdition of Keys to Soil Taxonomy Used to Classify SoilCalifornia Storie IndexComponent Key Component Table – Weighted AverageMap units may have one or more soil components. To create a 1:1 join, data from the Component table must be summarized by map unit. For these fields a custom script was used to calculate an average value for each map unit weighted by the Component Percentage Representative Value field (comppct_r). Slope Gradient - Low ValueSlope Gradient - Representative ValueSlope Gradient - High ValueSlope Length USLE - Low ValueSlope Length USLE - Representative ValueSlope Length USLE - High ValueElevation - Low ValueElevation - Representative ValueElevation - High ValueAlbedo - Low ValueAlbedo - Representative ValueAlbedo - High ValueMean Annual Air Temperature - Low ValueMean Annual Air Temperature - Representative ValueMean Annual Air Temperature - High ValueMean Annual Precipitation - Low ValueMean Annual Precipitation - Representative ValueMean Annual Precipitation - High ValueRelative Effective Annual Precipitation - Low ValueRelative Effective Annual Precipitation - Representative ValueRelative Effective Annual Precipitation - High ValueDays between Last and First Frost - Low ValueDays between Last and First Frost - Representative ValueDays between Last and First Frost - High ValueRange Forage Annual Potential Production - Low ValueRange Forage Annual Potential Production - Representative ValueRange Forage Annual Potential Production - High ValueInitial Subsidence - Low ValueInitial Subsidence - Representative ValueInitial Subsidence -

Location maps of monitoring sites and measured parameters in the NY State Ambient Air Monitoring Network

This street centerline lines feature class represents current right of way in the City of Los Angeles. It shows the official street names and is related to the official street name data. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works. Street Centerline layer was created in geographical information systems (GIS) software to display Dedicated street centerlines. The street centerline layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a line feature class and attribute data for the features. City of LA District Offices use Street Centerline layer to determine dedication and street improvement requirements. Engineering street standards are followed to dedicate the street for development. The Bureau of Street Services tracks the location of existing streets, who need to maintain that road. Additional information was added to Street Centerline layer. Address range attributes were added make layer useful for geocoding. Section ID values from Bureau of Street Services were added to make layer useful for pavement management. Department of City Planning added street designation attributes taken from Community Plan maps. The street centerline relates to the Official Street Name table named EASIS, Engineering Automated Street Inventory System, which contains data describing the limits of the street segment. A street centerline segment should only be added to the Street Centerline layer if documentation exists, such as a Deed or a Plan approved by the City Council. Paper streets are street lines shown on a recorded plan but have not yet come into existence on the ground. These street centerline segments are in the Street Centerline layer because there is documentation such as a Deed or a Plan for the construction of that street. Previously, some street line features were added although documentation did not exist. Currently, a Deed, Tract, or a Plan must exist in order to add street line features. Many street line features were edited by viewing the Thomas Bros Map's Transportation layer, TRNL_037 coverage, back when the street centerline coverage was created. When TBM and BOE street centerline layers were compared visually, TBM's layer contained many valid streets that BOE layer did not contain. In addition to TBM streets, Planning Department requested adding street line segments they use for reference. Further, the street centerline layer features are split where the lines intersect. The intersection point is created and maintained in the Intersection layer. The intersection attributes are used in the Intersection search function on NavigateLA on BOE's web mapping application NavigateLA. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. Note that there are named alleys in the BOE Street Centerline layer. Since the line features for named alleys are stored in the Street Centerline layer, there are no line features for named alleys in those areas that are geographically coincident in the Alley layer. For a named alley , the corresponding record contains the street designation field value of ST_DESIG = 20, and there is a name stored in the STNAME and STSFX fields.List of Fields:SHAPE: Feature geometry.OBJECTID: Internal feature number.STNAME_A: Street name Alias.ST_SUBTYPE: Street subtype.SV_STATUS: Status of street in service, whether the street is an accessible roadway. Values: • Y - Yes • N - NoTDIR: Street direction. Values: • S - South • N - North • E - East • W - WestADLF: From address range, left side.ZIP_R: Zip code right.ADRT: To address range, right side.INT_ID_TO: Street intersection identification number at the line segment's end node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.SECT_ID: Section ID used by the Bureau of Street Services. Values: • none - No Section ID value • private - Private street • closed - Street is closed from service • temp - Temporary • propose - Proposed construction of a street • walk - Street line is a walk or walkway • known as - • numeric value - A 7 digit numeric value for street resurfacing • outside - Street line segment is outside the City of Los Angeles boundary • pierce - Street segment type • alley - Named alleySTSFX_A: Street suffix Alias.SFXDIR: Street direction suffix Values: • N - North • E - East • W - West • S - SouthCRTN_DT: Creation date of the polygon feature.STNAME: Street name.ZIP_L: Zip code left.STSFX: Street suffix. Values: • BLVD - BoulevardADLT: To address range, left side.ID: Unique line segment identifierMAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral tract index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers.STNUM: Street identification number. This field relates to the Official Street Name table named EASIS, to the corresponding STR_ID field.ASSETID: User-defined feature autonumber.TEMP: This attribute is no longer used. This attribute was used to enter 'R' for reference arc line segments that were added to the spatial data, in coverage format. Reference lines were temporary and not part of the final data layer. After editing the permanent line segments, the user would delete temporary lines given by this attribute.LST_MODF_DT: Last modification date of the polygon feature.REMARKS: This attribute is a combination of remarks about the street centerline. Values include a general remark, the Council File number, which refers the street status, or whether a private street is a private driveway. The Council File number can be researched on the City Clerk's website http://cityclerk.lacity.org/lacityclerkconnect/INT_ID_FROM: Street intersection identification number at the line segment's start node. The value relates to the intersection layer attribute table, to the CL_NODE_ID field. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline data layer and then the intersections data layer, during the creation of new intersection points. Each intersection identification number is a unique value.ADRF: From address range, right side.

Unlock precise, high-quality GIS data covering 43M+ verified locations across the USA. With 50+ enriched attributes including coordinates, building structures, and spatial geometry our dataset provides the granularity and accuracy needed for in-depth spatial analysis. Powered by AI-driven enrichment and deduplication, and backed by 30+ years of expertise, our GIS solutions support industries ranging from mapping and navigation to urban planning and market analysis, helping businesses and organizations make smarter, data-driven decisions.

Key use cases of GIS Data helping our customers :

1. Optimize Mapping & Spatial Analysis : Use GIS data to analyse landscapes, urban infrastructure, and competitor locations, ensuring data-driven planning and decision-making.
2. Enhance Navigation & Location-Based Services : Improve real-time route planning, asset tracking, and EV charging station discovery for seamless location-based experiences.
3. Identify Strategic Sites for Business Expansion : Leverage GIS intelligence to select optimal retail sites, franchise locations, and warehouses with precision.
4. Improve Logistics & Address Accuracy : Streamline delivery networks, validate addresses, and optimize courier routes to boost efficiency and customer satisfaction.
5. Support Environmental & Urban Development Initiatives : Utilize GIS insights for disaster preparedness, sustainable city planning, and land-use management.

The Global Urban Network (GUN) dataset provides pre-computed node and edge attribute features for various cities. Each layer is available in .geojson format and can easily be converted into NetworkX, igraph, PyG, and DGL graph formats.

For node attributes, we adopt a uniform Euclidean approach, as it provides a consistent, straightforward, and extensible basis for integrating heterogeneous data sources across different network locations. Accordingly, we construct 100 metres euclidean buffers for each network node and compute the spatial intersection with spatial targets (e.g., street view imagery points, points of interest, and building footprints). To ensure spatial consistency and accurate distance computation, we project spatial entities into local coordinate reference systems (CRS). Users can employ the Urbanity package to generate Euclidean buffers of arbitrary distance.

For edge attributes, we adopt a two-step approach: 1) compute the distance between each spatial point of interest and its proximate edges in the network, and 2) assign entities to the corresponding edge with lowest distance. To account for remote edges (e.g., peripheral routes that are not located close to any amenities), we specify a distance threshold of 50 metres. For buildings, we compute the distance between building centroids and their respective network edge. Accordingly, we compute spatial indicators based on the set of elements assigned to each network edge.

We also release aggregated subzone statistics for each city. Similarly, users can employ the Urbanity package to generate aggregate statistics for any arbitrary geographic boundary.

Urbanity Python package: https://github.com/winstonyym/urbanity.

The New York State and National Register listings geographic dataset for Onondaga County was originally developed by the New York State Historic Preservation Office (NYSHPO) in May, 2004. Shortly after its production, this dataset was delivered to the Syracuse-Onondaga County Planning Agency (SOCPA) for use in the Agency's GIS database. Minor annual edits to the file have been conducted by SOCPA staff to ensure completeness and positional agreement with Onondaga County's parcel file and NYS orthophotography. The resulting file uses polygon features to represent both NYS/NR sites and NYS/NR districts in an ESRI shapefile format. All features and attributes were retained from the original NYSHPO dataset. Two additional attributes were created by SOCPA staff, one to classify polygon features as either sites or districts for cartographic display and one to identify the municipality.Data Dictionary:Attribute:Attribute Label: RESNAMEAttribute Definition: Feature NameAttribute Definition Source: NYSHPOAttribute:Attribute Label: ADDRESSAttribute Definition: Physical addressAttribute Definition Source: NYSHPOAttribute:Attribute Label: SRDATEAttribute Definition: unknownAttribute:Attribute Label: CNTYFIPSAttribute Definition: County FIPS codeAttribute Definition Source: NYSHPOAttribute:Attribute Label: COUNTYAttribute Definition: General location of featureAttribute Definition Source: NYSHPOAttribute:Attribute Label: CITYAttribute Definition: LocationAttribute Definition Source: NYSHPOAttribute:Attribute Label: CERTCDAttribute Definition: National Register Listings Code DefinitionsAttribute Definition Source: NYSHPOEnumerated Domain Value: FEEnumerated Domain Value Definition: State Register listed; determined eligible for National Register listing by the Keeper of the National RegisterEnumerated Domain Value Definition Source: NYSHPOAttribute Domain Values:Enumerated Domain Value: LIEnumerated Domain Value Definition: State and National Register listedEnumerated Domain Value Definition Source: NYSHPOAttribute Domain Values:Enumerated Domain Value: SREnumerated Domain Value Definition: State Register listed only; in most cases, National Register listing pendingEnumerated Domain Value Definition Source: NYSHPOAttribute Domain Values:Enumerated Domain Value: XXEnumerated Domain Value Definition: Listing in progressEnumerated Domain Value Definition Source: NYSHPOAttribute:Attribute Label: NRDATEAttribute Definition: unknownAttribute:Attribute Label: MUNICIPALIAttribute Definition: Municipality of featureAttribute Definition Source: SOCPAAttribute:Attribute Label: ShapeAttribute Definition: Feature geometry.Attribute Definition Source: ESRIAttribute:Attribute Label: NRNUMBERAttribute:Attribute Label: TYPEAttribute Definition: Differentiates features into districts and sitesAttribute Definition Source: SOCPA

Baltimore City Highways. No metadata was provided with this dataset; the UVM Spatial Analysis Lab has attempted to evaluate this dataset and generate metadata. When compared to high-resolution imagery and detailed street data offsets as great as 50m were observed. Due to positional accuracy errors this dataset should be used with caution. There are no attributes associated with this dataset. For the best available transportation data use the Roads_GDT_MSA dataset. This is part of a collection of 221 Baltimore Ecosystem Study metadata records that point to a geodatabase. The geodatabase is available online and is considerably large. Upon request, and under certain arrangements, it can be shipped on media, such as a usb hard drive. The geodatabase is roughly 51.4 Gb in size, consisting of 4,914 files in 160 folders. Although this metadata record and the others like it are not rich with attributes, it is nonetheless made available because the data that it represents could be indeed useful. This is part of a collection of 221 Baltimore Ecosystem Study metadata records that point to a geodatabase. The geodatabase is available online and is considerably large. Upon request, and under certain arrangements, it can be shipped on media, such as a usb hard drive. The geodatabase is roughly 51.4 Gb in size, consisting of 4,914 files in 160 folders. Although this metadata record and the others like it are not rich with attributes, it is nonetheless made available because the data that it represents could be indeed useful.

See full Data Guide here. Drainage Basin Set: Connecticut Drainage Basins is 1:24,000-scale, polygon and line feature data that define natural drainage areas in Connecticut. These are small basin areas that average approximately 1 square mile in size and make up, in order of increasing size, the larger local, subregional, regional, and major drainage basin areas. Connecticut Drainage Basins includes drainage areas for all Connecticut rivers, streams, brooks, lakes, reservoirs and ponds published on 1:24,000-scale 7.5 minute topographic quadrangle maps prepared by the USGS between 1969 and 1984. Data is compiled at 1:24,000 scale (1 inch = 2,000 feet). This information is not updated. Polygon and line features represent drainage basin areas and boundaries, respectively. Each basin area (polygon) feature is outlined by one or more major, regional, subregional, local, impoundment, or river reach boundary (line) feature. These data include 7,076 basin area (polygon) features and 20,945 basin boundary (line) features. Basin area (polygon) attributes include major, regional, subregional, local, (full) basin number, and feature size in acres and square miles. The full basin number (BASIN_NO) uniquely identifies individual basins and is up to 13 characters in length. There are 7,031 unique basin numbers. Examples include 6000-00-1+*, 4300-00-1+L1, and 6002-00-2-R1. The first digit (column 1) designates the major basin, the first two digits (columns 1-2) designate the regional basin, the first 4 digits (columns 1-4) designate the subregional basin, and the first seven digits (columns 1-7) designate the local basin. Note, there are slightly more basin polygon features (7,076) than unique basin numbers (7,031) primarily because a few water supply watershed boundaries split a basin into two polygon features at the _location of a small dam or point of diversion along a stream. Basin boundary (line) attributes include a drainage divide type attribute (DIVIDE) used to cartographically represent the hierarchical drainage basin system. This divide type attribute is used to assign different line symbology to major, regional, subregional, local, stream reach, and lake impoundment drainage basin divides. For example, major basin drainage divides are more pronounced and shown with a wider line symbol than regional basin drainage divides. Connecticut Drainage Basins is the data source for other digital spatial data including the Connecticut Major Drainage Basins, Connecticut Regional Drainage Basins, Connecticut Subregional Drainage Basins, and Connectcut Local Drainage Basins. Purpose: The polygon features define the contributing drainage area for individual reservoirs, lakes, ponds and river and stream reaches in Connecticut. These are hydrologic land units where precipitation is collected. Rain falling in a basin may take two courses. It may both run over the land and quickly enter surface watercourses, or it may soak into the ground moving through the earth until it surfaces at a wetland or stream. In an undisturbed natural drainage basin, the surface and ground water arrive as precipitation and leave either by evaporation or as surface runoff at the basin's outlet. A basin is a self-contained hydrologic system, with a clearly defined water budget and cycle. The amount of water that flows into the basins equals the amount that leaves. A drainage divide is the topographic barrier along a ridge or line of hilltops separating adjacent drainage basins. For example, rain or snow melt draining down one side of a hill generally will flow into a different basin and stream than water draining down the other side of the hill. These hillsides are separated by a drainage divided that follows nearby hilltops and ridge lines. Use these basin data to identify where rainfall flows over land and downstream to a particular watercourse. Use these data

This parcels polygons feature class represents current city parcels within the City of Los Angeles. It shares topology with the Landbase parcel lines feature class. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way, ownership and land record information. The legal boundaries are determined on the ground by license surveyors in the State of California, and by recorded documents from the Los Angeles County Recorder's office and the City Clerk's office of the City of Los Angeles. Parcel and ownership information are available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Associated information about the landbase parcels is entered into attributes. Principal attributes include:PIN and PIND: represents the unique auto-generated parcel identifier and key to related features and tables. This field is related to the LA_LEGAL, LA_APN and LA_HSE_NBR tables. PIN contains spaces and PIND replaces those spaces with a dash (-).LA_LEGAL - Table attributes containing legal description. Principal attributes include the following:TRACT: The subdivision tract number as recorded by the County of Los AngelesMAP_REF: Identifies the subdivision map book reference as recorded by the County of Los Angeles.LOT: The subdivision lot number as recorded by the County of Los Angeles.ENG_DIST: The four engineering Districts (W=Westla, C=Central, V= Valley and H=Harbor).CNCL_DIST: Council Districts 1-15 of the City of Los Angeles. OUTLA means parcel is outside the City.LA_APN- Table attributes containing County of Los Angeles Assessors information. Principal attributes include the following:BPP: The Book, Page and Parcel from the Los Angeles County Assessors office. SITUS*: Address for the property.LA_HSE_NBR - Table attributes containing housenumber information. Principal attributes include the following:HSE_ID: Unique id of each housenumber record.HSE_NBR: housenumber numerical valueSTR_*: Official housenumber addressFor a complete list of attribute values, please refer to Landbase_parcel_polygons_data_dictionary.Landbase parcels polygons data layer was created in geographical information systems (GIS) software to display the location of the right of way. The parcels polygons layer delineates the right of way from Landbase parcels lots. The parcels polygons layer is a feature class in the LACityLandbaseData.gdb Geodatabase dataset. The layer consists of spatial data as a polygon feature class and attribute data for the features. The area inside a polygon feature is a parcel lot. The area outside of the parcel polygon feature is the right of way. Several polygon features are adjacent, sharing one line between two polygons. For each parcel, there is a unique identifier in the PIND and PIN fields. The only difference is PIND has a dash and PIN does not. The types of edits include new subdivisions and lot cuts. Associated legal information about the landbase parcels lots is entered into attributes. The landbase parcels layer is vital to other City of LA Departments, by supporting property and land record operations and identifying legal information for City of Los Angeles. The landbase parcels polygons are inherited from a database originally created by the City's Survey and Mapping Division. Parcel information should only be added to the Landbase Parcels layer if documentation exists, such as a Deed or a Plan approved by the City Council. When seeking the definitive description of real property, consult the recorded Deed or Plan.List of Fields:ID: A unique numeric identifier of the polygon. The ID value is the last part of the PIN field value.ASSETID: User-defined feature autonumber.MAPSHEET: The alpha-numeric mapsheet number, which refers to a valid B-map or A-map number on the Cadastral grid index map. Values: • B, A, -5A - Any of these alpha-numeric combinations are used, whereas the underlined spaces are the numbers. An A-map is the smallest grid in the index map and is used when there is a large amount of spatial information in the map display. There are more parcel lines and annotation than can fit in the B-map, and thus, an A-map is used. There are 4 A-maps in a B-map. In areas where parcel lines and annotation can fit comfortably in an index map, a B-map is used. The B-maps are at a scale of 100 feet, and A-maps are at a scale of 50 feet.OBJECTID: Internal feature number.BPPMAP_REFTRACTBLOCKMODLOTARBCNCL_DIST: LA City Council District. Values: • (numbers 1-15) - Current City Council Member for that District can be found on the mapping website http://navigatela.lacity.org/navigatela, click Council Districts layer name, under Boundaries layer group.SHAPE: Feature geometry.BOOKPAGEPARCELPIND: The value is a combination of MAPSHEET and ID fields, creating a unique value for each parcel. The D in the field name PIND, means "dash", and there is a dash between the MAPSHEET and ID field values. This is a key attribute of the LANDBASE data layer. This field is related to the APN and HSE_NBR tables.ENG_DIST: LA City Engineering District. The boundaries are displayed in the Engineering Districts index map. Values: • H - Harbor Engineering District. • C - Central Engineering District. • V - Valley Engineering District. • W - West LA Engineering District.PIN: The value is a combination of MAPSHEET and ID fields, creating a unique value for each parcel. There are spaces between the MAPSHEET and ID field values. This is a key attribute of the LANDBASE data layer. This field is related to the APN and HSE_NBR tables.

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.4947 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.0029 and 0.3665 (in million kms), corressponding to 0.5881% and 74.094% respectively of the total road length in the dataset region. 0.1252 million km or 25.3179% of road surface information is missing in OSM. In order to fill this gap, Mapillary derived road surface dataset provides an additional 0.0 million km of information (corressponding to 0.0006% 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.

Land use data is critically important to the work of the Department of Water Resources (DWR) and other California agencies. Understanding the impacts of land use, crop location, acreage, and management practices on environmental attributes and resource management is an integral step in the ability of Groundwater Sustainability Agencies (GSAs) to produce Groundwater Sustainability Plans (GSPs) and implement projects to attain sustainability. Land IQ was contracted by DWR to develop a comprehensive and accurate spatial land use database for the 2021 water year (WY 2021), covering over 10.7 million acres of agriculture on a field scale and additional areas of urban extent.The primary objective of this effort was to produce a spatial land use database with an accuracy exceeding 95% using remote sensing, statistical, and temporal analysis methods. This project is an extension of the land use mapping which began in the 2014 crop year, which classified over 15 million acres of land into agricultural and urban areas. Unlike the 2014 and 2016 datasets, the annual WY datasets from and including 2018, 2019, 2020, and 2021 include multi-cropping.Land IQ integrated crop production knowledge with detailed ground truth information and multiple satellite and aerial image resources to conduct remote sensing land use analysis at the field scale. Individual fields (boundaries of homogeneous crop types representing true cropped area, rather than legal parcel boundaries) were classified using a crop category legend and a more specific crop type legend. A supervised classification process using a random forest approach was used to classify delineated fields and was carried out county by county where training samples were available. Random forest approaches are currently some of the highest performing methods for data classification and regression. To determine frequency and seasonality of multicropped fields, peak growth dates were determined for each field of annual crops. Fields were attributed with DWR crop categories, which included citrus/subtropical, deciduous fruits and nuts, field crops, grain and hay, idle, pasture, rice, truck crops, urban, vineyards, and young perennials. These categories represent aggregated groups of specific crop types in the Land IQ dataset.Accuracy was calculated for the crop mapping using both DWR and Land IQ crop legends. The overall accuracy result for the crop mapping statewide was 97% using the Land IQ legend (Land IQ Subclass) and 98% using the DWR legend (DWR Class). Accuracy and error results varied among crop types. Some less extensive crops that have very few validation samples may have a skewed accuracy result depending on the number and nature of validation sample points. DWR revised crops and conditions from the Land IQ classification were encoded using standard DWR land use codes added to feature attributes, and each modified classification is indicated by the value 'r' in the ‘DWR_REVISE' data field. Polygons drawn by DWR, not included in Land IQ dataset receive the 'n' code for new. Boundary change (i.e. DWR changed the boundary that LIQ delivered, could be split boundary) indicated by 'b'. Each polygon classification is consistent with DWR attribute standards, however some of DWR's traditional attribute definitions are modified and extended to accommodate unavoidable constraints within remote-sensing classifications, or to make data more specific for DWR's water balance computation needs. The original Land IQ classifications reported for each polygon are preserved for comparison, and are also expressed as DWR standard attributes. Comments, problems, improvements, updates, or suggestions about local conditions or revisions in the final data set should be forwarded to the appropriate Regional Office Senior Land Use Supervisor.Revisions were made if:- DWR corrected the original crop classification based on local knowledge and analysis,-PARTIALLY IRRIGATED CROPS Crops, irrigated for only part of their normal irrigation season were given the special condition of ‘X’,-In certain areas, DWR changed the irrigation status to non-irrigated. Among those areas the special condition may have been changed to 'Partially Irrigated' based on image analysis and local knowledge,- young versus mature stages of perennial orchards and vineyards were identified (DWR added ‘Young’ to Special Condition attributes),- DWR determined that a field originally classified ‘Idle’ or 'Unclassified' were actually cropped one or more times during the year,- the percent of cropped area was changed from the original acres reported by Land IQ (values indicated in DWR ‘Percent’ column),- DWR determined that the field boundary should have been changed to better reflect the cropped area of the polygon and is identified by a 'b' in the DWR_REVISED column,- DWR determined that the field boundary should have been split to better reflect separate crops within the same polygon and identified by a 'b' in the DWR_REVISED column,- The ‘Mixed’ was added to the MULTIUSE column refers to no boundary change, but percent of field is changed where more than one crop is found,- DWR identified a distinct early or late crop on the field before the main season crop (‘Double’ was added to the MULTIUSE column); if the 1st and 2nd sequential crops occupied different portions of the total field acreage, the area percentages were indicated for each crop).This dataset includes multicropped fields. If the field was determined to have more than one crop during the course of the WY (Water Year begins October 1 and ends September 30 of the following year), the order of the crops is sequential, beginning with Class 1. All single cropped fields will be placed in Class 2, so every polygon will have a crop in the Class 2 and CropType2 columns. In the case that a permanent crop was removed during the WY, the Class 2 crop will be the permanent crop followed by ‘X’ – Unclassified fallow in the Class 3 column. In the case of Intercropping, the main crop will be placed in the Class 2 column with the partial crop in the Class 3 column.A new column for the 2019, 2020, and 2021 datasets is called ‘MAIN_CROP’. This column indicates which field Land IQ identified as the main season crop for the WY representing the crop grown during the dominant growing season for each county. The column ‘MAIN_CROP_DATE’, another addition to the 2019, 2020, and 2021 datasets, indicates the Normalized Difference Vegetation Index (NDVI) peak date for this main season crop. The column 'EMRG_CROP' for 2019, 2020, and 2021 indicates an emerging crop at the end of the WY. Crops listed indicate that at the end of the WY, September 2021, crop activity was detected from a crop that reached peak NDVI in the following WY (2022 WY). This attribute is included to account for water use of crops that span multiple WYs and are not exclusive to a single WY. It is indicative of early crop growth and initial water use in the current WY, but a majority of crop development and water use in the following WY. Crops listed in the ‘EMRG_CROP’ attribute will also be captured as the first crop (not necessarily Crop 1) in the following WY (2022 WY). These crops are not included in the 2021 UCF_ATT code as their peak date occurred in the following WY.For the 2021 dataset new columns added are: 'YR_PLANTED' which represent the year orchard / grove was planted. 'SEN_CROP' indicates a senescing crop at the beginning of the WY. Crops listed indicate that at the beginning of the WY, October 2020, crop activity was detected from a crop that reached peak NDVI in the previous WY (2020 WY), thus was a senescing crop. This is included to account for water use of crop growth periods that span multiple WYs and are not exclusive to a WY. Crops listed in the ‘SEN_CROP’ attribute are also captured in the CROPTYP 1 through 4 sequence of the previous WY (2020 WY). These crops are not included in the 2021 UCF_ATT code as their peak NDVI occurred in the previous WY. CTYP#_NOTE: indicates a more specific land use subclassification from the DWR Standard Land Use Legend that is not included in the primary, DWR Remote Sensing Land Use Legend.DWR reviewed and revised the data in some cases. The associated data are considered DWR enterprise GIS data, which meet all appropriate requirements of the DWR Spatial Data Standards, specifically the DWR Spatial Data Standard version 3.6, dated September 27, 2023. This data set was not produced by DWR. Data were originally developed and supplied by Land IQ, LLC, under contract to California Department of Water Resources. DWR makes no warranties or guarantees - either expressed or implied - as to the completeness, accuracy, or correctness of the data. DWR neither accepts nor assumes liability arising from or for any incorrect, incomplete, or misleading subject data. Detailed compilation and reviews of Statewide Crop Mapping and metadata development were performed by DWR Land Use Unit staff, therefore you may forward your questions to Landuse@water.ca.gov.This dataset is current as of 2021.

The TIGER/Line shapefiles and related database files (.dbf) are an extract of selected geographic and cartographic information from the U.S. Census Bureau's Master Address File / Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) Database (MTDB). The MTDB represents a seamless national file with no overlaps or gaps between parts, however, each TIGER/Line shapefile is designed to stand alone as an independent data set, or they can be combined to cover the entire nation. The Feature Names Relationship File (FEATNAMES.dbf) contains a record for each feature name and any attributes associated with it. Each feature name can be linked to the corresponding edges that make up that feature in the All Lines Shapefile (EDGES.shp), where applicable to the corresponding address range or ranges in the Address Ranges Relationship File (ADDR.dbf), or to both files. Although this file includes feature names for all linear features, not just road features, the primary purpose of this relationship file is to identify all street names associated with each address range. An edge can have several feature names; an address range located on an edge can be associated with one or any combination of the available feature names (an address range can be linked to multiple feature names). The address range is identified by the address range identifier (ARID) attribute, which can be used to link to the Address Ranges Relationship File (ADDR.dbf). The linear feature is identified by the linear feature identifier (LINEARID) attribute, which can be used to relate the address range back to the name attributes of the feature in the Feature Names Relationship File or to the feature record in the Primary Roads, Primary and Secondary Roads, or All Roads Shapefiles. The edge to which a feature name applies can be determined by linking the feature name record to the All Lines Shapefile (EDGES.shp) using the permanent edge identifier (TLID) attribute. The address range identifier(s) (ARID) for a specific linear feature can be found by using the linear feature identifier (LINEARID) from the Feature Names Relationship File (FEATNAMES.dbf) through the Address Range / Feature Name Relationship File (ADDRFN.dbf).