Have you ever wanted to create your own maps, or integrate and visualize spatial datasets to examine changes in trends between locations and over time? Follow along with these training tutorials on QGIS, an open source geographic information system (GIS) and learn key concepts, procedures and skills for performing common GIS tasks – such as creating maps, as well as joining, overlaying and visualizing spatial datasets. These tutorials are geared towards new GIS users. We’ll start with foundational concepts, and build towards more advanced topics throughout – demonstrating how with a few relatively easy steps you can get quite a lot out of GIS. You can then extend these skills to datasets of thematic relevance to you in addressing tasks faced in your day-to-day work.

This dataset consists of shapefiles that correspond to the model grids used in the CSIRO eReefs hydrodynamic and biogeochemical models. These models store their results in multi-dimensional NetCDF files using a curvilinear grid. This dataset corresponds to an extract from these files converting the curvilinear grid into polygons in a shapefile. This dataset only captures the structure of the grid, not the time series data generated by the model. It contains shapefiles of the 4 km model grid (GBR4) and the 1 km grid (GBR1) as well as shapefiles for the bounding polygon of all the 'wet' cells in the model. This dataset is useful for visualising the extent of the various CSIRO eReefs models.

This dataset contains shapefiles for the 1 km and 4 km eReefs grids, derived from version 2.0 of the eReefs Hydrodynamic model. It contains shapefiles of the individual grid cells and the bounds. It also includes a low resolution version of the bounds suitable for detecting whether locations are inside the eReefs model extent.

The grid shapefile contains polygons representing each of the grid cells. An attribution is associated with each polygon corresponding to the depth used in the model. This can be used to show where the model has 'wet' cells.

Methods:

1. Representative data files for the GBR1 and GBR4 hydrodynamic version model were downloaded from the public repository of eReefs model data on NCI. The two common grids GBR1 and GBR4 are used over the model time series and for the both the hydrodynamic and biogeochemical models. We therefore just chose one model NetCDF for each model resolution. These were taken from the hydrodynamic model version 2.

2. The grid was converted to shapefiles using an R script that calculated the coordinates corners of each curvilinear pixel in the grid based on the centroids of the neighbouring pixels.

3. The grid boundary shapefiles were calculated using the merge GIS operation in QGIS after selecting all the 'wet' cells, where the depth was greater than 0.

