This dataset is a compilation of address point data for the City of Tempe. The dataset contains a point location, the official address (as defined by The Building Safety Division of Community Development) for all occupiable units and any other official addresses in the City. There are several additional attributes that may be populated for an address, but they may not be populated for every address. Contact: Lynn Flaaen-Hanna, Development Services Specialist Contact E-mail Link: Map that Lets You Explore and Export Address Data Data Source: The initial dataset was created by combining several datasets and then reviewing the information to remove duplicates and identify errors. This published dataset is the system of record for Tempe addresses going forward, with the address information being created and maintained by The Building Safety Division of Community Development.Data Source Type: ESRI ArcGIS Enterprise GeodatabasePreparation Method: N/APublish Frequency: WeeklyPublish Method: AutomaticData Dictionary

DESCRIPTION OF ORIGINAL PARCELS DATASET HOSTED BY NJ OGIS: The statewide composite of parcels (cadastral) data for New Jersey is made available here in Web Mercator projection (3857.) It was developed during the Parcels Normalization Project in 2008-2014 by the NJ Office of Information Technology, Office of GIS (NJOGIS). The normalized parcels data are compatible with the New Jersey Department of Treasury MOD-IV system currently used by Tax Assessors and selected attributes from that system have been joined with the parcels in this dataset. Please see the NJGIN parcel dataset page for additional resources, including a downloadable zip file of the statewide data: https://njgin.nj.gov/njgin/edata/parcels/index.html#!/This composite of parcels data serves as one of New Jersey's framework GIS data sets. Stewardship and maintenance of the data will continue to be the purview of county and municipal governments, but the statewide composite will be maintained by NJOGIS.Parcel attributes were normalized to a standard structure, specified in the NJ GIS Parcel Mapping Standard, to store parcel information and provide a PIN (parcel identification number) field that can be used to match records with suitably-processed property tax data. The standard is available for viewing and download at https://njgin.state.nj.us/oit/gis/NJ_NJGINExplorer/docs/NJGIS_ParcelMappingStandardv3.2.pdf. The PIN also can be constructed from attributes available in the MOD-IV Tax List Search table (see below).This dataset includes a large number of additional attributes from matched MOD-IV records; however, not all MOD-IV records match to a parcel, for reasons explained elsewhere in this metadata record. The statewide property tax table, including all MOD-IV records, is available as a separate download "MOD-IV Tax List Search Plus Database of New Jersey." Users who need only the parcel boundaries with limited attributes may obtain those from a separate download "Parcels Composite of New Jersey ". Also available separately are countywide parcels and tables of property ownership and tax information extracted from the NJ Division of Taxation database.The polygons delineated in this dataset do not represent legal boundaries and should not be used to provide a legal determination of land ownership. Parcels are not survey data and should not be used as such. Please note that these parcel datasets are not intended for use as tax maps. They are intended to provide reasonable representations of parcel boundaries for planning and other purposes. Please see Data Quality / Process Steps for details about updates to this composite since its first publication.

Complete accounting of all incorporated cities, including the boundary and name of each individual city. From 2009 to 2022 CAL FIRE maintained this dataset by processing and digitally capturing annexations sent by the state Board of Equalization (BOE). In 2022 CAL FIRE began sourcing data directly from BOE, in order to allow the authoritative department provide data directly. This data is then adjusted so it resembles the previous formats.Processing includes:• Clipping the dataset to traditional state boundaries• Erasing areas that span the Bay Area (derived from calw221.gdb)• Querying for incorporated areas only• Dissolving each incorporated polygon into a single feature• Calculating the COUNTY field to remove the word 'County'Version 24_1 is based on BOE_CityCounty_20240315, and includes all annexations present in BOE_CityAnx2023_20240315. Note: The Board of Equalization represents incorporated city boundaries as extending significantly into waterways, including beyond coastal boundaries. To see the representation in its original form please reference the datasets listed above.Note: The Board of Equalization represents incorporated city boundaries is extending significantly into waterways, including beyond coastal boundaries. To see the representation in its original form please reference the datasets listed above.

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

