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).

Please note that this dataset is not an official City of Toronto land use dataset. It was created for personal and academic use using City of Toronto Land Use Maps (2019) found on the City of Toronto Official Plan website at https://www.toronto.ca/city-government/planning-development/official-plan-guidelines/official-plan/official-plan-maps-copy, along with the City of Toronto parcel fabric (Property Boundaries) found at https://open.toronto.ca/dataset/property-boundaries/ and Statistics Canada Census Dissemination Blocks level boundary files (2016). The property boundaries used were dated November 11, 2021. Further detail about the City of Toronto's Official Plan, consolidation of the information presented in its online form, and considerations for its interpretation can be found at https://www.toronto.ca/city-government/planning-development/official-plan-guidelines/official-plan/ Data Creation Documentation and Procedures Software Used The spatial vector data were created using ArcGIS Pro 2.9.0 in December 2021. PDF File Conversions Using Adobe Acrobat Pro DC software, the following downloaded PDF map images were converted to TIF format. 9028-cp-official-plan-Map-14_LandUse_AODA.pdf 9042-cp-official-plan-Map-22_LandUse_AODA.pdf 9070-cp-official-plan-Map-20_LandUse_AODA.pdf 908a-cp-official-plan-Map-13_LandUse_AODA.pdf 978e-cp-official-plan-Map-17_LandUse_AODA.pdf 97cc-cp-official-plan-Map-15_LandUse_AODA.pdf 97d4-cp-official-plan-Map-23_LandUse_AODA.pdf 97f2-cp-official-plan-Map-19_LandUse_AODA.pdf 97fe-cp-official-plan-Map-18_LandUse_AODA.pdf 9811-cp-official-plan-Map-16_LandUse_AODA.pdf 982d-cp-official-plan-Map-21_LandUse_AODA.pdf Georeferencing and Reprojecting Data Files The original projection of the PDF maps is unknown but were most likely published using MTM Zone 10 EPSG 2019 as per many of the City of Toronto's many datasets. They could also have possibly been published in UTM Zone 17 EPSG 26917 The TIF images were georeferenced in ArcGIS Pro using this projection with very good results. The images were matched against the City of Toronto's Centreline dataset found here The resulting TIF files and their supporting spatial files include: TOLandUseMap13.tfwx TOLandUseMap13.tif TOLandUseMap13.tif.aux.xml TOLandUseMap13.tif.ovr TOLandUseMap14.tfwx TOLandUseMap14.tif TOLandUseMap14.tif.aux.xml TOLandUseMap14.tif.ovr TOLandUseMap15.tfwx TOLandUseMap15.tif TOLandUseMap15.tif.aux.xml TOLandUseMap15.tif.ovr TOLandUseMap16.tfwx TOLandUseMap16.tif TOLandUseMap16.tif.aux.xml TOLandUseMap16.tif.ovr TOLandUseMap17.tfwx TOLandUseMap17.tif TOLandUseMap17.tif.aux.xml TOLandUseMap17.tif.ovr TOLandUseMap18.tfwx TOLandUseMap18.tif TOLandUseMap18.tif.aux.xml TOLandUseMap18.tif.ovr TOLandUseMap19.tif TOLandUseMap19.tif.aux.xml TOLandUseMap19.tif.ovr TOLandUseMap20.tfwx TOLandUseMap20.tif TOLandUseMap20.tif.aux.xml TOLandUseMap20.tif.ovr TOLandUseMap21.tfwx TOLandUseMap21.tif TOLandUseMap21.tif.aux.xml TOLandUseMap21.tif.ovr TOLandUseMap22.tfwx TOLandUseMap22.tif TOLandUseMap22.tif.aux.xml TOLandUseMap22.tif.ovr TOLandUseMap23.tfwx TOLandUseMap23.tif TOLandUseMap23.tif.aux.xml TOLandUseMap23.tif.ov Ground control points were saved for all georeferenced images. The files are the following: map13.txt map14.txt map15.txt map16.txt map17.txt map18.txt map19.txt map21.txt map22.txt map23.txt The City of Toronto's Property Boundaries shapefile, "property_bnds_gcc_wgs84.zip" were unzipped and also reprojected to EPSG 26917 (UTM Zone 17) into a new shapefile, "Property_Boundaries_UTM.shp" Mosaicing Images Once georeferenced, all images were then mosaiced into one image file, "LandUseMosaic20211220v01", within the project-generated Geodatabase, "Landuse.gdb" and exported TIF, "LandUseMosaic20211220.tif" Reclassifying Images Because the original images were of low quality and the conversion to TIF made the image colours even more inconsistent, a method was required to reclassify the images so that different land use classes could be identified. Using Deep learning Objects, the images were re-classified into useful consistent colours. Deep Learning Objects and Training The resulting mosaic was then prepared for reclassification using the Label Objects for Deep Learning tool in ArcGIS Pro. A training sample, "LandUseTrainingSamples20211220", was created in the geodatabase for all land use types as follows: Neighbourhoods Insitutional Natural Areas Core Employment Areas Mixed Use Areas Apartment Neighbourhoods Parks Roads Utility Corridors Other Open Spaces General Employment Areas Regeneration Areas Lettering (not a land use type, but an image colour (black), used to label streets). By identifying the letters, it then made the reclassification and vectorization results easier to clean up of unnecessary clutter caused by the labels of streets. Reclassification Once the... Visit https://dataone.org/datasets/sha256%3A3e3f055bf6281f979484f847d0ed5eeb96143a369592149328c370fe5776742b for complete metadata about this dataset.

