This resource is a member of a series. 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 All Roads Shapefile includes all features within the MTDB Super Class "Road/Path Features" distinguished where the MAF/TIGER Feature Classification Code (MTFCC) for the feature in MTDB that begins with "S". This includes all primary, secondary, local neighborhood, and rural roads, city streets, vehicular trails (4wd), ramps, service drives, alleys, parking lot roads, private roads for service vehicles (logging, oil fields, ranches, etc.), bike paths or trails, bridle/horse paths, walkways/pedestrian trails, and stairways.

The National Hydrography Dataset (NHD) is a feature-based database that interconnects and uniquely identifies the stream segments or reaches that make up the nation's surface water drainage system. NHD data was originally developed at 1:100,000-scale and exists at that scale for the whole country. This high-resolution NHD, generally developed at 1:24,000/1:12,000 scale, adds detail to the original 1:100,000-scale NHD. (Data for Alaska, Puerto Rico and the Virgin Islands was developed at high-resolution, not 1:100,000 scale.) Local resolution NHD is being developed where partners and data exist. The NHD contains reach codes for networked features, flow direction, names, and centerline representations for areal water bodies. Reaches are also defined on waterbodies and the approximate shorelines of the Great Lakes, the Atlantic and Pacific Oceans and the Gulf of Mexico. The NHD also incorporates the National Spatial Data Infrastructure framework criteria established by the Federal Geographic Data Committee.

"""District boundaries: When the zoning map shows a zoning district boundary as following a particular feature, or reflects a clear intent that the boundary follows the feature, the boundary will be construed as following that feature as it actually exists.Map interpretations: Where any uncertainty exists about a zoning boundary, the actual location of the boundary will be determined by the Zoning Administrator using the following rules of interpretation.(1) A boundary shown on the zoning map as approximately following a river, stream, lake or other watercourse will be construed as following the actual centerline of the watercourse. If, subsequent to the establishment of the boundary, the centerline of the watercourse should move as a result of natural processes (flooding, erosion, sedimentation, etc.), the boundary will be construed as moving with the centerline of the watercourse.(2) A boundary shown on the zoning map as approximately following a ridge line or topographic contour line will be construed as following the actual ridge line or contour line. If, subsequent to the establishment of the boundary, the ridge line or contour line should move as a result of natural processes (erosion, slippage, subsidence, etc.), the boundary will be construed as moving with the ridge line or contour line.(3) A boundary shown on the zoning map as approximately following lot lines or other parcel boundaries assigned by the Will County Supervisor of Assessments will be construed as following such lot lines or parcel boundaries.(4) A boundary shown on the zoning map as approximately following a street or railroad line will be construed as following the centerline of the street or railroad right-of-way.(5) A boundary shown on the zoning map as approximately following the boundary of an adjacent municipality will be construed as following that boundary.(6) A boundary shown on the zoning map as approximately parallel to, or as an apparent extension of, a feature described above will be construed as being actually parallel to, or an extension of, the feature.(7) Zoning boundaries that do not coincide with a property line, parcel boundary, landmark or particular feature will be determined with a scale.(8) It is the intent that the entire unincorporated area of the county, including all land and water areas, rivers, streets, alleys, railroads, and other right-of-ways, be included in the districts established by this zoning ordinance. If any area is not shown on the zoning map as being included in a zoning district, it will be deemed to be classified in the E-1 district until otherwise reclassified by a zoning map amendment in accordance with chapter 155-16.30."""

Download In State Plane Projection Here. Boundaries of designated high quality ADID wetlands established as a result of a formal process under the direction of the U.S. Environmental Protection Agency. Part 404(b)(1) of the Clean Water Act authorizes the USEPA and the US Army Corps of Engineers to identify in advance of specific permit requests aquatic sites which will be considered as areas generally unsuitable for disposal of dredged or fill material. This process is called an Advanced Identification or ADID. Under the ADID process identification of an area as generally unsuitable for fill does not prohibit applications for permits to fill in these areas. Therefore the ADID designation of unsuitability is advisory not regulatory. An ADID designation lets a potential applicant know in advance that a proposal to fill such a site is not likely to be consistent with the 404(b)(1) guidelines, and the USEPA will probably request permit denial. ADID wetland information is also useful in watershed planning, land use planning, public land acquisition programs, natural resource studies and other purposes. The wetland selection criteria and methodology are documented in the publication entitled "Advanced Identification (ADID) Study, Lake County, Illinois. Final Report, November 1992" which is included in this download. Boundaries were delineated by the ADID project team on orthophotograph background with an intended usage scale of 1" = 400', a scale ratio of 1:4800.