AT_2004_HOWA

   File Geodatabase Feature Class


   Thumbnail Not Available

   Tags

   Socio-economic resources, Information, Social Institutions, Hierarchy, Territory, BES, Parcel, Property, Property View, A&T, Database, Assessors, Taxation




   Summary


   Serves as a basis for performing various analyses based on parcel data.


   Description


   Assessments & Taxation (A&T) Database from MD Property View 2004 for Howard County. The A&T Database contains parcel data from the State Department of Assessments and Taxation; it incorporates parcel ownership and address information, parcel valuation information and basic information about the land and structure(s) associated with a given parcel. These data form the basis for the 2004 Database, which also includes selected Computer Assisted Mass Appraisal (CAMA) characteristics, text descriptions to make parcel code field data more readily accessible and logical True/False fields which identify parcels with certain characteristics. Documentation for A&T, including a thorough definition for all attributes is enclosed. Complete Property View documentation can be found at http://www.mdp.state.md.us/data/index.htm under the "Technical Background" tab.


   It should be noted that the A&T Database consists of points and not parcel boundaries. For those areas where parcel polygon data exists the A&T Database can be joined using the ACCTID or a concatenation of the BLOCK and LOT fields, whichever is appropriate. (Spaces may have to be excluded when concatenating the BLOCK and LOT fields).


   A cursory review of the 2004 version of the A&T Database indicates that it has more accurate data when compared with the 2003 version, particularly with respect to dwelling types. However, for a given record it is not uncommon for numerous fields to be missing attributes. Based on previous version of the A&T Database it is also not unlikely that some of the information is inaccurate. This layer was edited to remove points that did not have a valid location because they failed to geocode. There were 1160 such points. A listing of the deleted points is in the table with the suffix "DeletedRecords."


   Credits


   Maryland Department of Planning


   Use limitations


   BES use only.


   Extent



   West -77.186932  East -76.699458 

   North 39.373967  South 39.099693 




   Scale Range

   There is no scale range for this item.