Urban areas have a manifold and far-reaching impact on our environment, and the three-dimensional structure is a key aspect for characterizing the urban environment.

This dataset features a map of building height predictions for entire Germany on a 10m grid based on Sentinel-1A/B and Sentinel-2A/B time series. We utilized machine learning regression to extrapolate building height reference information to the entire country. The reference data were obtained from several freely and openly available 3D Building Models originating from official data sources (building footprint: cadaster, building height: airborne laser scanning), and represent the average building height within a radius of 50m relative to each pixel. Building height was only estimated for built-up areas (European Settlement Mask), and building height predictions <2m were set to 0m.

Temporal extent
The acquisition dates of the different data sources vary to some degree:
- Independent variables: Sentinel-2 data are from 2018; Sentinel-1 data are from 2017.
- Dependent variables: the 3D building models are from 2012-2020 depending on data provider.
- Settlement mask: the ESM is based on a mosaic of imagery from 2014-2016.
Considering that net change of building stock is positive in Germany, the building height map is representative for ca. 2015.

Data format
The data come in tiles of 30x30km (see shapefile). The projection is EPSG:3035. The images are compressed GeoTiff files (*.tif). Metadata are located within the Tiff, partly in the FORCE domain. There is a mosaic in GDAL Virtual format (*.vrt), which can readily be opened in most Geographic Information Systems. Building height values are in meters, scaled by 10, i.e. a pixel value of 69 = 6.9m.

Further information
For further information, please see the publication or contact David Frantz (david.frantz@geo.hu-berlin.de).
A web-visualization of this dataset is available here.

Publication
Frantz, D., Schug, F., Okujeni, A., Navacchi, C., Wagner, W., van der Linden, S., & Hostert, P. (2021). National-scale mapping of building height using Sentinel-1 and Sentinel-2 time series. Remote Sensing of Environment, 252, 112128. DOI: https://doi.org/10.1016/j.rse.2020.112128

Acknowledgements
The dataset was generated by FORCE v. 3.1 (paper, code), which is freely available software under the terms of the GNU General Public License v. >= 3. Sentinel imagery were obtained from the European Space Agency and the European Commission. The European Settlement Mask was obtained from the European Commission. 3D building models were obtained from Berlin Partner für Wirtschaft und Technologie GmbH, Freie und Hansestadt Hamburg / Landesbetrieb Geoinformation und Vermessung, Landeshauptstadt Potsdam, Bezirksregierung Köln / Geobasis NRW, and Kompetenzzentrum Geodateninfrastruktur Thüringen. This dataset was partly produced on EODC - we thank Clement Atzberger for supporting the generation of this dataset by sharing disc space on EODC.

Funding
This dataset was produced with funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (MAT_STOCKS, grant agreement No 741950).

