In a GIS, the answer starts with a geographic coordinate system. Learn the fundamental concepts of geographic coordinate systems.Exercises can be completed with either ArcGIS Pro or ArcMap.

USGS is assessing the feasibility of map projections and grid systems for lunar surface operations. We propose developing a new Lunar Transverse Mercator (LTM), the Lunar Polar Stereographic (LPS), and the Lunar Grid Reference Systems (LGRS). We have also designed additional grids designed to NASA requirements for astronaut navigation, referred to as LGRS in Artemis Condensed Coordinates (ACC), but this is not released here. LTM, LPS, and LGRS are similar in design and use to the Universal Transverse Mercator (UTM), Universal Polar Stereographic (LPS), and Military Grid Reference System (MGRS), but adhere to NASA requirements. LGRS ACC format is similar in design and structure to historic Army Mapping Service Apollo orthotopophoto charts for navigation. The Lunar Transverse Mercator (LTM) projection system is a globalized set of lunar map projections that divides the Moon into zones to provide a uniform coordinate system for accurate spatial representation. It uses a transverse Mercator projection, which maps the Moon into 45 transverse Mercator strips, each 8°, longitude, wide. These transverse Mercator strips are subdivided at the lunar equator for a total of 90 zones. Forty-five in the northern hemisphere and forty-five in the south. LTM specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large areas with high positional accuracy while maintaining consistent scale. The Lunar Polar Stereographic (LPS) projection system contains projection specifications for the Moon’s polar regions. It uses a polar stereographic projection, which maps the polar regions onto an azimuthal plane. The LPS system contains 2 zones, each zone is located at the northern and southern poles and is referred to as the LPS northern or LPS southern zone. LPS, like is equatorial counterpart LTM, specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large polar areas with high positional accuracy, while maintaining consistent scale across the map region. LGRS is a globalized grid system for lunar navigation supported by the LTM and LPS projections. LGRS provides an alphanumeric grid coordinate structure for both the LTM and LPS systems. This labeling structure is utilized in a similar manner to MGRS. LGRS defines a global area grid based on latitude and longitude and a 25×25 km grid based on LTM and LPS coordinate values. Two implementations of LGRS are used as polar areas require a LPS projection and equatorial areas a transverse Mercator. We describe the difference in the techniques and methods report associated with this data release. Request McClernan et. al. (in-press) for more information. ACC is a method of simplifying LGRS coordinates and is similar in use to the Army Mapping Service Apollo orthotopophoto charts for navigation. These data will be released at a later date. Two versions of the shape files are provided in this data release, PCRS and Display only. See LTM_LPS_LGRS_Shapefiles.zip file. PCRS are limited to a single zone and are projected in either LTM or LPS with topocentric coordinates formatted in Eastings and Northings. Display only shapefiles are formatted in lunar planetocentric latitude and longitude, a Mercator or Equirectangular projection is best for these grids. A description of each grid is provided below: Equatorial (Display Only) Grids: Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Merged LTM zone borders Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones Merged Global Areas (8°×8° and 8°×10° extended area) for all LTM zones Merged 25km grid for all LTM zones PCRS Shapefiles:` Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones 25km Gird for North and South LPS zones Global Areas (8°×8° and 8°×10° extended area) for each LTM zone 25km grid for each LTM zone The rasters in this data release detail the linear distortions associated with the LTM and LPS system projections. For these products, we utilize the same definitions of distortion as the U.S. State Plane Coordinate System. Scale Factor, k - The scale factor is a ratio that communicates the difference in distances when measured on a map and the distance reported on the reference surface. Symbolically this is the ratio between the maps grid distance and distance on the lunar reference sphere. This value can be precisely calculated and is provided in their defining publication. See Snyder (1987) for derivation of the LPS scale factor. This scale factor is unitless and typically increases from the central scale factor k_0, a projection-defining parameter. For each LPS projection. Request McClernan et. al., (in-press) for more information. Scale Error, (k-1) - Scale-Error, is simply the scale factor differenced from 1. Is a unitless positive or negative value from 0 that is used to express the scale factor’s impact on position values on a map. Distance on the reference surface are expended when (k-1) is positive and contracted when (k-1) is negative. Height Factor, h_F - The Height Factor is used to correct for the difference in distance caused between the lunar surface curvature expressed at different elevations. It is expressed as a ratio between the radius of the lunar reference sphere and elevations measured from the center of the reference sphere. For this work, we utilized a radial distance of 1,737,400 m as recommended by the IAU working group of Rotational Elements (Archinal et. al., 2008). For this calculation, height factor values were derived from a LOLA DEM 118 m v1, Digital Elevation Model (LOLA Science Team, 2021). Combined Factor, C_F – The combined factor is utilized to “Scale-To-Ground” and is used to adjust the distance expressed on the map surface and convert to the position on the actual ground surface. This value is the product of the map scale factor and the height factor, ensuring the positioning measurements can be correctly placed on a map and on the ground. The combined factor is similar to linear distortion in that it is evaluated at the ground, but, as discussed in the next section, differs numerically. Often C_F is scrutinized for map projection optimization. Linear distortion, δ - In keeping with the design definitions of SPCS2022 (Dennis 2023), we refer to scale error when discussing the lunar reference sphere and linear distortion, δ, when discussing the topographic surface. Linear distortion is calculated using C_F simply by subtracting 1. Distances are expended on the topographic surface when δ is positive and compressed when δ is negative. The relevant files associated with the expressed LTM distortion are as follows. The scale factor for the 90 LTM projections: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_K_grid_scale_factor.tif Height Factor for the LTM portion of the Moon: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_EF_elevation_factor.tif Combined Factor in LTM portion of the Moon LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_CF_combined_factor.tif The relevant files associated with the expressed LPS distortion are as follows. Lunar North Pole The scale factor for the northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the north pole of the Moon: LUNAR_LGRS_NP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_CF_combined_factor.tif Lunar South Pole Scale factor for the northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the south pole of the Moon: LUNAR_LGRS_SP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_CF_combined_factor.tif For GIS utilization of grid shapefiles projected in Lunar Latitude and Longitude, referred to as “Display Only”, please utilize a registered lunar geographic coordinate system (GCS) such as IAU_2015:30100 or ESRI:104903. LTM, LPS, and LGRS PCRS shapefiles utilize either a custom transverse Mercator or polar Stereographic projection. For PCRS grids the LTM and LPS projections are recommended for all LTM, LPS, and LGRS grid sizes. See McClernan et. al. (in-press) for such projections. Raster data was calculated using planetocentric latitude and longitude. A LTM and LPS projection or a registered lunar GCS may be utilized to display this data. Note: All data, shapefiles and rasters, require a specific projection and datum. The projection is recommended as LTM and LPS or, when needed, IAU_2015:30100 or ESRI:104903. The datum utilized must be the Jet Propulsion Laboratory (JPL) Development Ephemeris (DE) 421 in the Mean Earth (ME) Principal Axis Orientation as recommended by the International Astronomy Union (IAU) (Archinal et. al., 2008).

This dataset contains a variety of spatial data layers compiled in support of research activities associated with the NAME research program. With a few exception the data layers have each been imported and projected to a common geographic coordinate system into the ESRI ArcGIS geographical information system. This dataset is one large (550 MB) gzipped tar file.

Contains NY State Plane Coordinate System Zones. For use to see what State Plane Zone in New York of an area you are working in is.Please contact NYS ITS Geospatial Services at nysgis@its.ny.gov if you have any questions

The purpose of creating and utilizing a road spatial data standard is to consolidate road spatial data and integrate the existing feature attribute information into a national database for reporting, planning, analysis and sharing purposes.

The primary benefit of using the road spatial data standard remains the organization and documentation of road data to allow users to share spatial data between parks, regions, programs, other federal agencies, and the public, at the national level.

This feature class contains lines representing formal and informal trails as well as routes within and across National Park Units. This dataset uses a set of core attributes designed by the NPS enterprise geospatial committee.

U.S. State Plane Zones (NAD 1927) represents the State Plane Coordinate System (SPCS) Zones for the 1927 North American Datum within United States.

There are many useful strategies for preparing GIS data for Next Generation 9-1-1. One step of preparation is making sure that all of the required fields exist (and sometimes populated) before loading into the system. While some localities add needed fields to their local data, others use an extract, transform, and load process to transform their local data into a Next Generation 9-1-1 GIS data model, and still others may do a combination of both.There are several strategies and considerations when loading data into a Next Generation 9-1-1 GIS data model. The best place to start is using a GIS data model schema template, or an empty file with the needed data layout to which you can append your data. Here are some resources to help you out. 1) The National Emergency Number Association (NENA) has a GIS template available on the Next Generation 9-1-1 GIS Data Model Page.2) The NENA GIS Data Model template uses a WGS84 coordinate system and pre-builds many domains. The slides from the Virginia NG9-1-1 User Group meeting in May 2021 explain these elements and offer some tips and suggestions for working with them. There are also some tips on using field calculator. Click the "open" button at the top right of this screen or here to view this information.3) VGIN adapted the NENA GIS Data Model into versions for Virginia State Plane North and Virginia State Plane South, as Virginia recommends uploading in your local coordinates and having the upload tools consistently transform your data to the WGS84 (4326) parameters required by the Next Generation 9-1-1 system. These customized versions only include the Site Structure Address Point and Street Centerlines feature classes. Address Point domains are set for address number, state, and country. Street Centerline domains are set for address ranges, parity, one way, state, and country. 4) A sample extract, transform, and load (ETL) for NG9-1-1 Upload script is available here.Additional resources and recommendations on GIS related topics are available on the VGIN 9-1-1 & GIS page.

Tacoma 1973 - 3 foot Aerials for ArcGIS Online/Bing Maps/Google Maps, etc.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgFlight Times:September, 1973 and June 17, 1974Scale: 1” = 400'Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.582581 East longitude: -122.321904 North latitude: 47.331638 South latitude: 47.130024Extent in the item's coordinate system: West longitude: 1123999.606494 East longitude: 1187000.756494 South latitude: 661999.767430 North latitude: 733999.867430

Puyallup River 1940 - 3 foot Aerials for ArcGIS Online/Bing Maps/Google Maps, etc.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgCompany: Army Corps of EngineersScale: Approx. 1:15,000 Puget Sound River History Project - Version 1 Puget Sound River History Project - Version 2MetadataOriginal ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.508957 East longitude: -122.305211 North latitude: 47.377456 South latitude: 47.121285Extent in the item's coordinate system: West longitude: 1142687.587301 East longitude: 1191072.715539 South latitude: 658328.705521 North latitude: 750622.583189

U.S. State Plane Zones (NAD 1983) represents the State Plane Coordinate System (SPCS) Zones for the 1983 North American Datum within United States.

Several State Plane Coordinate System zones are not shown in this dataset, including Puerto Rico, the U.S. Virgin Islands, American Samoa, Guam, and Louisiana's offshore zone.

Tacoma 1990 - USGS 1 meter Aerials for ArcGIS Online/Bing Maps/Google Maps, etc. This layer includes UP, Fircrest, Fife, and some of Federal Way.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgCompany: U.S. Geological SurveyFlight Time: July, 1990Metadata (Internal use only)Earth Explorer Full Display of Record 1 (Internal use only)Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.632392 East longitude: -122.304303 North latitude: 47.380453 South latitude: 47.118196Extent in the item's coordinate system: West longitude: 1112120.835383 East longitude: 1191291.333557 South latitude: 658000.509741 North latitude: 751710.870268

Service Area 2005 - 6 inch Aerials for ArcGIS Online/Bing Maps/Google Maps, etc.Coverage area includes Gig Harbor, Fox Island, McNeil Island, Anderson Island, and more land to the west and north.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgPhotos supplied by Mapcon Mapping.Photos taken in July, 2005.Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.852199 East longitude: -121.962361 North latitude: 47.418869 South latitude: 46.754961Extent in the item's coordinate system: West longitude: 1058000.000000 East longitude: 1274000.000000 South latitude: 527000.000000 North latitude: 764000.000000

Puget Sound 2002 - 1 foot Aerials for ArcGIS Online/Bing Maps/Google Maps, etc. Includes areas north to Everett; east to Monroe, Sammamish, and Buckley; west to Vashon, Bremerton, and Gig Harbor; South to Roy.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgCompany: Triathlon, Inc.Flight Date: June, 2002Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.695504 East longitude: -121.932319 North latitude: 48.027739 South latitude: 46.980475Extent in the item's coordinate system: West longitude: 1103000.000000 East longitude: 1283000.000000 South latitude: 608000.000000 North latitude: 986000.000000

Water Service Area 2018 - 3 inch Aerials for ArcGIS Online/Bing Maps/Google Maps, etc.Allow clients to export 100,000 cached tiles for offline use.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgCompany: Quantum Spatial, Inc.Flight Time Date Range:Beginning Date: 06/17/2018Ending Date: 07/15/2018Detailed Metadata (Internal use only)Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.597308 East longitude: -121.732097 North latitude: 47.347891 South latitude: 47.061812Extent in the item's coordinate system: West longitude: 1120428.000000 East longitude: 1333428.000000 South latitude: 637207.000000 North latitude: 737082.000000

Water Service Area 1998 - 6 inch Aerials for ArcGIS Online/Bing Maps/Google Maps, etc. Includes Gig Harbor. Missing some coverage in Federal Way and to the east by South Prairie.Contact Info: Name: GIS Team Email: GISteam@cityoftacoma.orgCompany: Nies Mapping Group, Inc.Flight Date: July, 1998Original ArcGIS coordinate system: Type: Projected Geographic coordinate reference: GCS_North_American_1983_HARN Projection: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet Well-known identifier: 2927Geographic extent - Bounding rectangle: West longitude: -122.706776 East longitude: -122.076790 North latitude: 47.414788 South latitude: 46.988018Extent in the item's coordinate system: West longitude: 1094000.000000 East longitude: 1246999.999963 South latitude: 611000.000027 North latitude: 763036.499990

This intersection points feature class represents current intersections in the City of Los Angeles. Few intersection points, named pseudo nodes, are used to split the street centerline at a point that is not a true intersection at the ground level. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Intersection layer was created in geographical information systems (GIS) software to display intersection points. Intersection points are placed where street line features join or cross each other and where freeway off- and on-ramp line features join street line features. The intersection points layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a point feature class and attribute data for the features. The intersection points relates to the intersection attribute table, which contains data describing the limits of the street segment, by the CL_NODE_ID field. The layer shows the location of the intersection points on map products and web mapping applications, and the Department of Transportation, LADOT, uses the intersection points in their GIS system. The intersection attributes are used in the Intersection search function on BOE's web mapping application NavigateLA. The intersection spatial data and related attribute data are maintained in the Intersection layer using Street Centerline Editing application. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. List of Fields:Y: This field captures the georeferenced location along the vertical plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, Y = in the record of a point, while the X = .CL_NODE_ID: This field value is entered as new point features are added to the edit layer, during Street Centerline application editing process. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline spatial data layer, then the intersections point spatial data layer, and then the intersections point attribute data during the creation of new intersection points. Each intersection identification number is a unique value. The value relates to the street centerline layer attributes, to the INT_ID_FROM and INT_ID_TO fields. One or more street centerline features intersect the intersection point feature. For example, if a street centerline segment ends at a cul-de-sac, then the point feature intersects only one street centerline segment.X: This field captures the georeferenced location along the horizontal plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, X = in the record of a point, while the Y = .ASSETID: User-defined feature autonumber.USER_ID: The name of the user carrying out the edits.SHAPE: Feature geometry.LST_MODF_DT: Last modification date of the polygon feature.LAT: This field captures the Latitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.OBJECTID: Internal feature number.CRTN_DT: Creation date of the polygon feature.TYPE: This field captures a value for intersection point features that are psuedo nodes or outside of the City. A pseudo node, or point, does not signify a true intersection of two or more different street centerline features. The point is there to split the line feature into two segments. A pseudo node may be needed if for example, the Bureau of Street Services (BSS) has assigned different SECT_ID values for those segments. Values: • S - Feature is a pseudo node and not a true intersection. • null - Feature is an intersection point. • O - Intersection point is outside of the City of LA boundary.LON: This field captures the Longitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.

Summary Rail Crossings is a spatial file maintained by the Federal Railroad Administration (FRA) for use by States and railroads. Description FRA Grade Crossings is a spatial file that originates from the National Highway-Rail Crossing, Inventory Program. The program is to provide information to Federal, State, and local governments, as well as the railroad industry for the improvements of safety at highway-rail crossing. Credits Federal Railroad Administration (FRA) Use limitations There are no access and use limitations for this item. Extent West -79.491008 East -75.178954 North 39.733500 South 38.051719 Scale Range Maximum (zoomed in) 1:5,000 Minimum (zoomed out) 1:150,000,000 ArcGIS Metadata ▼►Topics and Keywords ▼►Themes or categories of the resource  transportation * Content type  Downloadable Data Export to FGDC CSDGM XML format as Resource Description No Temporal keywords  2013 Theme keywords  Rail Theme keywords  Grade Crossing Theme keywords  Rail Crossings Citation ▼►Title rr_crossings Creation date 2013-03-15 00:00:00 Presentation formats  * digital map Citation Contacts ▼►Responsible party  Individual's name Raquel Hunt Organization's name Federal Railroad Administration (FRA) Contact's position GIS Program Manager Contact's role  custodian Responsible party  Organization's name Research and Innovative Technology Administration/Bureau of Transportation Statistics Individual's name National Transportation Atlas Database (NTAD) 2013 Contact's position Geospatial Information Systems Contact's role  distributor Contact information  ▼►Phone  Voice 202-366-DATA Address  Type  Delivery point 1200 New Jersey Ave. SE City Washington Administrative area DC Postal code 20590 e-mail address answers@BTS.gov Resource Details ▼►Dataset languages  * English (UNITED STATES) Dataset character set  utf8 - 8 bit UCS Transfer Format Spatial representation type  * vector * Processing environment Microsoft Windows 7 Version 6.1 (Build 7600) ; Esri ArcGIS 10.2.0.3348 Credits Federal Railroad Administration (FRA) ArcGIS item properties  * Name USDOT_RRCROSSINGS_MD * Size 0.047 Location withheld * Access protocol Local Area Network Extents ▼►Extent  Geographic extent  Bounding rectangle  Extent type  Extent used for searching * West longitude -79.491008 * East longitude -75.178954 * North latitude 39.733500 * South latitude 38.051719 * Extent contains the resource Yes Extent in the item's coordinate system  * West longitude 611522.170675 * East longitude 1824600.445629 * South latitude 149575.449134 * North latitude 752756.624659 * Extent contains the resource Yes Resource Points of Contact ▼►Point of contact  Individual's name Raquel Hunt Organization's name Federal Railroad Administration (FRA) Contact's position GIS Program Manager Contact's role  custodian Resource Maintenance ▼►Resource maintenance  Update frequency  annually Resource Constraints ▼►Constraints  Limitations of use There are no access and use limitations for this item. Spatial Reference ▼►ArcGIS coordinate system  * Type Projected * Geographic coordinate reference GCS_North_American_1983_HARN * Projection NAD_1983_HARN_StatePlane_Maryland_FIPS_1900_Feet * Coordinate reference details  Projected coordinate system  Well-known identifier 2893 X origin -120561100 Y origin -95444400 XY scale 36953082.294548117 Z origin -100000 Z scale 10000 M origin -100000 M scale 10000 XY tolerance 0.0032808333333333331 Z tolerance 0.001 M tolerance 0.001 High precision true Latest well-known identifier 2893 Well-known text PROJCS["NAD_1983_HARN_StatePlane_Maryland_FIPS_1900_Feet",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree"

Crowther_Nature_Files.zip This description pertains to the original download. Details on revised (newer) versions of the datasets are listed below. When more than one version of a file exists in Figshare, the original DOI will take users to the latest version, though each version technically has its own DOI. -- Two global maps (raster files) of tree density. These maps highlight how the number of trees varies across the world. One map was generated using biome-level models of tree density, and applied at the biome scale. The other map was generated using ecoregion-level models of tree density, and applied at the ecoregion scale. For this reason, transitions between biomes or between ecoregions may be unrealistically harsh, but large-scale estimates are robust (see Crowther et al 2015 and Glick et al 2016). At the outset, this study was intended to generate reliable estimates at broad spatial scales, which inherently comes at the cost of fine-scale precision. For this reason, country-scale (or larger) estimates are generally more robust than individual pixel-level estimates. Additionally, due to data limitations, estimates for Mangroves and Tropical coniferous forest (as identified by WWF and TNC) were generated using models constructed from Topical moist broadleaf forest data and Temperate coniferous forest data, respectively. Because we used ecological analogy, the estimates for these two biomes should be considered less reliable than those of other biomes . These two maps initially appeared in Crowther et al (2015), with the biome map being featured more prominently. Explicit publication of the data is associated with Glick et al (2016). As they are produced, updated versions of these datasets, as well as alternative formats, will be made available under Additional Versions (see below).

Methods: We collected over 420,000 ground-sources estimates of tree density from around the world. We then constructed linear regression models using vegetative, climatic, topographic, and anthropogenic variables to produce forest tree density estimates for all locations globally. All modeling was done in R. Mapping was done using R and ArcGIS 10.1.

Viewing Instructions: Load the files into an appropriate geographic information system (GIS). For the original download (ArcGIS geodatabase files), load the files into ArcGIS to view or export the data to other formats. Because these datasets are large and have a unique coordinate system that is not read by many GIS, we suggest loading them into an ArcGIS dataframe whose coordinate system matches that of the data (see File Format). For GeoTiff files (see Additional Versions), load them into any compatible GIS or image management program.

Comments: The original download provides a zipped folder that contains (1) an ArcGIS File Geodatabase (.gdb) containing one raster file for each of the two global models of tree density – one based on biomes and one based on ecoregions; (2) a layer file (.lyr) for each of the global models with the symbology used for each respective model in Crowther et al (2015); and an ArcGIS Map Document (.mxd) that contains the layers and symbology for each map in the paper. The data is delivered in the Goode homolosine interrupted projected coordinate system that was used to compute biome, ecoregion, and global estimates of the number and density of trees presented in Crowther et al (2015). To obtain maps like those presented in the official publication, raster files will need to be reprojected to the Eckert III projected coordinate system. Details on subsequent revisions and alternative file formats are list below under Additional Versions.----------

Additional Versions: Crowther_Nature_Files_Revision_01.zip contains tree density predictions for small islands that are not included in the data available in the original dataset. These predictions were not taken into consideration in production of maps and figures presented in Crowther et al (2015), with the exception of the values presented in Supplemental Table 2. The file structure follows that of the original data and includes both biome- and ecoregion-level models.

Crowther_Nature_Files_Revision_01_WGS84_GeoTiff.zip contains Revision_01 of the biome-level model, but stored in WGS84 and GeoTiff format. This file was produced by reprojecting the original Goode homolosine files to WGS84 using nearest neighbor resampling in ArcMap. All areal computations presented in the manuscript were computed using the Goode homolosine projection. This means that comparable computations made with projected versions of this WGS84 data are likely to differ (substantially at greater latitudes) as a product of the resampling. Included in this .zip file are the primary .tif and its visualization support files.

References:

Crowther, T. W., Glick, H. B., Covey, K. R., Bettigole, C., Maynard, D. S., Thomas, S. M., Smith, J. R., Hintler, G., Duguid, M. C., Amatulli, G., Tuanmu, M. N., Jetz, W., Salas, C., Stam, C., Piotto, D., Tavani, R., Green, S., Bruce, G., Williams, S. J., Wiser, S. K., Huber, M. O., Hengeveld, G. M., Nabuurs, G. J., Tikhonova, E., Borchardt, P., Li, C. F., Powrie, L. W., Fischer, M., Hemp, A., Homeier, J., Cho, P., Vibrans, A. C., Umunay, P. M., Piao, S. L., Rowe, C. W., Ashton, M. S., Crane, P. R., and Bradford, M. A. 2015. Mapping tree density at a global scale. Nature, 525(7568): 201-205. DOI: http://doi.org/10.1038/nature14967Glick, H. B., Bettigole, C. B., Maynard, D. S., Covey, K. R., Smith, J. R., and Crowther, T. W. 2016. Spatially explicit models of global tree density. Scientific Data, 3(160069), doi:10.1038/sdata.2016.69.

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.Data Processing: Tax roll provided by the county has multiple records for each unique parcel record as many of the parcels have multiple uses. As a result many of the parcel records are duplicated.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)