Last update: August 20, 2024OverviewThis point data was generated and filtered from OpenStreetMap and is intended to represent places of interest in the state of Utah. These may include businesses, restaurants, places of worship, airports, parks, schools, event centers, apartment complexes, hotels, car dealerships…almost anything that you can find in OpenStreetMap (OSM). There are over 23,000 features in the original dataset (March 2022) and users can directly contribute to it through openstreetmap.org. This data is updated approximately once every month and will likely continue to grow over time with user activity.Data SourcesThe original bulk set of OSM data for the state of Utah is downloaded from Geofabrik: https://download.geofabrik.de/north-america/us/utah-latest-free.shp.zipAdditional attributes for the Utah features are gathered via the Overpass API using the following query: https://overpass-turbo.eu/s/1geRData Creation ProcessThe Open Source Places layer is created by a Python script that pulls statewide OSM data from a nightly archive provided by Geofabrik (https://www.geofabrik.de/data/download.html). The archive data contains nearly 20 shapefiles, some that are relevant to this dataset and some that aren't. The Open Source Places layer is built by filtering the polygon and point data in those shapefiles down to a single point feature class with specific categories and attributes that UGRC determines would be of widest interest. The polygon features (buildings, areas, complexes, etc.) are converted to points using an internal centroid. Spatial filtering is done as the data from multiple shapefiles is combined into a single layer to minimize the occurrence of duplicate features. (For example, a restaurant can be represented in OSM as both a point of interest and as a building polygon. The spatial filtering helps reduce the chances that both of these features are present in the final dataset.) Additional de-duplication is performed by using the 'block_id' field as a spatial index, to ensure that no two features of the same name exist within a census block. Then, additional fields are created and assigned from UGRC's SGID data (county, city, zip, nearby address, etc.) via point-in-polygon and near analyses. A numeric check is done on the 'name' field to remove features where the name is less than 3 characters long or more than 50% numeric characters. This eliminates several features derived from the buildings layer where the 'name' is simply an apartment complex building number (ex: 3A) or house number (ex: 1612). Finally, additional attributes (osm_addr, opening_hours, phone, website, cuisine, etc.) are pulled from the Overpass API (https://wiki.openstreetmap.org/wiki/Overpass_API) and joined to the filtered data using the 'osm_id' field as the join key.Field Descriptionsaddr_dist - the distance (m) to the nearest UGRC address point within 25 mosm_id - the feature ID in the OSM databasecategory - the feature's data class based on the 4-digit code and tags in the OSM databasename - the name of the feature in the OSM databasecounty - the county the feature is located in (assigned from UGRC's county boundaries)city - the city the feature is located in (assigned from UGRC's municipal boundaries)zip - the zip code of the feature (assigned from UGRC's approximation of zip code boundaries)block_id - the census block the feature is located in (assigned from UGRC's census block boundaries)ugrc_addr - the nearest address (within 25 m) from the UGRC address point databasedisclaimer - a note from UGRC about the ugrc_near_addr fieldlon - the approximate longitude of the feature, calculated in WGS84 EPSG:4326lat - the approximate latitude of the feature, calculated in WGS84 EPSG:4326amenity - the amenity available at the feature (if applicable), often similar to the categorycuisine - the type of food available (if applicable), multiple types are separated by semicolons (;)tourism - the type of tourist location, if applicable (zoo, viewpoint, hotel, attraction, etc.)shop - the type of shop, if applicablewebsite - the feature's website in the OSM database, if availablephone - the feature's phone number(s) in the OSM database, if availableopen_hours - the feature's operating hours in the OSM database, if availableosm_addr - the feature's address in the OSM database, if availableMore information can be found on the UGRC data page for this layer:https://gis.utah.gov/data/society/open-source-places/

These data include the individual responses for the City of Tempe Annual Business Survey conducted by ETC Institute. These data help determine priorities for the community as part of the City's on-going strategic planning process. Averaged Business Survey results are used as indicators for city performance measures. The performance measures with indicators from the Business Survey include the following (as of 2023):1. Financial Stability and Vitality5.01 Quality of Business ServicesThe location data in this dataset is generalized to the block level to protect privacy. This means that only the first two digits of an address are used to map the location. When they data are shared with the city only the latitude/longitude of the block level address points are provided. This results in points that overlap. In order to better visualize the data, overlapping points were randomly dispersed to remove overlap. The result of these two adjustments ensure that they are not related to a specific address, but are still close enough to allow insights about service delivery in different areas of the city.Additional InformationSource: Business SurveyContact (author): Adam SamuelsContact E-Mail (author): Adam_Samuels@tempe.govContact (maintainer): Contact E-Mail (maintainer): Data Source Type: Excel tablePreparation Method: Data received from vendor after report is completedPublish Frequency: AnnualPublish Method: ManualData DictionaryMethods:The survey is mailed to a random sample of businesses in the City of Tempe. Follow up emails and texts are also sent to encourage participation. A link to the survey is provided with each communication. To prevent people who do not live in Tempe or who were not selected as part of the random sample from completing the survey, everyone who completed the survey was required to provide their address. These addresses were then matched to those used for the random representative sample. If the respondent’s address did not match, the response was not used.To better understand how services are being delivered across the city, individual results were mapped to determine overall distribution across the city.Processing and Limitations:The location data in this dataset is generalized to the block level to protect privacy. This means that only the first two digits of an address are used to map the location. When they data are shared with the city only the latitude/longitude of the block level address points are provided. This results in points that overlap. In order to better visualize the data, overlapping points were randomly dispersed to remove overlap. The result of these two adjustments ensure that they are not related to a specific address, but are still close enough to allow insights about service delivery in different areas of the city.The data are used by the ETC Institute in the final published PDF report.