This is an ArcGIS Server Image Service of the 4-band 2021 National Agricultural Imagery Program (NAIP) orthorectified digital aerial photos of Montana. Imagery defaults to natural color. To view the imagery as false-color infrared (CIR), select band 4 as the red image, band 1 as the green, and band 2 as the blue. This data set contains imagery from the National Agriculture Imagery Program (NAIP). These data are digital aerial photos, at 60 centimeter resolution, of the state of Montana, taken in 2021. The data are available from the State Library in two different formats. The most accessible format is a downloadable collection of compressed county mosaic (CCM) 4-Band MrSID images. These data are in UTM coordinates. The FTP folder containing these images is https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2023_NAIP/UTM_County_Mosaics The data are available from the State Library as a collection 10,505 4-band (near infrared, red, green and blue) TIFF images in UTM coordinates. Each image is about 425 megabytes. The tiling format of the TIFF imagery is based on 3.75 x 3.75 minute quarter-quadrangles with a 300 pixel buffer on all four sides. An ESRI shapefile index showing the extent and acquisition dates of the TIF images is available at:Tile Index: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2023_NAIP/NAIP2023_TileIndex_shp.zipPhoto Dates: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2023_NAIP/NAIP2023_ImageDates_shp.zipTo order TIFF images from the State Library, select the quadrangles you want from the tiff index shapefile and send them to the Library, along with a storage device of sufficient size to hold them and return postage for the device. More information on ordering can be found at the following website https://msl.mt.gov/geoinfo/data/Aerial_Photos/Ordering