This is version 9 of plan 11.

The Hydrology Feature Dataset contains photogrammetrically compiled water drainage features and structures including rivers, streams, drainage canals, locks, dams, lakes, ponds, reservoirs and mooring cells. Rivers, Lakes, Ponds, Reservoirs, Hidden Lakes, Reservoirs or Ponds: If greater than 25 feet and less than 30 feet wide, is captured as a double line stream. If greater than 30 feet wide it is captured as a river. Lakes are large standing bodies of water greater than 5 acres in size. Ponds are large standing bodies of water greater than 1 acre and less than 5 acres in size. Polygons are created from Stream edges and River Edges. The Ohio River, Monongahela River and Allegheny River are coded as Major Rivers. All other River and Stream polygons are coded as River. If a stream is less than 25 feet wide it is placed as a single line and coded as a Stream. Both sides of the stream are digitized and coded as a Stream for Streams whose width is greater than 25 feet. River edges are digitized and coded as River. A Drainage Canal is a manmade or channelized hydrographic feature. Drainage Canals are differentiated from streams in that drainage canals have had the sides and/or bottom stabilized to prevent erosion for the predominant length of the feature. Streams may have had some stabilization done, but are primarily in a natural state. Lakes are large standing bodies of water greater than five acres in size. Ponds are large standing bodies of water greater than one acre in size and less than five acres in size. Reservoirs are manmade embankments of water. Included in this definition are both covered and uncovered water tanks. Reservoirs that are greater than one acre in size are digitized. Hidden Streams, Hidden Rivers and Hidden Drainage Canal or Culverts are those areas of drainage where the water flows through a manmade facility such as a culvert. Hydrology Annotation is not being updated but will be preserved. If a drainage feature has been removed, as apparent on the aerial photography, the associated drainage name annotation will be removed. A Mooring Cell is a structure to which tows can tie off while awaiting lockage. They are normally constructed of concrete and steel and are anchored to the river bottom by means of gravity or sheet piling. Mooring Cells do not currently exist in the Allegheny County dataset but will be added. Locks are devices that are used to control flow or access to a hydrologic feature. The edges of the Lock are captured. Dams are devices that are used to hold or delay the natural flow of water. The edges of the Dam are shown.