The project lead for the collection of this data was Carrington Hilson. Elk (2 adult females) were captured and equipped with GPS collars (Lotek Iridium) transmitting data from 2019-2021. The Sinyone herd does not migrate between traditional summer and winter seasonal ranges. Therefore, annual home ranges were modeled using year-round data to demarcate high use areas in lieu of modeling the specific winter ranges commonly seen in other ungulate analyses in California. GPS locations were fixed between 1-6 hour intervals in the dataset. To improve the quality of the data set as per Bjørneraas et al. (2010), the GPS data were filtered prior to analysis to remove locations which were: i) further from either the previous point or subsequent point than an individual pronghorn is able to travel in the elapsed time, ii) forming spikes in the movement trajectory based on outgoing and incoming speeds and turning angles sharper than a predefined threshold , or iii) fixed in 2D space and visually assessed as a bad fix by the analyst. The methodology used for this migration analysis allowed for the mapping of the herd''s home range. Brownian bridge movement models (BBMMs; Sawyer et al. 2009) were constructed with GPS collar data from 2 elk, including 3 annual home range sequences, location, date, time, and average location error as inputs in Migration Mapper. BBMMs were produced at a spatial resolution of 50 m using a sequential fix interval of less than 27 hours. Large water bodies were clipped from the final output. Home range is visualized as the 50thpercentile contour (high use) and the 99thpercentile contour of the year-round utilization distribution. Home range designations for this herd may expand with a larger sample.

Use the app to find the downloadable area within Jackson County - 2 Foot Contour MapThe 2-foot Contour Map shows contours that were derived from several different LiDAR projects in the Rogue Valley over the last 10 years. The map can be used to both download and view the contour data. To use the map, search or zoom in to an address. When zoomed in to a specific scale, the map will change from the downloadable areas layer to 2-foot interval contour lines. The LiDAR Project Dates layer can be used to identify the date when the elevation was collected in an area. Please note that data is available only for the valley floor areas at this time.The 2ft contours were created from 1-meter pixel DEM and then cleaned to remove very small elevation changes and to create a smooth contour line. This information should not be used to create topographic surveys or other applications where the precise elevation of a location is required. For additional information on LiDAR in Oregon or to download the source data, please visit the DOGAMI Lidar Viewer.The downloadable data is a zipped ESRI Shapefile and is projected to Oregon State Plane South (Intl Feet) with NAD 1983 datum.

Mapping the infestation of Sesbania punicea along the middle Sacramento River was the first step of a project to remove rattlebox in the Sacramento River ecosystem. This project is funded by a State Wildlife Grant, administered by the US Fish and Wildlife Service.

AT_2004_BACO File Geodatabase Feature Class Thumbnail Not Available Tags Socio-economic resources, Information, Social Institutions, Hierarchy, Territory, BES, Parcel, Property, Property View, A&T, Database, Assessors, Taxation Summary Serves as a basis for performing various analyses based on parcel data. Description Assessments & Taxation (A&T) Database from MD Property View 2004 for Baltimore County. The A&T Database contains parcel data from the State Department of Assessments and Taxation; it incorporates parcel ownership and address information, parcel valuation information and basic information about the land and structure(s) associated with a given parcel. These data form the basis for the 2004 Database, which also includes selected Computer Assisted Mass Appraisal (CAMA) characteristics, text descriptions to make parcel code field data more readily accessible and logical True/False fields which identify parcels with certain characteristics. Documentation for A&T, including a thorough definition for all attributes is enclosed. Complete Property View documentation can be found at http://www.mdp.state.md.us/data/index.htm under the "Technical Background" tab. It should be noted that the A&T Database consists of points and not parcel boundaries. For those areas where parcel polygon data exists the A&T Database can be joined using the ACCTID or a concatenation of the BLOCK and LOT fields, whichever is appropriate. (Spaces may have to be excluded when concatenating the BLOCK and LOT fields). A cursory review of the 2004 version of the A&T Database indicates that it has more accurate data when compared with the 2003 version, particularly with respect to dwelling types. However, for a given record it is not uncommon for numerous fields to be missing attributes. Based on previous version of the A&T Database it is also not unlikely that some of the information is inaccurate. This layer was edited to remove points that did not have a valid location because they failed to geocode. There were 5870 such points. A listing of the deleted points is in the table with the suffix "DeletedRecords." Credits Maryland Department of Planning Use limitations BES use only. Extent West -76.897802 East -76.335214 North 39.726520 South 39.192552 Scale Range There is no scale range for this item.