Reason for SelectionProtected natural areas in urban environments provide urban residents a nearby place to connect with nature and offer refugia for some species. They help foster a conservation ethic by providing opportunities for people to connect with nature, and also support ecosystem services like offsetting heat island effects (Greene and Millward 2017, Simpson 1998), water filtration, stormwater retention, and more (Hoover and Hopton 2019). In addition, parks, greenspace, and greenways can help improve physical and psychological health in communities (Gies 2006). Urban park size complements the equitable access to potential parks indicator by capturing the value of existing parks.Input DataSoutheast Blueprint 2024 extentFWS National Realty Tracts, accessed 12-13-2023Protected Areas Database of the United States(PAD-US):PAD-US 3.0national geodatabase -Combined Proclamation Marine Fee Designation Easement, accessed 12-6-20232020 Census Urban Areas from the Census Bureau’s urban-rural classification; download the data, read more about how urban areas were redefined following the 2020 censusOpenStreetMap data “multipolygons” layer, accessed 12-5-2023A polygon from this dataset is considered a beach if the value in the “natural” tag attribute is “beach”. Data for coastal states (VA, NC, SC, GA, FL, AL, MS, LA, TX) were downloaded in .pbf format and translated to an ESRI shapefile using R code. OpenStreetMap® is open data, licensed under theOpen Data Commons Open Database License (ODbL) by theOpenStreetMap Foundation (OSMF). Additional credit to OSM contributors. Read more onthe OSM copyright page.2021 National Land Cover Database (NLCD): Percentdevelopedimperviousness2023NOAA coastal relief model: volumes 2 (Southeast Atlantic), 3 (Florida and East Gulf of America), 4 (Central Gulf of America), and 5 (Western Gulf of America), accessed 3-27-2024Mapping StepsCreate a seamless vector layer to constrain the extent of the urban park size indicator to inland and nearshore marine areas <10 m in depth. The deep offshore areas of marine parks do not meet the intent of this indicator to capture nearby opportunities for urban residents to connect with nature. Shallow areas are more accessible for recreational activities like snorkeling, which typically has a maximum recommended depth of 12-15 meters. This step mirrors the approach taken in the Caribbean version of this indicator.Merge all coastal relief model rasters (.nc format) together using QGIS “create virtual raster”.Save merged raster to .tif and import into ArcPro.Reclassify the NOAA coastal relief model data to assign areas with an elevation of land to -10 m a value of 1. Assign all other areas (deep marine) a value of 0.Convert the raster produced above to vector using the “RasterToPolygon” tool.Clip to 2024 subregions using “Pairwise Clip” tool.Break apart multipart polygons using “Multipart to single parts” tool.Hand-edit to remove deep marine polygon.Dissolve the resulting data layer.This produces a seamless polygon defining land and shallow marine areas.Clip the Census urban area layer to the bounding box of NoData surrounding the extent of Southeast Blueprint 2024.Clip PAD-US 3.0 to the bounding box of NoData surrounding the extent of Southeast Blueprint 2024.Remove the following areas from PAD-US 3.0, which are outside the scope of this indicator to represent parks:All School Trust Lands in Oklahoma and Mississippi (Loc Des = “School Lands” or “School Trust Lands”). These extensive lands are leased out and are not open to the public.All tribal and military lands (“Des_Tp” = "TRIBL" or “Des_Tp” = "MIL"). Generally, these lands are not intended for public recreational use.All BOEM marine lease blocks (“Own_Name” = "BOEM"). These Outer Continental Shelf lease blocks do not represent actively protected marine parks, but serve as the “legal definition for BOEM offshore boundary coordinates...for leasing and administrative purposes” (BOEM).All lands designated as “proclamation” (“Des_Tp” = "PROC"). These typically represent the approved boundary of public lands, within which land protection is authorized to occur, but not all lands within the proclamation boundary are necessarily currently in a conserved status.Retain only selected attribute fields from PAD-US to get rid of irrelevant attributes.Merged the filtered PAD-US layer produced above with the OSM beaches and FWS National Realty Tracts to produce a combined protected areas dataset.The resulting merged data layer contains overlapping polygons. To remove overlapping polygons, use the Dissolve function.Clip the resulting data layer to the inland and nearshore extent.Process all multipart polygons (e.g., separate parcels within a National Wildlife Refuge) to single parts (referred to in Arc software as an “explode”).Select all polygons that intersect the Census urban extent within 0.5 miles. We chose 0.5 miles to represent a reasonable walking distance based on input and feedback from park access experts. Assuming a moderate intensity walking pace of 3 miles per hour, as defined by the U.S. Department of Health and Human Service’s physical activity guidelines, the 0.5 mi distance also corresponds to the 10-minute walk threshold used in the equitable access to potential parks indicator.Dissolve all the park polygons that were selected in the previous step.Process all multipart polygons to single parts (“explode”) again.Add a unique ID to the selected parks. This value will be used in a later step to join the parks to their buffers.Create a 0.5 mi (805 m) buffer ring around each park using the multiring plugin in QGIS. Ensure that “dissolve buffers” is disabled so that a single 0.5 mi buffer is created for each park.Assess the amount of overlap between the buffered park and the Census urban area using “overlap analysis”. This step is necessary to identify parks that do not intersect the urban area, but which lie within an urban matrix (e.g., Umstead Park in Raleigh, NC and Davidson-Arabia Mountain Nature Preserve in Atlanta, GA). This step creates a table that is joined back to the park polygons using the UniqueID.Remove parks that had ≤10% overlap with the urban areas when buffered. This excludes mostly non-urban parks that do not meet the intent of this indicator to capture parks that provide nearby access for urban residents. Note: The 10% threshold is a judgement call based on testing which known urban parks and urban National Wildlife Refuges are captured at different overlap cutoffs and is intended to be as inclusive as possible.Calculate the GIS acres of each remaining park unit using the Add Geometry Attributes function.Buffer the selected parks by 15 m. Buffering prevents very small and narrow parks from being left out of the indicator when the polygons are converted to raster.Reclassify the parks based on their area into the 7 classes seen in the final indicator values below. These thresholds were informed by park classification guidelines from the National Recreation and Park Association, which classify neighborhood parks as 5-10 acres, community parks as 30-50 acres, and large urban parks as optimally 75+ acres (Mertes and Hall 1995).Assess the impervious surface composition of each park using the NLCD 2021 impervious layer and the Zonal Statistics “MEAN” function. Retain only the mean percent impervious value for each park.Extract only parks with a mean impervious pixel value <80%. This step excludes parks that do not meet the intent of the indicator to capture opportunities to connect with nature and offer refugia for species (e.g., the Superdome in New Orleans, LA, the Astrodome in Houston, TX, and City Plaza in Raleigh, NC).Extract again to the inland and nearshore extent.Export the final vector file to a shapefile and import to ArcGIS Pro.Convert the resulting polygons to raster using the ArcPy Feature to Raster function and the area class field.Assign a value of 0 to all other pixels in the Southeast Blueprint 2024 extent not already identified as an urban park in the mapping steps above. Zero values are intended to help users better understand the extent of this indicator and make it perform better in online tools.Use the land and shallow marine layer and “extract by mask” tool to save the final version of this indicator.Add color and legend to raster attribute table.As a final step, clip to the spatial extent of Southeast Blueprint 2024.Note: For more details on the mapping steps, code used to create this layer is available in theSoutheast Blueprint Data Downloadunder > 6_Code.Final indicator valuesIndicator values are assigned as follows:6= 75+ acre urban park5= 50 to <75 acre urban park4= 30 to <50 acre urban park3= 10 to <30 acre urban park2=5 to <10acreurbanpark1 = <5 acre urban park0 = Not identified as an urban parkKnown IssuesThis indicator does not include park amenities that influence how well the park serves people and should not be the only tool used for parks and recreation planning. Park standards should be determined at a local level to account for various community issues, values, needs, and available resources.This indicator includes some protected areas that are not open to the public and not typically thought of as “parks”, like mitigation lands, private easements, and private golf courses. While we experimented with excluding them using the public access attribute in PAD, due to numerous inaccuracies, this inadvertently removed protected lands that are known to be publicly accessible. As a result, we erred on the side of including the non-publicly accessible lands.The NLCD percent impervious layer contains classification inaccuracies. As a result, this indicator may exclude parks that are mostly natural because they are misclassified as mostly impervious. Conversely, this indicator may include parks that are mostly impervious because they are misclassified as mostly