Full step-by-step instructions and scripts are available to reproduce this dataset from github (https://github.com/eatlas/GBR_AIMS_eReefs-grid-shapefiles).

Format:

Shapefile

Data Dictionary:

SP_ID: Row and column indices in the NetCDF grid joined together depth: Depth used in the eReefs model in metres. This is based on the botz variable in the original NetCDF eReefs model data file. row: Row index in the NetCDF tables for this pixel. col: Column index in the NetCDF tables for this pixel.

Change Log: 2025-10-16 - Added DOI, ROR and ORCIDs to the record.

Data Location:

This dataset is filed in the eAtlas enduring data repository at: X:\data\custodian\2018-22-eReefs\GBR_AIMS_eReefs-grid-shapefiles Source code for reproducing this dataset is available on github (https://github.com/eatlas/GBR_AIMS_eReefs-grid-shapefiles).

The Digital Geologic-GIS Map of Virgin Islands National Park, Virgin Islands is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) an ESRI file geodatabase (viis_geology.gdb), a 2.) Open Geospatial Consortium (OGC) geopackage, and 3.) 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. The file geodatabase format is supported with a 1.) ArcGIS Pro 3.X map file (.mapx) file (viis_geology.mapx) and individual Pro 3.X layer (.lyrx) files (for each GIS data layer). The OGC geopackage is supported with a QGIS project (.qgz) file. Upon request, the GIS data is also available in ESRI shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) a readme file (viis_geology_gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (viis_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (viis_geology_metadata_faq.pdf). Please read the viis_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. Google Earth software is available for free at: https://www.google.com/earth/versions/. QGIS software is available for free at: https://www.qgis.org/en/site/. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri.htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: U.S. Geological Survey. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (viis_geology_metadata.txt or viis_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS Pro, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm).

OpenStreetMap (OSM) is a free, editable map & spatial database of the whole world. This dataset is an extract of OpenStreetMap data for 21 Pacific Island Countries, in a GIS-friendly format. The OSM data has been split into separate layers based on themes (buildings, roads, points of interest, etc), and it comes bundled with a QGIS project and styles, to help you get started with using the data in your maps. This OSM product will be updated weekly and contains data for Cook Islands, Federated States of Micronesia, Fiji, Kiribati, Republic of the Marshall Islands, Nauru, Niue, Palau, Papua New Guinea, Samoa, Solomon Islands, Tonga, Tuvalu, Vanuatu, Guam, Northern Mariana Islands, French Polynesia, Wallis and Futuna, Tokelau, American Samoa as well as data on the Pacific region. The goal is to increase awareness among Pacific GIS users of the richness of OpenStreetMap data in Pacific countries, as well as the gaps, so that they can take advantage of this free resource, become interested in contributing to OSM, and perhaps join the global OSM community.

Context

This data set was created for use in the Sberbank Kaggle competition.

Content

The data consists of three GIS shapefiles one for each of the 3 major Moscow ring roads; the MKAD, TTK (or third ring) and Sadovoe (or garden ring).

Acknowledgements

The road shapefiles have been extracted from OpenStreetMap data, processed in QGiS to extract only the roads of interest.

OpenStreetMap License: https://www.OpenStreetMap.org/copyright

Inspiration

With these files and the distances given in the Sberbank dataset it should be possible to better understand the location of properties. With a better understanding of location it may be possible to improve the quality of the overall dataset which contains material amounts of missing or poorly coded data.

This resource contains data inputs and a Jupyter Notebook that is used to introduce Hydrologic Analysis using Terrain Analysis Using Digital Elevation Models (TauDEM) and Python. TauDEM is a free and open-source set of Digital Elevation Model (DEM) tools developed at Utah State University for the extraction and analysis of hydrologic information from topography. This resource is part of a HydroLearn Physical Hydrology learning module available at https://edx.hydrolearn.org/courses/course-v1:Utah_State_University+CEE6400+2019_Fall/about

In this activity, the student learns how to (1) derive hydrologically useful information from Digital Elevation Models (DEMs); (2) describe the sequence of steps involved in mapping stream networks, catchments, and watersheds; and (3) compute an approximate water balance for a watershed-based on publicly available data.

Please note that this exercise is designed for the Logan River watershed, which drains to USGS streamflow gauge 10109000 located just east of Logan, Utah. However, this Jupyter Notebook and the analysis can readily be applied to other locations of interest. If running the terrain analysis for other study sites, you need to prepare a DEM TIF file, an outlet shapefile for the area of interest, and the average annual streamflow and precipitation data. - There are several sources to obtain DEM data. In the U.S., the DEM data (with different spatial resolutions) can be obtained from the National Elevation Dataset available from the national map (http://viewer.nationalmap.gov/viewer/). Another DEM data source is the Shuttle Radar Topography Mission (https://www2.jpl.nasa.gov/srtm/), an international research effort that obtained digital elevation models on a near-global scale (search for Digital Elevation at https://www.usgs.gov/centers/eros/science/usgs-eros-archive-products-overview?qt-science_center_objects=0#qt-science_center_objects). - If not already available, you can generate the outlet shapefile by applying basic terrain analysis steps in geospatial information system models such as ArcGIS or QGIS. - You also need to obtain average annual streamflow and precipitation data for the watershed of interest to assess the annual water balance and calculate the runoff ratio in this exercise. In the U.S., the streamflow data can be obtained from the USGS NWIS website (https://waterdata.usgs.gov/nwis) and the precipitation from PRISM (https://prism.oregonstate.edu/normals/). Note that using other datasets may require preprocessing steps to make data ready to use for this exercise.

The Digital Surficial Geologic-GIS Map of Mount Rainier National Park, Washington is composed of GIS data layers and GIS tables, and is available in the following GRI-supported GIS data formats: 1.) a 10.1 file geodatabase (mora_surficial_geology.gdb), a 2.) Open Geospatial Consortium (OGC) geopackage, and 3.) 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. The file geodatabase format is supported with a 1.) ArcGIS Pro map file (.mapx) file and individual Pro layer (.lyrx) files (for each GIS data layer), as well as with a 2.) 10.1 ArcMap (.mxd) map document (mora_surficial_geology.mxd) and individual 10.1 layer (.lyr) files (for each GIS data layer). The OGC geopackage is supported with a QGIS project (.qgz) file. Upon request, the GIS data is also available in ESRI 10.1 shapefile format. Contact Stephanie O'Meara (see contact information below) to acquire the GIS data in these GIS data formats. In addition to the GIS data and supporting GIS files, three additional files comprise a GRI digital geologic-GIS dataset or map: 1.) this file (mora_geology.gis_readme.pdf), 2.) the GRI ancillary map information document (.pdf) file (mora_geology.pdf) which contains geologic unit descriptions, as well as other ancillary map information and graphics from the source map(s) used by the GRI in the production of the GRI digital geologic-GIS data for the park, and 3.) a user-friendly FAQ PDF version of the metadata (mora_surficial_geology_metadata_faq.pdf). Please read the mora_geology_gis_readme.pdf for information pertaining to the proper extraction of the GIS data and other map files. Google Earth software is available for free at: http://www.google.com/earth/index.html. QGIS software is available for free at: https://www.qgis.org/en/site/. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). For a complete listing of GRI products visit the GRI publications webpage: For a complete listing of GRI products visit the GRI publications webpage: https://www.nps.gov/subjects/geology/geologic-resources-inventory-products.htm. For more information about the Geologic Resources Inventory Program visit the GRI webpage: https://www.nps.gov/subjects/geology/gri,htm. At the bottom of that webpage is a "Contact Us" link if you need additional information. You may also directly contact the program coordinator, Jason Kenworthy (jason_kenworthy@nps.gov). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: U.S. Geological Survey. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (mora_surficial_geology_metadata.txt or mora_surficial_geology_metadata_faq.pdf). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:48,000 and United States National Map Accuracy Standards features are within (horizontally) 24.4 meters or 80 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS, QGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: https://www.nps.gov/articles/gri-geodatabase-model.htm). The GIS data projection is NAD83, UTM Zone 10N, however, for the KML/KMZ format the data is projected upon export to WGS84 Geographic, the native