Update NotesMar 16 2024, remove spaces in the file and folder names.Mar 31 2024, delete the underscore in the city names with a space (such as San Francisco) in the '02_TransCAD_results' folder to ensure correct data loading by TransCAD (software version: 9.0).Aug 31 2024, add the 'cityname_link_LinkFlows.csv' file in the '02_TransCAD_results' folder to match the link from input data and the link from TransCAD results (LinkFlows) with the same Link_ID.IntroductionThis is a unified and validated traffic dataset for 20 US cities. There are 3 folders for each city.01 Input datathe initial network data obtained from OpenStreetMap (OSM)the visualization of the OSM dataprocessed node / link / od data02 TransCAD results (software version: 9.0)cityname.dbd : geographical network database of the city supported by TransCAD (version 9.0)cityname_link.shp / cityname_node.shp : network data supported by GIS software, which can be imported into TransCAD manually. Then the corresponding '.dbd' file can be generated for TransCAD with a version lower than 9.0od.mtx : OD matrix supported by TransCADLinkFlows.bin / LinkFlows.csv : traffic assignment results by TransCADcityname_link_LinkFlows.csv: the input link attributes with the traffic assignment results by TransCADShortestPath.mtx / ue_travel_time.csv : the traval time (min) between OD pairs by TransCAD03 AequilibraE results (software version: 0.9.3)cityname.shp : shapefile network data of the city support by QGIS or other GIS softwareod_demand.aem : OD matrix supported by AequilibraEnetwork.csv : the network file used for traffic assignment in AequilibraEassignment_result.csv : traffic assignment results by AequilibraEPublicationXu, X., Zheng, Z., Hu, Z. et al. (2024). A unified dataset for the city-scale traffic assignment model in 20 U.S. cities. Sci Data 11, 325. https://doi.org/10.1038/s41597-024-03149-8Usage NotesIf you use this dataset in your research or any other work, please cite both the dataset and paper above.A brief introduction about how to use this dataset can be found in GitHub. More detailed illustration for compiling the traffic dataset on AequilibraE can be referred to GitHub code or Colab code.ContactIf you have any inquiries, please contact Xiaotong Xu (email: kid-a.xu@connect.polyu.hk).

A. SUMMARY This dataset contains San Francisco Board of Supervisor district boundaries approved by the San Francisco Redistricting Task Force in April 2022 following redistricting based on the 2020 Decennial Census.

B. HOW THE DATASET IS CREATED The dataset was created from the final map submitted by the San Francisco Redistricting Task Force. Boundaries in this map were decided using data from the 2020 Census on the number of people living in each census block in the City and County. This data includes the number of individuals incarcerated in facilities under the control of the Department of Corrections and Rehabilitation based on their last known residential address. This information is made available by the Statewide Database based on U.S. Census Bureau Census Redistricting Data (P.L. 94-171).

These map boundaries were trimmed to align with the city and county's physical boundaries for greater usability. This trimming mainly consisted of excluding the water around the City and County from the boundaries.