This data repository contains a set of multi-temporal data products of ecosystem structure derived from four national ALS surveys of the Netherlands (AHN1–AHN4) (folder: 1. Data_products). Four sets of 25 LiDAR-derived vegetation metrics representing ecosystem height, cover, and structural variability are provided at 10 m spatial resolution, providing valuable data sources for a wide range of ecological research and field beyond. All 25 LiDAR metrics were calculated using Laserfarm workflow (https://laserfarm.readthedocs.io/en/latest/) (building on the user-extendable features from the “Laserchicken” software: https://laserchicken.readthedocs.io/en/latest/#features). All metrics are calculated with the normalized point cloud. More details on metric calculation are provided on GitHub (Laserchicken: https://github.com/eEcoLiDAR/laserchicken and Laserfarm: https://github.com/eEcoLiDAR/Laserfarm), as well as on the “Laserchicken” documentation page (https://laserchicken.readthedocs.io/en/latest/). We also provided masks to minimize the influence of water surfaces, buildings and roads, as well as powerlines in the data products (folder: 2. Masks). Since the point density of each AHN dataset has changed significantly which may have influence on generated LiDAR metrics, we also provided the four raster layers of point density (all points) for each AHN dataset (folder: 3. Point_density). Two use cases demonstrated the utility of the presented data products: (use case 1) monitoring forest structural change across time using multi-temporal ALS data and (use case 2) comparison of vegetation structural difference within Natura 2000 sites. The used data are also provided (folder: 4. Use_case). Note that all the raster layers and shapefiles provided in this repository are under the local Dutch coordinate system “RD_new” (EPSG: 28992, NAP:5709).

Three subfolders are included:

1. Data_products

· AHN1.zip

· AHN2.zip

· AHN3.zip

· AHN4.zip

· Maps

It contains four folders with 25 LiDAR metrics at 10 m resolution generated from each AHN dataset. The file names and their corresponding LiDAR metrics can be found in Table 1. An additional folder (Maps) contains the maps (.pdf format) of all 25 metrics for each AHN dataset.

1. Masks

· ahn3_10m_mask_building_road_water.tif

· ahn4_10m_mask_building_road_water.tif

· ahn4_10m_mask_powerline.tif

It contains two mask layers of water surfaces, buildings and roads for both AHN3 and AHN4 data products based on the Dutch cadaster data (TOP10NL) from 2018 (corresponding to AHN3) and 2021 (corresponding to AHN4) (https://www.kadaster.nl/zakelijk/producten/geo-informatie/topnl). In the masks, water surfaces, buildings and roads were merged into one class with pixel value assigned to 1 and the rest has the pixel value of 0. There is also a powerline mask generated from the AHN4 dataset at 10 m resolution, where pixels containing powerlines were assigned a value of 1 and the rest as NoData. We provide those masks to minimize the inaccuracies of the data products caused by human infrastructures and water surfaces.

1. Point_density

· ahn1_10m_point_density.tif

· ahn2_10m_point_density.tif

· ahn3_10m_point_density.tif

· ahn4_10m_point_density.tif

It contains four raster layers (at 10 m resolution) representing the point density of each AHN dataset.

1. Use_case

2. Multi-temporal_AHN

· Data

· Usecase_multi-temporal_AHN.R

It contains the input data for the use case data processing (i.e. Data folder), including the shapefile of the area (i.e. shp folder), and extracted pixel value from six selected LiDAR metrics from AHN1–AHN5 (i.e. Metrics folder), and the selected LiDAR metrics of the area (e.g. Hp95 folder), and the R code for data processing (i.e. Usecase_multi-temporal_AHN.R).

1. Natura2000

· Data

· Natura2000_end2021_HABITATCLASS.csv

· Natura2000_NL_habitat_grouped.csv

· Usecase_Natura2000.R

It contains a folder of the input data used for the use case (i.e. Data folder), including the shapefile (i.e. shp folder) of the Natura 2000 sites in the Netherlands (i.e. Nature2000_NL_RDnew.shp) and the 100 random sample plots from each habitat type (e.g. woodland_points.shp), and the LiDAR metrics from AHN4 used for demonstrating the vegetation structure within each habitat type (i.e. AHN4_metrics folder). The table “Natura2000_end2021_HABITATCLASS.csv” is the original attribute table of Natura 2000 sites, including information related to the description of habitat classes (column “DESCRIPTION”), the code corresponding to the habitat class (column “HABITATCODE”), the code for the specific site (column “SITECODE”), and the percentage of the cover of a specific habitat class in one site (column “PERCENTAGECOVER”). The table “Natura2000_NL_habitat_grouped.csv” contains two subtabs, one (i.e. “Habitatclass”) is the copy of the original attribute table of Natura 2000 sites in the Netherlands, and the other one (i.e. “Habitat_class_summary”) is the grouped habitat type based on the dominant habitat class (i.e. class with the highest percentage cover) in each site. Different colors indicate different habitat types, corresponding to the colors in the first tab (“Habitatclass”) where the dominant habitat class was highlighted for each site.

Code availability

Jupyter Notebooks for processing AHN datasets:

https://github.com/ShiYifang/AHN

Laserfarm workflow repository:

https://github.com/eEcoLiDAR/Laserfarm

Laserchicken software repository:

https://github.com/eEcoLiDAR/laserchicken

Code for downloading AHN dataset: https://github.com/ShiYifang/AHN/tree/main/AHN_downloading

Code for generating masks for AHN datasets: https://github.com/ShiYifang/AHN/tree/main/AHN_masks

Code for demonstration of ecological use cases: https://github.com/ShiYifang/AHN/tree/main/Use_case

This is an ArcGIS Server Image Service of the 4-band 2021 National Agricultural Imagery Program (NAIP) orthorectified digital aerial photos of Montana. Imagery defaults to natural color. To view the imagery as false-color infrared (CIR), select band 4 as the red image, band 1 as the green, and band 2 as the blue. This data set contains imagery from the National Agriculture Imagery Program (NAIP). These data are digital aerial photos, at 60 centimeter resolution, of the state of Montana, taken in 2021. The data are available from the State Library in two different formats. The most accessible format is a downloadable collection of compressed county mosaic (CCM) 4-Band MrSID images. These data are in UTM coordinates. The FTP folder containing these images is https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2021_NAIP/UTM_County_Mosaics The data are available from the State Library as a collection 11,776 4-band (near infrared, red, green and blue) TIFF images in UTM coordinates. Each image is about 425 megabytes. The tiling format of the TIFF imagery is based on 3.75 x 3.75 minute quarter-quadrangles with a 300 pixel buffer on all four sides. An ESRI shapefile index showing the extent and acquisition dates of the TIF images is available at https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2021_NAIP/NAIP2021_Index_Final_UTMZone12.zip To order TIFF images from the State Library, select the quadrangles you want from the tiff index shapefile and send them to the Library, along with a storage device of sufficient size to hold them and return postage for the device. More information on ordering can be found at the following website https://msl.mt.gov/geoinfo/data/Aerial_Photos/Ordering

Abstract:This image database is comprised of digital orthophotography that was flown in June and July of 2005. The orthos have been registered to the terrain at National Map Accuracy standards. The images are stored in tif format. This database calls the path of this imagery and displays it according to the parameters of XMIN, YMIN, XMAX and YMAX. The following specs were used for this ortho flight: Flown: 2005 June and July Flight Height: 9600 feet Focal Length: 12" Pixel Size: 1/2 ft Terrain Model: Pierce County Lidar The construction of the images required the mosaicking of photo images using OrthoVista software which also corrected for color balancing. The image database has been licensed to the County by Mapcon Mapping (or OSI Geomatics). The license agreement only allows certain organizations to directly access the data. Any of the data can be produced in paper copy and distributed to the public. Digital copies of the data are not permitted. Users should note the scale of photography (1:800) and use the data appropriately. Please also note that the orthos have a better horizontal accuracy than some of the current GIS data in County View. The vertical datum for this data is North American Vertical Datum of 1988. If you are using NAD 29 as your vertical datum the elevations are going to be 3.5 feet too high and you will need to lower the elevation by 3.5ftPurpose:The orthophoto imagery serves as a basemap to inform decisions county-wide. The data is not owned by Pierce County and should be acquired from the vendor whose information can be found in the Use Limitation section of this metadata documentation.Supplemental Information:Procedures_Used In 2005 the color photography was captured using a 12" focal length. The photography was flown at an altitude of 9600 feet above mean terrain. Revisions There will be updates to the entire photo area every three years. Reviews_Applied_to_Data The photographic quality of the data is reviewed as deliveries are made. Even with the low flying heights for the photos, some features will be obscured by trees, tree lean, shadow, and building lean. Related_Spatial_and_Tabular_Data_Sets The 2005 Orthophoto Area theme, a polygon-based ArcView shapefile found in CountyView, shows the areas in which there are orthophotos. As additional deliveries of orthophotos arrive, this shapefile will be updated. References_Cited MAPCON MAPPING (OR OSI GEOMATICS), Photos flown between 6/20 - 7/28/2005. Notes The Orthophotos are stored in tiff and Mr Sid formats. The Assessor-Treasurer has requested that the tax parcel data that has been registered to Orthophotography be used to over-lay over the Orthophotos due to horizontal accuracy issues. The 2005 Orthos are now loaded in SDE. The layer is "Orthophotos.DBO.Msc_Cnty_2005" and can be accessed like any other layer in the SDE Orthophotos database. There is an area around Longbranch that is damaged, however, and so will appear as whitespace of different sizes depending on the zoom level. Per the experts at ESRI, the only way to repair this is a reload--which I will start doing immediately. This should take approximately a week based on how long the last one required. In the mean time, except for the small damaged area, the rest should be usable in its present form. It has also been noticed that an area over large parts of Tacoma that do not display when the scale is between 1:855 and 1:1733. There are probably other areas that have similarly damaged pyramids that we haven't found yet. In other words, use at your own risk. Making them available to everyone in the County is not recommended at this point.

This is an ArcGIS Server Image Service of the 4-band 2021 National Agricultural Imagery Program (NAIP) orthorectified digital aerial photos of Montana. Imagery defaults to natural color. To view the imagery as false-color infrared (CIR), select band 4 as the red image, band 1 as the green, and band 2 as the blue. This data set contains imagery from the National Agriculture Imagery Program (NAIP). These data are digital aerial photos, at 60 centimeter resolution, of most of the state of Montana, taken in 2017. Due to cloud cover, wildfire smoke, and snow cover the imagery acquisition was not completed in 2017 and some areas were acquired in 2018. The data are available from the State Library in two different formats. The most accessible format is a downloadable collection of compressed county mosaic (CCM) natural color MrSID images. These data are in UTM coordinates. The FTP folder containing these images is https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2017_NAIP/UTM_County_Mosaics. The data are available from the State Library as a collection 11,384 4-band (near infrared, red, green and blue) TIF images in UTM coordinates. Each image is about 400 megabytes. The tiling format of the TIFF imagery is based on 3.75 x 3.75 minute quarter-quadrangles with a 300 pixel buffer on all four sides. An ESRI shapefile index showing the extent and acquisition dates of the TIF images is available at https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Imagery/2017_NAIP/NAIP_2017_Index_Montana.zip. To order TIFF images from the State Library, select the quadrangles you want from the tiff index shapefile and send them to the Library, along with a storage device of sufficient size to hold them and return postage for the device.

This dataset consists of a shapefile representing 50 foot contour intervals for Santa Cruz County, Arizona. Datasets are also available for 100', 250', and 500' intervals. Each file covers an Arizona county or part of a county and as a collection covers the entire state. The data were created by processing hillshade TIF files derived from the U.S. Geological Survey National Elevation Dataset. The processing produced ESRI formatted coverages for each county or part of a county. The U.S. Geological Survey has developed a National Elevation Dataset (NED). The NED is a seamless mosaic of best-available elevation data. The 7.5-minute elevation data for the conterminous United States are the primary initial source data. In addition to the availability of complete 7.5-minute data, efficient processing methods were developed to filter production artifacts in the existing data, convert to the NAD83 datum, edge-match, and fill slivers of missing data at quadrangle seams. One of the effects of the NED processing steps is a much-improved base of elevation data for calculating slope and hydrologic derivatives. The specifications for the NED 1 arc second and 1/3 arc second data are - Geographic coordinate system, Horizontal datum of NAD83, except for AK which is NAD27, Vertical datum of NAVD88, except for AK which is NAVD29, Z units of meters.

This dataset consists of a shapefile representing 50 foot contour intervals for Santa Cruz County, Arizona. Datasets are also available for 100', 250', and 500' intervals. Each file covers an Arizona county or part of a county and as a collection covers the entire state. The data were created by processing hillshade TIF files derived from the U.S. Geological Survey National Elevation Dataset. The processing produced ESRI formatted coverages for each county or part of a county. The U.S. Geological Survey has developed a National Elevation Dataset (NED). The NED is a seamless mosaic of best-available elevation data. The 7.5-minute elevation data for the conterminous United States are the primary initial source data. In addition to the availability of complete 7.5-minute data, efficient processing methods were developed to filter production artifacts in the existing data, convert to the NAD83 datum, edge-match, and fill slivers of missing data at quadrangle seams. One of the effects of the NED processing steps is a much-improved base of elevation data for calculating slope and hydrologic derivatives. The specifications for the NED 1 arc second and 1/3 arc second data are - Geographic coordinate system, Horizontal datum of NAD83, except for AK which is NAD27, Vertical datum of NAVD88, except for AK which is NAVD29, Z units of meters.

This dataset consists of a shapefile representing 50 foot contour intervals for Santa Cruz County, Arizona. Datasets are also available for 100', 250', and 500' intervals. Each file covers an Arizona county or part of a county and as a collection covers the entire state. The data were created by processing hillshade TIF files derived from the U.S. Geological Survey National Elevation Dataset. The processing produced ESRI formatted coverages for each county or part of a county. The U.S. Geological Survey has developed a National Elevation Dataset (NED). The NED is a seamless mosaic of best-available elevation data. The 7.5-minute elevation data for the conterminous United States are the primary initial source data. In addition to the availability of complete 7.5-minute data, efficient processing methods were developed to filter production artifacts in the existing data, convert to the NAD83 datum, edge-match, and fill slivers of missing data at quadrangle seams. One of the effects of the NED processing steps is a much-improved base of elevation data for calculating slope and hydrologic derivatives. The specifications for the NED 1 arc second and 1/3 arc second data are - Geographic coordinate system, Horizontal datum of NAD83, except for AK which is NAD27, Vertical datum of NAVD88, except for AK which is NAVD29, Z units of meters.