ps-places-metadata-v1.01

SUMMARY

This dataset comprises a pair of layers, (points and polys) which attempt to better locate "populated places" in NZ. Populated places are defined here as settled areas, either urban or rural where densitys of around 20 persons per hectare exist, and something is able to be seen from the air.

RATIONALE

The only liberally licensed placename dataset is currently LINZ geographic placenames, which has the following drawbacks: - coordinates are not place centers but left most label on 260 series map - the attributes are outdated

METHODOLOGY

This dataset necessarily involves cleaving the linz placenames set into two, those places that are poplulated, and those unpopulated. Work was carried out in four steps. First placenames were shortlisted according to the following criterion: - all places that rated at least POPL in the linz geographic places layer, ie POPL, METR or TOWN or USAT were adopted. - Then many additional points were added from a statnz meshblock density analysis.
- Finally remaining points were added from a check against linz residential polys, and zenbu poi clusters.

Spelling is broadly as per linz placenames, but there are differences for no particular reason. Instances of LINZ all upper case have been converted to sentance case. Some places not presently in the linz dataset are included in this set, usually new places, or those otherwise unnamed. They appear with no linz id, and are not authoritative, in some cases just wild guesses.

Density was derived from the 06 meshblock boundarys (level 2, geometry fixed), multipart conversion, merging in 06 usually resident MB population then using the formula pop/area*10000. An initial urban/rural threshold level of 0.6 persons per hectare was used.

Step two was to trace the approx extent of each populated place. The main purpose of this step was to determine the relative area of each place, and to create an intersection with meshblocks for population. Step 3 involved determining the political center of each place, broadly defined as the commercial center.

Tracing was carried out at 1:9000 for small places, and 1:18000 for large places using either bing or google satellite views. No attempt was made to relate to actual town 'boundarys'. For example large parks or raceways on the urban fringe were not generally included. Outlying industrial areas were included somewhat erratically depending on their connection to urban areas.

Step 3 involved determining the centers of each place. Points were overlaid over the following layers by way of a base reference:

a. original linz placenames b. OSM nz-locations points layer c. zenbu pois, latest set as of 5/4/11 d. zenbu AllSuburbsRegions dataset (a heavily hand modified) LINZ BDE extract derived dataset courtesy Zenbu. e. LINZ road-centerlines, sealed and highway f. LINZ residential areas, g. LINZ building-locations and building footprints h. Olivier and Co nz-urban-north and south

Therefore in practice, sources c and e, form the effective basis of the point coordinates in this dataset. Be aware that e, f and g are referenced to the LINZ topo data, while c and d are likely referenced to whatever roading dataset google possesses. As such minor discrepencys may occur when moving from one to the other.

Regardless of the above, this place centers dataset was created using the following criteria, in order of priority:

• attempts to represent the present (2011) subjective 'center' of each place as defined by its commercial/retail center ie. mainstreets where they exist, any kind of central retail cluster, even a single shop in very small places.
• the coordinate is almost always at the junction of two or more roads.
• most of the time the coordinate is at or near the centroid of the poi cluster
• failing any significant retail presence, the coordinate tends to be placed near the main road junction to the community.
• when the above criteria fail to yield a definitive answer, the final criteria involves the centroids of: . the urban polygons . the clusters of building footprints/locations.

To be clear the coordinates are manually produced by eye without any kind of computation. As such the points are placed approximately perhaps plus or minus 10m, but given that the roads layers are not that flash, no attempt was made to actually snap the coordinates to the road junctions themselves.

The final step involved merging in population from SNZ meshblocks (merge+sum by location) of popl polys). Be aware that due to the inconsistent way that meshblocks are defined this will result in inaccurate populations, particular small places will collect population from their surrounding area. In any case the population will generally always overestimate by including meshblocks that just nicked the place poly. Also there are a couple of dozen cases of overlapping meshblocks between two place polys and these will double count. Which i have so far made no attempt to fix.

Merged in also tla and regions from SNZ shapes, a few of the original linz atrributes, and lastly grading the size of urban areas according to SNZ 'urban areas" criteria. Ie: class codes:

1. Not used.
2. main urban area 30K+
3. secondary urban area 10k-30K
4. minor urban area 1k-10k
5. rural center 300-1K
6. village -300

Note that while this terminology is shared with SNZ the actual places differ owing to different decisions being made about where one area ends an another starts, and what constiutes a suburb or satellite. I expect some discussion around this issue. For example i have included tinwald and washdyke as part of ashburton and timaru, but not richmond or waikawa as part of nelson and picton. Im open to discussion on these.

No attempt has or will likely ever be made to locate the entire LOC and SBRB data subsets. We will just have to wait for NZFS to release what is thought to be an authoritative set.

PROJECTION

Shapefiles are all nztm. Orig data from SNZ and LINZ was all sourced in nztm, via koordinates, or SNZ. Satellite tracings were in spherical mercator/wgs84 and converted to nztm by Qgis. Zenbu POIS were also similarly converted.

ATTRIBUTES

Shapefile: Points id : integer unique to dataset name : name of popl place, string class : urban area size as above. integer tcode : SNZ tla code, integer rcode : SNZ region code, 1-16, integer area : area of poly place features, integer in square meters. pop : 2006 usually resident popluation, being the sum of meshblocks that intersect the place poly features. Integer lid : linz geog places id desc_code : linz geog places place type code

Shapefile: Polygons gid : integer unique to dataset, shared by points and polys name : name of popl place, string, where spelling conflicts occur points wins area : place poly area, m2 Integer

LICENSE

Clarification about the minorly derived nature of LINZ and google data needs to be sought. But pending these copyright complications, the actual points data is essentially an original work, released as public domain. I retain no copyright, nor any responsibility for data accuracy, either as is, or regardless of any changes that are subsequently made to it.

Peter Scott 16/6/2011

v1.01 minor spelling and grammar edits 17/6/11

The High Resolution Digital Elevation Model (HRDEM) product is derived from airborne LiDAR data (mainly in the south) and satellite images in the north. The complete coverage of the Canadian territory is gradually being established. It includes a Digital Terrain Model (DTM), a Digital Surface Model (DSM) and other derived data. For DTM datasets, derived data available are slope, aspect, shaded relief, color relief and color shaded relief maps and for DSM datasets, derived data available are shaded relief, color relief and color shaded relief maps. The productive forest line is used to separate the northern and the southern parts of the country. This line is approximate and may change based on requirements. In the southern part of the country (south of the productive forest line), DTM and DSM datasets are generated from airborne LiDAR data. They are offered at a 1 m or 2 m resolution and projected to the UTM NAD83 (CSRS) coordinate system and the corresponding zones. The datasets at a 1 m resolution cover an area of 10 km x 10 km while datasets at a 2 m resolution cover an area of 20 km by 20 km. In the northern part of the country (north of the productive forest line), due to the low density of vegetation and infrastructure, only DSM datasets are generally generated. Most of these datasets have optical digital images as their source data. They are generated at a 2 m resolution using the Polar Stereographic North coordinate system referenced to WGS84 horizontal datum or UTM NAD83 (CSRS) coordinate system. Each dataset covers an area of 50 km by 50 km. For some locations in the north, DSM and DTM datasets can also be generated from airborne LiDAR data. In this case, these products will be generated with the same specifications as those generated from airborne LiDAR in the southern part of the country. The HRDEM product is referenced to the Canadian Geodetic Vertical Datum of 2013 (CGVD2013), which is now the reference standard for heights across Canada. Source data for HRDEM datasets is acquired through multiple projects with different partners. Since data is being acquired by project, there is no integration or edgematching done between projects. The tiles are aligned within each project. The product High Resolution Digital Elevation Model (HRDEM) is part of the CanElevation Series created in support to the National Elevation Data Strategy implemented by NRCan. Collaboration is a key factor to the success of the National Elevation Data Strategy. Refer to the “Supporting Document” section to access the list of the different partners including links to their respective data.