C. UPDATE PROCESS Supervisor District boundaries are updated every 10 years following the federal decennial census. The Supervisor District boundaries reflected in this dataset will remain unchanged. A new dataset will be created after the next decennial census and redistricting process are completed.

The dataset is manually updated as new members of the Board of Supervisors take office. The most recent manual update date is reflected in the 'data_as_of' field.

Once the redistricting process is completed after the next decennial census and a new dataset is published, this dataset will become static and will no longer be updated.

D. HOW TO USE THIS DATASET This dataset can be joined to other datasets for analysis and reporting at the Supervisor District level.

If you are building an automated reporting pipeline using Socrata API access, we recommend using this dataset if you'd like your boundaries to remain static. If you would like the boundaries to automatically update after each decennial census to reflect the most recent Supervisor District boundaries, see the Current Supervisor Districts dataset or the Current Supervisor Districts (trimmed to remove water and other non-populated City territories) dataset.

E. RELATED DATASETS Supervisor Districts (2012) Current Supervisor Districts Current Supervisor Districts (trimmed to remove water and non-populated areas)

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)

Rogue River 2ft Contours Use the app to find the downloadable area within Jackson County - 2 Foot Contour MapThe 2-foot Contour Map shows contours that were derived from several different LiDAR projects in the Rogue Valley over the last 10 years. The map can be used to both download and view the contour data. To use the map, search or zoom in to an address. When zoomed in to a specific scale, the map will change from the downloadable areas layer to 2-foot interval contour lines. The LiDAR Project Dates layer can be used to identify the date when the elevation was collected in an area. Please note that data is available only for the valley floor areas at this time.The 2ft contours were created from 1-meter pixel DEM and then cleaned to remove very small elevation changes and to create a smooth contour line. This information should not be used to create topographic surveys or other applications where the precise elevation of a location is required. For additional information on LiDAR in Oregon or to download the source data, please visit the DOGAMI Lidar Viewer.The downloadable data is a zipped ESRI Shapefile and is projected to Oregon State Plane South (Intl Feet) with NAD 1983 datum.

This page provides data for the 3rd Grade Reading Level Proficiency performance measure.The dataset includes the student performance results on the English/Language Arts section of the AzMERIT from the Fall 2017 and Spring 2018. Data is representive of students in third grade in public elementary schools in Tempe. This includes schools from both Tempe Elementary and Kyrene districts. Results are by school and provide the total number of students tested, total percentage passing and percentage of students scoring at each of the four levels of proficiency.

The performance measure dashboard is available at 3.07 3rd Grade Reading Level Proficiency.Additional InformationSource: Arizona Department of EducationContact: Ann Lynn DiDomenicoContact E-Mail: Ann_DiDomenico@tempe.govData Source Type: Excel/ CSVPreparation Method: Filters on original dataset: within "Schools" Tab School District [select Tempe School District and Kyrene School District]; School Name [deselect Kyrene SD not in Tempe city limits]; Content Area [select English Language Arts]; Test Level [select Grade 3]; Subgroup/Ethnicity [select All Students] Remove irrelevant fields; Add Fiscal YearPublish Frequency: Annually as data becomes availablePublish Method: ManualData Dictionary

The project lead for the collection of this data was Carrington Hilson. Elk (3 adult females) were captured and equipped with GPS collars (Lotek Iridium) transmitting data from 2017-2021. The Davison herd does not migrate between traditional summer and winter seasonal ranges. Therefore, annual home ranges were modeled using year-round data to demarcate high use areas in lieu of modeling the specific winter ranges commonly seen in other ungulate analyses in California. GPS locations were fixed between 1-6 hour intervals in the dataset. To improve the quality of the data set as per Bjørneraas et al. (2010), the GPS data were filtered prior to analysis to remove locations which were: i) further from either the previous point or subsequent point than an individual pronghorn is able to travel in the elapsed time, ii) forming spikes in the movement trajectory based on outgoing and incoming speeds and turning angles sharper than a predefined threshold , or iii) fixed in 2D space and visually assessed as a bad fix by the analyst. The methodology used for this migration analysis allowed for the mapping of the herd''s home range. Brownian bridge movement models (BBMMs; Sawyer et al. 2009) were constructed with GPS collar data from 3 elk, including 9 annual home range sequences, location, date, time, and average location error as inputs in Migration Mapper. BBMMs were produced at a spatial resolution of 50 m using a sequential fix interval of less than 27 hours. Large water bodies were clipped from the final output. Home range is visualized as the 50th percentile contour (high use) and the 99th percentile contour of the year-round utilization distribution. Home range designations for this herd may expand with a larger sample.