If viewing this description on the Western Pennsylvania Regional Data Center’s open data portal (http://www.wprdc.org), this dataset is harvested on a weekly basis from Allegheny County’s GIS data portal (http://openac.alcogis.opendata.arcgis.com/). The full metadata record for this dataset can also be found on Allegheny County’s GIS portal. You can access the metadata record and other resources on the GIS portal by clicking on the “Explore” button (and choosing the “Go to resource” option) to the right of the “ArcGIS Open Dataset” text below.

Category: Environment

Organization: Allegheny County

Department: Geographic Information Systems Group; Department of Administrative Services

Temporal Coverage: 2006

Data Notes:

Coordinate System: Pennsylvania State Plane South Zone 3702; U.S. Survey Foot

Development Notes: Original Lakes and Drainage datasets combined to create this layer. Data was updated as a result of a flyover in the spring of 2004. A database field has been defined for all map features named "Update Year". This database field will define which dataset provided each map feature. Map features from the current map will be set to "2004". The earlier dataset map features the earlier dataset map features used to supplement the area near the county boundary will be set to "1993". All new or modified map data will have the value for "Update Year" set to "2004".

Other: none

Related Document(s): Data Dictionary (https://docs.google.com/spreadsheets/d/16BWrRkoPtq2ANRkrbG7CrfQk2dUsWRiaS2Ee1mTn7l0/edit?usp=sharing)

Frequency - Data Change: As needed

Frequency - Publishing: As needed

Data Steward Name: Eli Thomas

Data Steward Email:

This dataset contains street centerlines for vehicular and foot traffic in Allegheny County. Street Centerlines are classified as Primary Road, Secondary Road, Unpaved Road, Limited Access Road, Connecting Road, Jeep Trail, Walkway, Stairway, Alleyway and Unknown. A Primary Road is a street paved with either concrete or asphalt that has two (2) or more lanes in each direction. A Secondary Road is a residential type hard surface road, or any hard surface road with only one (1) lane in each direction. An Unpaved Road is any road covered with packed dirt or gravel. A Limited Access Road is one that can only be accessed from a Connecting Road such as an Interstate Highway. A Connecting Road is a ramp connecting a Limited Access Road to a surface street. A Walkway is a paved or unpaved foot track that connects two (2) roads together. Walkways within College Campuses will also be shown. Recreational pedestrian trails and walkways through parks and wooded areas are not considered transportation and will not be digitized during this update. Walkways will not have an Edge of Pavement feature. A Stairway is a paved or wooden structure that connects two (2) roads together. Recreational pedestrian trails and walkways through parks and wooded areas are not considered transportation and will not be digitized during this update. An Alleyway is a road, usually narrower than a Secondary Road that runs between, but parallel to, two (2) Secondary Roads. Generally, Outbuildings will be adjacent to Alleyways. A Jeep Trail is a vehicular trail used for recreation. A Jeep Trail will not have an associated edge of pavement feature. A road coded as Unknown is a road, which in the judgment of the photogrammetrist, does not fall into any of the categories listed. Centerlines will be visually placed between the edges of pavement. One (1) centerline will be placed between each edge of pavement. Roads with medial strips, such as Limited Access Roads, will have two (2) centerlines for those portions of the road where the medial strip is present. For roads that terminate with a cul-de-sac, the centerline shall continue through the center of the cul-de-sac and stop at the edge of pavement. All attribute data will remain for all Street Centerlines that are not updated. For Street Centerlines that are new, the only attribute field that will be populated is the FeatureCode and UPDATE_YEAR. If a Street Centerline is graphically modified, the existing attribute data will remain and the UPDATE_YEAR will be set to 2004. The attribute values for 2004 Street Centerlines should be considered suspicious until verified. The ArcInfo Street Centerline coverage that is being updated has 800 segments of Paper Streets, 66 segments of Vacated Streets and 78 segments of Steps. Street Centerlines that are coded as Paper Streets in the OWNER field will remain unchanged in the updated dataset unless the area has been developed. In the event the area has been developed, the Street Centerlines will be modified to reflect the true condition of the visible roads. Street Centerlines that are coded as Vacated in the OWNER field will also remain unchanged in the updated dataset. In the event the area coinciding with the Vacated Streets has been developed, the Vacated Street Centerlines will be removed in order to reflect the true condition of the area. Street Centerlines that are coded as Steps in the OWNER field will be updated to reflect the current condition of the area. The Street Centerlines dataset consists of an external table that links to the supplied coverages and the Geodatabase created for this project using the "-ID" (UserID) field. In order to maintain the link to the external table and not loose valuable data the decision was made to keep all database information currently in the Street Centerline dataset. When a Street Centerline is modified during the update process, the field "UPDATE_YEAR" is set to 2004. All other database attributes will remain unchanged from the original values. All Street Centerline database data with an "UPDATE_YEAR" of 2004 should be verified before used. In some occasions the Street Centerline was divided into two (2) sections to allow for a new road intersection. Both sections of the resulting Street Centerline will have the same database attributes including Address Range. All new Street Centerlines will have zero (0) for "SystemID" and "UserID". This dataset was previously harvested from Allegheny County’s GIS data portal. The new authoritative source for this data is now the PASDA page (https://www.pasda.psu.edu/uci/DataSummary.aspx?dataset=1224), which includes links to historical versions of the shapefile representations of this data.

Parcels with tax assessor data for SSMMA region. See Code Definitions for Cook County parcel classification details.CAVEAT EMPTOR: Cook County data from 2016, Will County data from 2017.We are currently in the process of collecting Cook County data and processing Will County data for 2019.For up-to-date parcel tax records, visit the Cook County GIS Viewer or Will County GIS Viewer, or access the Cook County Tax Assessor's databases [1] [2] or the Will County Tax Assessor's Office.Municipalities in SSMMA's GIS Consortium may contact the GIS staff if more recent data is available to display on municipal viewers.

Municipalities around Cook County have opened cooling centers for area residents as temperatures start to rise. Residents who need to seek shelter should contact the center first to verify it is open. This dataset will be no longer updated on May 1, 2019. Please refer to this link for future updates: https://datacatalog.cookcountyil.gov/dataset/Cook-County-Cooling-Centers-Map/dnn9-esge

DWR subdivided California into study areas for planning purposes. The largest study areas are the ten hydrologic regions (HR), corresponding to the State’s major drainage basins. The next levels of delineation are the Planning Areas (PA), which in turn are composed of multiple detailed analysis units (DAU). The DAUs are often split by county boundaries, so are the smallest study areas used by DWR. The DAU/counties are used for estimating water demand by agricultural crops and other surfaces for water resources planning. Under current guidelines, each DAU/County has multiple crop and land-use categories. Many planning studies begin at the DAU or PA level, and the results are aggregated into hydrologic regions for presentation. This is considered a legacy dataset and will no longer be updated. After decades of use, Detailed Analysis Units are being retired as the framework dataset for the California Water Plan. Future updates of the California Water Plan will use the 8-digit Hydrologic Units of the U.S. Geological Survey’s Watershed Boundary Dataset as the planning and analysis framework. For more information on the Watershed Boundary Dataset, please visit https://data.cnra.ca.gov/dataset/watershed-boundary-dataset-wbd or contact nhd_stewardship@water.ca.gov. Questions about the California Water Plan may be directed to cwpcom@water.ca.gov.

This dataset is a compilation of tax parcel polygon and point layers from the seven Twin Cities, Minnesota metropolitan area counties of Anoka, Carver, Dakota, Hennepin, Ramsey, Scott and Washington. The seven counties were assembled into a common coordinate system. No attempt has been made to edgematch or rubbersheet between counties. A standard set of attribute fields is included for each county. (See section 5 of the metadata). The attributes are the same for the polygon and points layers. Not all attributes are populated for all counties.

The polygon layer contains one record for each real estate/tax parcel polygon within each county's parcel dataset. Some counties will polygons for each individual condominium, and others do not. (See Completeness in Section 2 of the metadata for more information.) The points layer includes the same attribute fields as the polygon dataset. The points are intended to provide information in situations where multiple tax parcels are represented by a single polygon. The primary example of this is the condominium. Condominiums, by definition, are legally owned as individual, taxed real estate units. Records for condominiums may not show up in the polygon dataset. The points for the point dataset often will be randomly placed or stacked within the parcel polygon with which they are associated.

The polygon layer is broken into individual county shape files. The points layer is one file for the entire metro area.

In many places a one-to-one relationship does not exist between these parcel polygons or points and the actual buildings or occupancy units that lie within them. There may be many buildings on one parcel and there may be many occupancy units (e.g. apartments, stores or offices) within each building. Additionally, no information exists within this dataset about residents of parcels. Parcel owner and taxpayer information exists for many, but not all counties.

Polygon and point counts for each county are as follows (based on the January 2010 dataset unless otherwise noted):

polygons / points
Anoka - 129271 / 129271
Carver - 38205 / 38205
Dakota - 136067 / 150436
Hennepin - 424182 / 424182
Ramsey - 149101 / 168152
Scott - 55213 / 55213
Washington - 98933 / 104100 (October 2009)

This is a MetroGIS Regionally Endorsed dataset.

Each of the seven Metro Area counties has entered into a multiparty agreement with the Metropolitan Council to assemble and distribute the parcel data for each county as a regional (seven county) parcel dataset.

A standard set of attribute fields is included for each county. The attributes are identical for the point and polygon datasets. Not all attributes fields are populated by each county. Detailed information about the attributes can be found in the MetroGIS Regional Parcels Attributes 2009 document.

Additional information may be available in the individual metadata for each county at the links listed below. Also, any questions or comments about suspected errors or omissions in this dataset can be addressed to the contact person listed in the individual county metadata.

Anoka = http://www.anokacounty.us/315/GIS

Caver = http://www.co.carver.mn.us/GIS

Dakota = http://www.co.dakota.mn.us/homeproperty/propertymaps/pages/default.aspx

Hennepin: http://www.hennepin.us/gisopendata

Ramsey = https://www.ramseycounty.us/your-government/open-government/research-data

Scott = http://www.scottcountymn.gov/1183/GIS-Data-and-Maps

Washington = http://www.co.washington.mn.us/index.aspx?NID=1606

A complete, historic universe of Cook County parcels with attached geographic, governmental, and spatial data.

When working with Parcel Index Numbers (PINs) make sure to zero-pad them to 14 digits. Some datasets may lose leading zeros for PINs when downloaded.

Additional notes:

• Non-taxing district data is attached via spatial join (st_contains) to each parcel's centroid.
• Tax district data (school district, park district, municipality, etc.) are attached by a parcel's assigned tax code.
• Centroids are based on Cook County parcel shapefiles.
• Older properties may be missing coordinates and thus also missing attached spatial data (usually they are missing a parcel boundary in the shapefile).
• Newer properties may be missing a mailing or property address, as they need to be assigned one by the postal service.
• This dataset contains data for the current tax year, which may not yet be complete or final. Assessed values for any given year are subject to change until review and certification of values by the Cook County Board of Review, though there are a few rare circumstances where values may change for the current or past years after that.
• Rowcount for a given year is final once the Assessor has certified the assessment roll all townships.
• Data will be updated monthly.
• Depending on the time of year, some third-party and internal data will be missing for the most recent year. Assessments mailed this year represent values from last year, so this isn't an issue. By the time the Data Department models values for this year, those data will have populated.
• Current property class codes, their levels of assessment, and descriptions can be found on the Assessor's website. Note that class codes details can change across time.
• Due to discrepancies between the systems used by the Assessor and Clerk's offices, tax_district_code is not currently up-to-date in this table.

Read about the Assessor's 2025 Open Data Refresh.

The 2002 Sierra County land use survey data set was developed by DWR through its Division of Planning and Local Assistance (DPLA). The data was gathered using aerial photography and extensive field visits, the land use boundaries and attributes were digitized, and the resultant data went through standard quality control procedures before finalizing. The land uses that were gathered were detailed agricultural land uses, and lesser detailed urban and native vegetation land uses. The data was gathered and digitized by staff of DWR’s Central District. Quality control procedures were performed jointly by staff at DWR’s DPLA headquarters and Central District. Important Points about Using this Data Set: 1. The land use boundaries were hand drawn directly on USGS quad maps and then digitized. They were drawn to depict observable areas of the same land use. They were not drawn to represent legal parcel (ownership) boundaries, or meant to be used as parcel boundaries. 2. This survey was a "snapshot" in time. The indicated land use attributes of each delineated area (polygon) were based upon what the surveyor saw in the field at that time, and, to an extent possible, whatever additional information the aerial photography might provide. For example, the surveyor might have seen a cropped field in the photograph, and the field visit showed a field of corn, so the field was given a corn attribute. In another field, the photograph might have shown a crop that was golden in color (indicating grain prior to harvest), and the field visit showed newly planted corn. This field would be given an attribute showing a double crop, grain followed by corn. The DWR land use attribute structure allows for up to three crops per delineated area (polygon). In the cases where there were crops grown before the survey took place, the surveyor may or may not have been able to detect them from the field or the photographs. For crops planted after the survey date, the surveyor could not account for these crops. Thus, although the data is very accurate for that point in time, it may not be an accurate determination of what was grown in the fields for the whole year. If the area being surveyed does have double or multicropping systems, it is likely that there are more crops grown than could be surveyed with a "snapshot". 3. If the data is to be brought into a GIS for analysis of cropped (or planted) acreage, two things must be understood: a. The acreage of each field delineated is the gross area of the field. The amount of actual planted and irrigated acreage will always be less than the gross acreage, because of ditches, farm roads, other roads, farmsteads, etc. Thus, a delineated corn field may have a GIS calculated acreage of 40 acres but will have a smaller cropped (or net) acreage, maybe 38 acres. b. Double and multicropping must be taken into account. A delineated field of 40 acres might have been cropped first with grain, then with corn, and coded as such. To estimate actual cropped acres, the two crops are added together (38 acres of grain and 38 acres of corn) which results in a total of 76 acres of net crop (or planted) acres. 4. Not all land use codes will be represented in the survey.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.3, dated April 13, 2022. 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. See the CADWR Land User Viewer (gis.water.ca.gov/app/CADWRLandUseViewer) for the most current contact information. Comments, problems, improvements, updates, or suggestions should be forwarded to gis@water.ca.gov.

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/ It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

Land cover describes the surface of the earth. Land-cover maps are useful in urban planning, resource management, change detection, agriculture, and a variety of other applications in which information related to the earth's surface is required. Land-cover classification is a complex exercise and is difficult to capture using traditional means. Deep learning models are highly capable of learning these complex semantics and can produce superior results.There are a few public datasets for land cover, but the spatial and temporal coverage of these public datasets may not always meet the user’s requirements. It is also difficult to create datasets for a specific time, as it requires expertise and time. Use this deep learning model to automate the manual process and reduce the required time and effort significantly.Using the modelFollow the guide to use the model. Before using this model, ensure that the supported deep learning libraries are installed. For more details, check Deep Learning Libraries Installer for ArcGIS.Fine-tuning the modelThis model can be fine-tuned using the Train Deep Learning Model tool. Follow the guide to fine-tune this model.Input8-bit, 3-band very high-resolution (10 cm) imagery.OutputClassified raster with the 8 classes as in the LA county landcover dataset.Applicable geographiesThe model is expected to work well in the United States and will produce the best results in the urban areas of California.Model architectureThis model uses the UNet model architecture implemented in ArcGIS API for Python.Accuracy metricsThis model has an overall accuracy of 84.8%. The table below summarizes the precision, recall and F1-score of the model on the validation dataset: ClassPrecisionRecallF1 ScoreTree Canopy0.8043890.8461520.824742Grass/Shrubs0.7199930.6272780.670445Bare Soil0.89270.9099580.901246Water0.9808850.9874990.984181Buildings0.9222020.9450320.933478Roads/Railroads0.8696370.8629210.866266Other Paved0.8114650.8119610.811713Tall Shrubs0.7076740.6382740.671185Training dataThis model has been trained on very high-resolution Landcover dataset (produced by LA County).LimitationsSince the model is trained on imagery of urban areas of LA County it will work best in urban areas of California or similar geography.Model is trained on limited classes and may lead to misclassification for other types of LULC classes.Sample resultsHere are a few results from the model.

This data set was generated through the 2020 LU/LC update mapping effort. The 2020 update is the seventh in a series of land use mapping efforts that was begun in 1986. Revisions and additions to the initial baseline layer were done in subsequent years from imagery captured in 1995/97, 2002, 2007, 2012, 2015 and now, 2020. This present 2020 update was created by comparing the 2015 LU/LC layer from NJDEP's Geographic Information Systems (GIS) database to 2020 color infrared (CIR) imagery and delineating and coding areas of change. Work for this data set was done by Aerial Information Systems, Inc., Redlands, CA, under direction of the New Jersey Department of Environmental Protection (NJDEP), Bureau of Geographic Information System (BGIS). LU/LC changes were captured by adding new line work and attribute data for the 2020 land use directly to the base data layer. All 2015 LU/LC polygons and 2015 LU/LC coding remains in this data set, so change analysis for the period 2015-2020 can be undertaken from this one layer. The mapping was done by USGS HUC8 basins, 13 of which cover portions of New Jersey. This statewide layer is composed of the final data sets generated for each HUC8 basin. Initial QA/QC was done on each HUC8 data set as it was produced with final QA/QC and basin-to-basin edgematching done on this statewide layer. The classification system used was a modified Anderson et al., classification system. Minimum mapping unit (MMU) is 1 acre for changes to non-water and non-wetland polygons. Changes to these two categories were mapped using .25 acres as the MMU. (See entry under the Advisory section concerning additional review being done on NHD waterbody attribute coding and impervious surface estimation.) ADVISORY This data set, edition 20231120, is a statewide layer that includes updated land use/land cover data for all HUC8 basins in New Jersey. The polygon delineations and associated land use code assignments are considered the final versions for this mapping effort. Note, however, that there is continuing review being done on this layer to update several additional attributes not presently evaluated in this edition. These attributes include several from the National Hydrography Database (NHD) that are specific to the waterbodies mapped in this layer, and several attributes containing impervious surface estimates for each polygon. Evaluating the NHD codes facilitates extracting the water features mapped in this layer and using them to update the New Jersey portion of the NHD. Those NHD specific attributes are still being evaluated and may be added to a future edition of this base data set. Similarly, additional review is being done to assess the feasibility of incorporating data on impervious surface (IS) amounts generated from two independent projects, one of which was just completed by NOAA, into this base land use layer. While the NHD and IS attributes will enhance the use of this base layer in several types of analyses, this present layer can be used for doing all primary land use analyses without having those attributes evaluated. Further, evaluating these extra attributes will result in few, if any, changes to the polygon delineations and standard land use coding that are the primary features of this layer. As such, the layer is being provided in its present edition for general use. As the additional attributes are evaluated, they may be added to a future edition of this data set. The basic land use features and codes, however, as mapped in this version of the data set will serve as the base 2020 LU/LC update. As stated in this metadata record's Use Constraints section, NJDEP makes no representations of any kind, including, but not limited to, the warranties of merchantability or fitness for a particular use, nor are any such warranties to be implied with respect to the digital data layers furnished hereunder. NJDEP assumes no responsibility to maintain them in any manner or form. By downloading this data, user agrees to the data use constraints listed within this metadata record.The data for Somerset County data was extracted & processed from the latest dataset by the Somerset County Office of GIS Services (SCOGIS).

This service is publicly available GIS data representing Voting Precincts, as recorded by DETCOG in partnership with the relevant member local governments. The data available here covers Angelina County and is a subset of the regional GIS database. DETCOG, in conjunction with its member governments, seeks to provide accurate and accessible GIS data and services to support public safety efforts throughout the region and support other regional needs and efforts.Some notes regarding the available datasets:While layers may be present for various precinct boundaries, these will only contain data where it has been provided by the relevant county office, otherwise the layers will be empty. It should also be noted that the precinct boundaries presented here are to be used as approximate geographic representations only. The relevant local government office should always be contacted directly regarding any specific questions or for any final determinations as to what precinct a particular location is in.Any other questions regarding the data may be directed to the DETCOG regional GIS staff or the relevant county GIS coordinator using the contact information available at https://www.detcog.gov/911

The establishment of a BES Multi-User Geodatabase (BES-MUG) allows for the storage, management, and distribution of geospatial data associated with the Baltimore Ecosystem Study. At present, BES data is distributed over the internet via the BES website. While having geospatial data available for download is a vast improvement over having the data housed at individual research institutions, it still suffers from some limitations. BES-MUG overcomes these limitations; improving the quality of the geospatial data available to BES researches, thereby leading to more informed decision-making. BES-MUG builds on Environmental Systems Research Institute's (ESRI) ArcGIS and ArcSDE technology. ESRI was selected because its geospatial software offers robust capabilities. ArcGIS is implemented agency-wide within the USDA and is the predominant geospatial software package used by collaborating institutions. Commercially available enterprise database packages (DB2, Oracle, SQL) provide an efficient means to store, manage, and share large datasets. However, standard database capabilities are limited with respect to geographic datasets because they lack the ability to deal with complex spatial relationships. By using ESRI's ArcSDE (Spatial Database Engine) in conjunction with database software, geospatial data can be handled much more effectively through the implementation of the Geodatabase model. Through ArcSDE and the Geodatabase model the database's capabilities are expanded, allowing for multiuser editing, intelligent feature types, and the establishment of rules and relationships. ArcSDE also allows users to connect to the database using ArcGIS software without being burdened by the intricacies of the database itself. For an example of how BES-MUG will help improve the quality and timeless of BES geospatial data consider a census block group layer that is in need of updating. Rather than the researcher downloading the dataset, editing it, and resubmitting to through ORS, access rules will allow the authorized user to edit the dataset over the network. Established rules will ensure that the attribute and topological integrity is maintained, so that key fields are not left blank and that the block group boundaries stay within tract boundaries. Metadata will automatically be updated showing who edited the dataset and when they did in the event any questions arise. Currently, a functioning prototype Multi-User Database has been developed for BES at the University of Vermont Spatial Analysis Lab, using Arc SDE and IBM's DB2 Enterprise Database as a back end architecture. This database, which is currently only accessible to those on the UVM campus network, will shortly be migrated to a Linux server where it will be accessible for database connections over the Internet. Passwords can then be handed out to all interested researchers on the project, who will be able to make a database connection through the Geographic Information Systems software interface on their desktop computer. This database will include a very large number of thematic layers. Those layers are currently divided into biophysical, socio-economic and imagery categories. Biophysical includes data on topography, soils, forest cover, habitat areas, hydrology and toxics. Socio-economics includes political and administrative boundaries, transportation and infrastructure networks, property data, census data, household survey data, parks, protected areas, land use/land cover, zoning, public health and historic land use change. Imagery includes a variety of aerial and satellite imagery. See the readme: http://96.56.36.108/geodatabase_SAL/readme.txt See the file listing: http://96.56.36.108/geodatabase_SAL/diroutput.txt

WARNING: This is a pre-release dataset and its fields names and data structures are subject to change. It should be considered pre-release until the end of March 2025. The schema changed in February 2025 - please see below. We will post a roadmap of upcoming changes, but service URLs and schema are now stable. For deployment status of new services in February 2025, see https://gis.data.ca.gov/pages/city-and-county-boundary-data-status. Additional roadmap and status links at the bottom of this metadata.

Purpose

County boundaries along with third party identifiers used to join in external data. Boundaries are from the California Department of Tax and Fee Administration (CDTFA). These boundaries are the best available statewide data source in that CDTFA receives changes in incorporation and boundary lines from the Board of Equalization, who receives them from local jurisdictions for tax purposes. Boundary accuracy is not guaranteed, and though CDTFA works to align boundaries based on historical records and local changes, errors will exist. If you require a legal assessment of boundary location, contact a licensed surveyor.

This dataset joins in multiple attributes and identifiers from the US Census Bureau and Board on Geographic Names to facilitate adding additional third party data sources. In addition, we attach attributes of our own to ease and reduce common processing needs and questions. Finally, coastal buffers are separated into separate polygons, leaving the land-based portions of jurisdictions and coastal buffers in adjacent polygons. This layer removes the coastal buffer polygons. This feature layer is for public use.

Related Layers

This dataset is part of a grouping of many datasets:

1. Cities: Only the city boundaries and attributes, without any unincorporated areas
   • With Coastal Buffers
   • Without Coastal Buffers
2. Counties: Full county boundaries and attributes, including all cities within as a single polygon
   • With Coastal Buffers
   • Without Coastal Buffers (this dataset)
3. Cities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.
   • With Coastal Buffers
   • Without Coastal Buffers
4. City and County Abbreviations
5. Unincorporated Areas (Coming Soon)
6. Census Designated Places
7. Cartographic Coastline
   • Polygon
   • Line source (Coming Soon)

Point of Contact

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

Field and Abbreviation Definitions

• CDTFA_COUNTY: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.
• CDTFA_COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system. The boundary data originate with CDTFA's teams managing tax rate information, so this field is preserved and flows into this dataset.
• CENSUS_GEOID: numeric geographic identifiers from the US Census Bureau
• CENSUS_PLACE_TYPE: City, County, or Town, stripped off the census name for identification purpose.
• GNIS_PLACE_NAME: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information System
• GNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.
• CDT_COUNTY_ABBR: Abbreviations of county names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 3 characters.
• CDT_NAME_SHORT: The name of the jurisdiction (city or county) with the word "City" or "County" stripped off the end. Some changes may come to how we process this value to make it more consistent.
• AREA_SQMI: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.
• OFFSHORE: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".
• PRIMARY_DOMAIN: Currently empty/null for all records. Placeholder field for official URL of the city or county
• CENSUS_POPULATION: Currently null for all records. In the future, it will include the most recent US Census population estimate for the jurisdiction.
• GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.