Reason for Selection Protected 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.0 national 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

There are two types of boundary files: cartographic and digital. Cartographic boundary files portray the geographic areas using only the major land mass of Canada and its coastal islands. Digital boundary files portray the full extent of the geographic areas, including the coastal water area.

Queensland's spatial cadastre datasets are changing! From a planned date of 1 July 2025 the current Digital Cadastral Database (DCDB) will be migrated to an entirely new operating environment, and there will be some changes to the data provided. Visit our Spatial Applications Support page (https://spatial-qld-support.atlassian.net/wiki/spaces/QSUITE/pages/1067515932/Cadastre+and+Address+Modernisation+CAM) for more information.The Digital Cadastre is the spatial representation of every current parcel of land in Queensland, and its legal Lot on Plan description and relevant attributes. It provides the map base for systems dealing with land-related information. The Digital Cadastre is considered to be the point of truth for the graphical representation of property boundaries. It is not the point of truth for the legal property boundary or related attribute information, this will always be the plan of survey or the related titling information and administrative data sets. This data is updated weekly on Sunday.Data dictionary https://www.publications.qld.gov.au/dataset/queensland-digital-cadastral-database-supporting-documents/resource/b59bb1a1-3818-4754-8dc4-3669f0ec3f8b Spatial cadastre accuracy map https://www.publications.qld.gov.au/dataset/queensland-digital-cadastral-database-supporting-documents/resource/d6f029ad-b3a4-428b-bcf1-2f7c7326132b