The project lead for the collection of this data was Tom Stephenson. Mule deer (130 adult females) from the Casa Diablo herd were captured and equipped with store-onboard GPS collars (Lotek Pinnacle Pro and Vectronic Survey), transmitting data from 2014-2023. Casa Diablo mule deer are largely traditional migrants, with a winter range stretching between the Benton Range and eastern Inyo National Forest. For summer, individuals move west using a wide range of pathways; however, a concentrated movement corridor passes through Long Valley, across U.S. Highway 395, and into the high mountain Sierra Nevada range. Most deer do not cross into Yosemite National Park. Summer range exists on both sides of U.S. Highway 395, which is a known hotspot for deer-vehicle collisions. Migrants vary in their movements from shorter (4 km) to longer (80 km) distances.GPS locations were fixed between 1-24 hour intervals in the dataset. To improve the quality of the data set as per Bjørneraas et al. (2010), the GPS data were filtered prior to analysis to remove locations which were: i) further from either the previous point or subsequent point than an individual deer is able to travel in the elapsed time, ii) forming spikes in the movement trajectory based on outgoing and incoming speeds and turning angles sharper than a predefined threshold , or iii) fixed in 2D space and visually assessed as a bad fix by the analyst. The methodology used for this migration analysis allowed for the mapping of winter ranges and the identification and prioritization of migration corridors. Brownian Bridge Movement Models (BBMMs; Sawyer et al. 2009) were constructed with GPS collar data from 101 migrating deer, including 445 migration sequences, location, date, time, and average location error as inputs in Migration Mapper. The dataset was divided into two overlapping subgroups based on winter range location (i.e., north, central) and analyzed separately, but visualized together as a final product. The averag

This ArcGIS Online hosted feature service displays perimeters from the National Incident Feature Service (NIFS) that meet ALL of the following criteria:

A digital raster graphic (DRG) is a scanned image of an U.S. Geological Survey (USGS) standard series topographic map, including all map collar information. The image inside the map neatline is georeferenced to the surface of the earth and fit to the Universal Transverse Mercator projection. The horizontal positional accuracy and datum of the DRG matches the accuracy and datum of the source map. The map is scanned at a minimum resolution of 250 dots per inch.

DRG's are created by scanning published paper maps on high-resolution scanners. The raster image is georeferenced and fit to the UTM projection. Colors are standardized to remove scanner limitations and artifacts. The average data set size is about 6 megabytes in Tagged Image File Format (TIFF) with PackBits compression. DRG's can be easily combined with other digital cartographic products such as digital elevation models (DEM) and digital orthophoto quadrangles (DOQ).

DRG's are stored as rectified TIFF files in geoTIFF format. GeoTIFF is a relatively new TIFF image storage format that incorporates georeferencing information in the header. This allows software, such as ArcView, ARC/INFO, or EPPL7 to reference the image without an additional header or world file.

Within the Minnesota Department of Natural Resources Core GIS data set the DRG's have been processed to be in compliance with departmental data standards (UTM Extended Zone 15, NAD83 datum) and the map collar information has been removed to facilitate the display of the DRG's in a seamless fashion.

These DRG's were clipped and transformed to UTM Zone 15 using EPPL7 Raster GIS.