Reason for SelectionProtected natural areas in urban environments provide urban residents a nearby place to connect with nature and offer refugia for some species. Because beaches in Puerto Rico and the U.S. Virgin Islands are open to the public, beaches also provide important outdoor recreation opportunities for urban residents, so we include beaches as parks in this indicator.Input DataSoutheast Blueprint 2023 subregions: CaribbeanSoutheast Blueprint 2023 extentNational Oceanic and Atmospheric Administration (NOAA) National Centers for Environmental Information (NCEI) Coastal Relief Model, accessed 11-22-2022Protected Areas Database of the United States (PAD-US) 3.0: VI, PR, and Marine Combined Fee EasementPuerto Rico Protected Natural Areas 2018 (December 2018 update): Terrestrial and marine protected areas (PACAT2018_areas_protegidasPR_TERRESTRES_07052019.shp, PACAT2018_areas_protegidasPR_MARINAS_07052019.shp) 2020 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 3-14-2023A polygon from this dataset is considered a park if the “leisure” tag attribute is either “park” or “nature_reserve”, and considered a beach if the value in the “natural” tag attribute is “beach”. OpenStreetMap describes leisure areas as “places people go in their spare time” and natural areas as “a wide variety of physical geography, geological and landcover features”. Data were downloaded in .pbf format and translated ton an ESRI shapefile using R code. OpenStreetMap® is open data, licensed under the Open Data Commons Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF). Additional credit to OSM contributors. Read more on the OSM copyright page. TNC Lands - Public Layer, accessed 3-8-2023U.S. Virgin Islands beaches layer (separate vector layers for St. Croix, St. Thomas, and St. John) provided by Joe Dwyer with Lynker/the NOAA Caribbean Climate Adaptation Program on 3-3-2023 (contact jdwyer@lynker.com for more information)Mapping StepsMost mapping steps were completed using QGIS (v 3.22) Graphical Modeler.Fix geometry errors in the PAD-US PR data using Fix Geometry. This must be done before any analysis is possible.Merge the terrestrial PR and VI PAD-US layers.Use the NOAA coastal relief model to restrict marine parks (marine polygons from PAD-US and Puerto Rico Protected Natural Areas) to areas shallower than 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.Merge into one layer the resulting shallow marine parks from marine PAD-US and the Puerto Rico Protected Natural Areas along with the combined terrestrial PAD-US parks, OpenStreetMap, TNC Lands, and USVI beaches. Omit from the Puerto Rico Protected Areas layer the “Zona de Conservación del Carso”, which has some policy protections and conservation incentives but is not formally protected.Fix geometry errors in the resulting merged layer using Fix Geometry.Intersect the resulting fixed file with the Caribbean Blueprint subregion.Process all multipart polygons to single parts (referred to in Arc software as an “explode”). This helps the indicator capture, as much as possible, the discrete units of a protected area that serve urban residents.Clip the Census urban area to the Caribbean Blueprint subregion.Select all polygons that intersect the Census urban extent within 1.2 miles (1,931 m). The 1.2 mi threshold is consistent with the average walking trip on a summer day (U.S. DOT 2002) used to define the walking distance threshold used in the greenways and trails indicator. Note: this is further than the 0.5 mi distance used in the continental version of the indicator. We extended it to capture East Bay and Point Udall based on feedback from the local conservation community about the importance of the park for outdoor recreation.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 to join the parks to their buffers.Create a 1.2 mi (1,931 m) buffer ring around each park using the multiring buffer plugin in QGIS. Ensure that “dissolve buffers” is disabled so that a single 1.2 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. This step creates a table that is joined back to the park polygons using the UniqueID.Remove parks that had ≤2% 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: In the continental version of this indicator, we used a threshold of 10%. In the Caribbean version, we lowered this to 2% in order to capture small parks that dropped out of the indicator when we extended the buffer distance to 1.2 miles.Calculate the GIS acres of each remaining park unit using the Add Geometry Attributes function.Join the buffer attribute table to the previously selected parks, retaining only the parks that exceeded the 2% urban area overlap threshold while buffered. Buffer the selected parks by 15 m. Buffering prevents very small parks and narrow beaches from being left out of the indicator when the polygons are converted to raster.Reclassify the polygons into 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).Export the final vector file to a shapefile and import to ArcGIS Pro.Convert the resulting polygons to raster using the ArcPy Polygon to Raster function. Assign values to the pixels in the resulting raster based on the polygon class sizes of the contiguous park areas.Clip to the Caribbean Blueprint 2023 subregion.As a final step, clip to the spatial extent of Southeast Blueprint 2023. Note: For more details on the mapping steps, code used to create this layer is available in the Southeast Blueprint Data Download under > 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 <10 acre urban park1 = <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.This indicator includes parks and beaches from OpenStreetMap, which is a crowdsourced dataset. While members of the OpenStreetMap community often verify map features to check for accuracy and completeness, there is the potential for spatial errors (e.g., misrepresenting the boundary of a park) or incorrect tags (e.g., labelling an area as a park that is not actually a park). However, using a crowdsourced dataset gives on-the-ground experts, Blueprint users, and community members the power to fix errors and add new parks to improve the accuracy and coverage of this indicator in the future.Other Things to Keep in MindThis indicator calculates the area of each park using the park polygons from the source data. However, simply converting those park polygons to raster results in some small parks and narrow beaches being left out of the indicator. To capture those areas, we buffered parks and beaches by 15 m and applied the original area calculation to the larger buffered polygon, so as not to inflate the area by including the buffer. As a result, when the buffered polygons are rasterized, the final indicator has some areas of adjacent pixels that receive different scores. While these pixels may appear to be part of one contiguous park or suite of parks, they are scored differently because the park polygons themselves are not actually contiguous. The Caribbean version of this indicator uses a slightly different methodology than the continental Southeast version. It includes parks within a 1.2 mi distance from the Census urban area, compared to 0.5 mi in the continental Southeast. We extended it to capture East Bay and Point Udall based on feedback from the local conservation community about the importance of the park for outdoor recreation. Similarly, this indicator uses a 2% threshold of overlap between buffered parks and the Census urban areas, compared to a 10% threshold in the continental Southeast. This helped capture small parks that dropped out of the indicator when we extended the buffer distance to 1.2 miles. Finally, the Caribbean version does not use the impervious surface cutoff applied in the continental Southeast because the landcover data available in the Caribbean does not assess percent impervious in a comparable way.Disclaimer: Comparing with Older Indicator VersionsThere are numerous problems with using Southeast Blueprint