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

The dataset and the validation are fully described in a Nature Scientific Data Descriptor https://www.nature.com/articles/s41597-019-0265-5

If you want to use this dataset in an interactive environment, then use this link https://mybinder.org/v2/gh/GeographerAtLarge/TravelTime/HEAD

The following text is a summary of the information in the above Data Descriptor.

The dataset is a suite of global travel-time accessibility indicators for the year 2015, at approximately one-kilometre spatial resolution for the entire globe. The indicators show an estimated (and validated), land-based travel time to the nearest city and nearest port for a range of city and port sizes.

The datasets are in GeoTIFF format and are suitable for use in Geographic Information Systems and statistical packages for mapping access to cities and ports and for spatial and statistical analysis of the inequalities in access by different segments of the population.

These maps represent a unique global representation of physical access to essential services offered by cities and ports.

The datasets travel_time_to_cities_x.tif (where x has values from 1 to 12) The value of each pixel is the estimated travel time in minutes to the nearest urban area in 2015. There are 12 data layers based on different sets of urban areas, defined by their population in year 2015 (see PDF report).

travel_time_to_ports_x (x ranges from 1 to 5)

The value of each pixel is the estimated travel time to the nearest port in 2015. There are 5 data layers based on different port sizes.

Format Raster Dataset, GeoTIFF, LZW compressed Unit Minutes

Data type Byte (16 bit Unsigned Integer)

No data value 65535

Flags None

Spatial resolution 30 arc seconds

Spatial extent

Upper left -180, 85

Lower left -180, -60 Upper right 180, 85 Lower right 180, -60 Spatial Reference System (SRS) EPSG:4326 - WGS84 - Geographic Coordinate System (lat/long)

Temporal resolution 2015

Temporal extent Updates may follow for future years, but these are dependent on the availability of updated inputs on travel times and city locations and populations.

Methodology Travel time to the nearest city or port was estimated using an accumulated cost function (accCost) in the gdistance R package (van Etten, 2018). This function requires two input datasets: (i) a set of locations to estimate travel time to and (ii) a transition matrix that represents the cost or time to travel across a surface.

The set of locations were based on populated urban areas in the 2016 version of the Joint Research Centre’s Global Human Settlement Layers (GHSL) datasets (Pesaresi and Freire, 2016) that represent low density (LDC) urban clusters and high density (HDC) urban areas (https://ghsl.jrc.ec.europa.eu/datasets.php). These urban areas were represented by points, spaced at 1km distance around the perimeter of each urban area.

Marine ports were extracted from the 26th edition of the World Port Index (NGA, 2017) which contains the location and physical characteristics of approximately 3,700 major ports and terminals. Ports are represented as single points

The transition matrix was based on the friction surface (https://map.ox.ac.uk/research-project/accessibility_to_cities) from the 2015 global accessibility map (Weiss et al, 2018).

Code The R code used to generate the 12 travel time maps is included in the zip file that can be downloaded with these data layers. The processing zones are also available.

Validation The underlying friction surface was validated by comparing travel times between 47,893 pairs of locations against journey times from a Google API. Our estimated journey times were generally shorter than those from the Google API. Across the tiles, the median journey time from our estimates was 88 minutes within an interquartile range of 48 to 143 minutes while the median journey time estimated by the Google API was 106 minutes within an interquartile range of 61 to 167 minutes. Across all tiles, the differences were skewed to the left and our travel time estimates were shorter than those reported by the Google API in 72% of the tiles. The median difference was −13.7 minutes within an interquartile range of −35.5 to 2.0 minutes while the absolute difference was 30 minutes or less for 60% of the tiles and 60 minutes or less for 80% of the tiles. The median percentage difference was −16.9% within an interquartile range of −30.6% to 2.7% while the absolute percentage difference was 20% or less in 43% of the tiles and 40% or less in 80% of the tiles.

This process and results are included in the validation zip file.

Usage Notes The accessibility layers can be visualised and analysed in many Geographic Information Systems or remote sensing software such as QGIS, GRASS, ENVI, ERDAS or ArcMap, and also by statistical and modelling packages such as R or MATLAB. They can also be used in cloud-based tools for geospatial analysis such as Google Earth Engine.

The nine layers represent travel times to human settlements of different population ranges. Two or more layers can be combined into one layer by recording the minimum pixel value across the layers. For example, a map of travel time to the nearest settlement of 5,000 to 50,000 people could be generated by taking the minimum of the three layers that represent the travel time to settlements with populations between 5,000 and 10,000, 10,000 and 20,000 and, 20,000 and 50,000 people.

The accessibility layers also permit user-defined hierarchies that go beyond computing the minimum pixel value across layers. A user-defined complete hierarchy can be generated when the union of all categories adds up to the global population, and the intersection of any two categories is empty. Everything else is up to the user in terms of logical consistency with the problem at hand.

The accessibility layers are relative measures of the ease of access from a given location to the nearest target. While the validation demonstrates that they do correspond to typical journey times, they cannot be taken to represent actual travel times. Errors in the friction surface will be accumulated as part of the accumulative cost function and it is likely that locations that are further away from targets will have greater a divergence from a plausible travel time than those that are closer to the targets. Care should be taken when referring to travel time to the larger cities when the locations of interest are extremely remote, although they will still be plausible representations of relative accessibility. Furthermore, a key assumption of the model is that all journeys will use the fastest mode of transport and take the shortest path.

This dataset contains both large (A0) printable maps of the Torres Strait broken into six overlapping regions, based on a clear sky, clear water composite Sentinel 2 composite imagery and the imagery used to create these maps. These maps show satellite imagery of the region, overlaid with reef and island boundaries and names. Not all features are named, just the more prominent features. This also includes a vector map of Ashmore Reef and Boot Reef in Coral Sea as these were used in the same discussions that these maps were developed for. The map of Ashmore Reef includes the atoll platform, reef boundaries and depth polygons for 5 m and 10 m. This dataset contains all working files used in the development of these maps. This includes all a copy of all the source datasets and all derived satellite image tiles and QGIS files used to create the maps. This includes cloud free Sentinel 2 composite imagery of the Torres Strait region with alpha blended edges to allow the creation of a smooth high resolution basemap of the region. The base imagery is similar to the older base imagery dataset: Torres Strait clear sky, clear water Landsat 5 satellite composite (NERP TE 13.1 eAtlas, AIMS, source: NASA). Most of the imagery in the composite imagery from 2017 - 2021. Method: The Sentinel 2 basemap was produced by processing imagery from the World_AIMS_Marine-satellite-imagery dataset (01-data/World_AIMS_Marine-satellite-imagery in the data download) for the Torres Strait region. The TrueColour imagery for the scenes covering the mapped area were downloaded. Both the reference 1 imagery (R1) and reference 2 imagery (R2) was copied for processing. R1 imagery contains the lowest noise, most cloud free imagery, while R2 contains the next best set of imagery. Both R1 and R2 are typically composite images from multiple dates. The R2 images were selectively blended using manually created masks with the R1 images. This was done to get the best combination of both images and typically resulted in a reduction in some of the cloud artefacts in the R1 images. The mask creation and previewing of the blending was performed in Photoshop. The created masks were saved in 01-data/R2-R1-masks. To help with the blending of neighbouring images a feathered alpha channel was added to the imagery. The processing of the merging (using the masks) and the creation of the feathered borders on the images was performed using a Python script (src/local/03-merge-R2-R1-images.py) using the Pillow library and GDAL. The neighbouring image blending mask was created by applying a blurring of the original hard image mask. This allowed neighbouring image tiles to merge together. The imagery and reference datasets (reef boundaries, EEZ) were loaded into QGIS for the creation of the printable maps. To optimise the matching of the resulting map slight brightness adjustments were applied to each scene tile to match its neighbours. This was done in the setup of each image in QGIS. This adjustment was imperfect as each tile was made from a different combinations of days (to remove clouds) resulting in each scene having a different tonal gradients across the scene then its neighbours. Additionally Sentinel 2 has slight stripes (at 13 degrees off the vertical) due to the swath of each sensor having a slight sensitivity difference. This effect was uncorrected in this imagery.
Single merged composite GeoTiff: The image tiles with alpha blended edges work well in QGIS, but not in ArcGIS Pro. To allow this imagery to be used across tools that don't support the alpha blending we merged and flattened the tiles into a single large GeoTiff with no alpha channel. This was done by rendering the map created in QGIS into a single large image. This was done in multiple steps to make the process manageable.
The rendered map was cut into twenty 1 x 1 degree georeferenced PNG images using the Atlas feature of QGIS. This process baked in the alpha blending across neighbouring Sentinel 2 scenes. The PNG images were then merged back into a large GeoTiff image using GDAL (via QGIS), removing the alpha channel. The brightness of the image was adjusted so that the darkest pixels in the image were 1, saving the value 0 for nodata masking and the boundary was clipped, using a polygon boundary, to trim off the outer feathering. The image was then optimised for performance by using internal tiling and adding overviews. A full breakdown of these steps is provided in the README.md in the 'Browse and download all data files' link. The merged final image is available in export\TS_AIMS_Torres Strait-Sentinel-2_Composite.tif. Source datasets: Complete Great Barrier Reef (GBR) Island and Reef Feature boundaries including Torres Strait Version 1b (NESP TWQ 3.13, AIMS, TSRA, GBRMPA), https://eatlas.org.au/data/uuid/d2396b2c-68d4-4f4b-aab0-52f7bc4a81f5 Geoscience Australia (2014b), Seas and Submerged Lands Act 1973 - Australian Maritime Boundaries 2014a - Geodatabase [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, https://dx.doi.org/10.4225/25/5539DFE87D895 Basemap/AU_GA_AMB_2014a/Exclusive_Economic_Zone_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014a). The Geodatabase was loaded in ArcMap. The Exclusive_Economic_Zone_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data. Geoscience Australia (2014a), Treaties - Australian Maritime Boundaries (AMB) 2014a [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, http://dx.doi.org/10.4225/25/5539E01878302 Basemap/AU_GA_Treaties-AMB_2014a/Papua_New_Guinea_TSPZ_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014b). The Geodatabase was loaded in ArcMap. The Papua_New_Guinea_TSPZ_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data. AIMS Coral Sea Features (2022) - DRAFT This is a draft version of this dataset. The region for Ashmore and Boot reef was checked. The attributes in these datasets haven't been cleaned up. Note these files should not be considered finalised and are only suitable for maps around Ashmore Reef. Please source an updated version of this dataset for any other purpose. CS_AIMS_Coral-Sea-Features/CS_Names/Names.shp CS_AIMS_Coral-Sea-Features/CS_Platform_adj/CS_Platform.shp CS_AIMS_Coral-Sea-Features/CS_Reef_Boundaries_adj/CS_Reef_Boundaries.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth5m_Coral-Sea.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth10m_Coral-Sea.shp Murray Island 20 Sept 2011 15cm SISP aerial imagery, Queensland Spatial Imagery Services Program, Department of Resources, Queensland This is the high resolution imagery used to create the map of Mer. World_AIMS_Marine-satellite-imagery The base image composites used in this dataset were based on an early version of Lawrey, E., Hammerton, M. (2024). Marine satellite imagery test collections (AIMS) [Data set]. eAtlas. https://doi.org/10.26274/zq26-a956. A snapshot of the code at the time this dataset was developed is made available in the 01-data/World_AIMS_Marine-satellite-imagery folder of the download of this dataset. Data Location: This dataset is filed in the eAtlas enduring data repository at: data\custodian\2020-2029-AIMS\TS_AIMS_Torres-Strait-Sentinel-2-regional-maps. On the eAtlas server it is stored at eAtlas GeoServer\data\2020-2029-AIMS. Change Log: 2025-05-12: Eric Lawrey Added Torres-Strait-Region-Map-Masig-Ugar-Erub-45k-A0 and Torres-Strait-Eastern-Region-Map-Landscape-A0. These maps have a brighten satellite imagery to allow easier reading of writing on the maps. They also include markers for geo-referencing the maps for digitisation. 2025-02-04: Eric Lawrey Fixed up the reference to the World_AIMS_Marine-satellite-imagery dataset, clarifying where the source that was used in this dataset. Added ORCID and RORs to the record. 2023-11-22: Eric Lawrey Added the data and maps for close up of Mer. - 01-data/TS_DNRM_Mer-aerial-imagery/ - preview/Torres-Strait-Mer-Map-Landscape-A0.jpeg - exports/Torres-Strait-Mer-Map-Landscape-A0.pdf Updated 02-Torres-Strait-regional-maps.qgz to include the layout for the new map. 2023-03-02: Eric Lawrey Created a merged version of the satellite imagery, with no alpha blending so that it can be used in ArcGIS Pro. It is now a single large GeoTiff image. The Google Earth Engine source code for the World_AIMS_Marine-satellite-imagery was included to improve the reproducibility and provenance of the dataset, along with a calculation of the distribution of image dates that went into the final composite image. A WMS service for the imagery was also setup and linked to from the metadata. A cross reference to the older Torres Strait clear sky clear water Landsat composite imagery was also added to the record.

This dataset shows the results of mapping the connectivity of key values (natural heritage, indigenous heritage, social and historic and economic) of the Great Barrier Reef with its neighbouring regions (Torres Strait, Coral Sea and Great Sandy Strait). The purpose of this mapping process was to identify values that need joint management across multiple regions. It contains a spreadsheet containing the connection information obtained from expert elicitation, all maps derived from this information and all GIS files needed to recreate these maps. This dataset contains the connection strength for 59 attributes of the values between 7 regions (GBR Far Northern, GBR Cairns-Cooktown, GBR Whitsunday-Townsville, GBR Mackay-Capricorn, Torres Strait, Coral Sea and Great Sandy Strait) based on expert opinion. Each connection is assessed based on its strength, mechanism and confidence. Where a connection was known to not exist between two regions then this was also explicitly recorded. A video tutorial on this dataset and its maps is available from https://vimeo.com/335053846.

Methods:

The information for the connectivity maps was gathered from experts (~30) during a 3-day workshop in August 2017. Experts were provided with a template containing a map of Queensland and the neighbouring seas, with an overlay of the regions of interest to assess the connectivity. These were Torres Strait, GBR:Far North Queensland, GBR:Cairns to Cooktown, GBC: Townsville to Whitsundays, GBR: Mackay to Capricorn Bunkers and Great Sandy Strait (which includes Hervey bay). A range of reference maps showing locations of the values were provided, where this information could be obtained. As well as the map the template provided 7x7 table for filling in the connectivity strength and connection type between all combinations of these regions. The experts self-organised into groups to discuss and complete the template for each attribute to be mapped. Each expert was asked to estimate the strength of connection between each region as well as the connection mechanism and their confidence in the information. Due to the limited workshop time the experts were asked to focus on initially recording the connections between the GBR and its neighbouring regions and not to worry about the internal connections in the GBR, or long-distance connections along the Queensland coast. In the second half of the workshop the experts were asked to review the maps created and expand on the connections to include those internal to the GBR. After the workshop an initial set of maps were produced and reviewed by the project team and a range of issues were identified and resolved. Additional connectivity maps for some attributes were prepared after the workshop by the subject experts within the project team. The data gathered from these templates was translated into a spreadsheet, then processing into the graphic maps using QGIS to present the connectivity information. The following are the value attributes where their connectivity was mapped: Seagrass meadows: pan-regional species (e.g. Halophila spp. and Halodule spp.) Seagrass meadows: tropical/sub-tropical (Cymodocea serrulata, Syringodium isoetifolium) Seagrass meadows: tropical (Thalassia, Cymodocea, Thalassodendron, Enhalus, Rotundata) Seagrass meadows: Zostera muelleri Mangroves & saltmarsh Hard corals Crustose coralline algae Macroalgae Crown of thorns starfish larval flow Acropora larval flow Casuarina equisetifolia & Pandanus tectorius Argusia argentia Pisonia grandis: cay vegetation Inter-reef gardens (sponges + gorgonians) (Incomplete) Halimeda Upwellings Pelagic foraging seabirds Inshore and offshore foraging seabirds Migratory shorebirds Ornate rock lobster Yellowfin tuna Black marlin Spanish mackerel Tiger shark Grey nurse shark Humpback whales Dugongs Green turtles Hawksbill turtles Loggerhead turtles Flatback turtles Longfin & Shortfin Eels Red-spot king prawn Brown tiger prawn Eastern king prawns Great White Shark Sandfish (H. scabra) Black teatfish (H. whitmaei) Location of sea country Tangible cultural resources Location of place attachment Location of historic shipwrecks Location of places of social significance Location of commercial fishing activity Location of recreational use Location of tourism destinations Australian blacktip shark (C. tilstoni) Barramundi Common black tip shark (C. limbatus) Dogtooth tuna Grey mackerel Mud crab Coral trout (Plectropomus laevis) Coral trout (Plectropomus leopardus) Red throat emperor Reef manta Saucer scallop (Ylistrum balloti) Bull shark Grey reef shark

Limitations of the data:

The connectivity information in this dataset is only rough in nature, capturing the interconnections between 7 regions. The connectivity data is based on expert elicitation and so is limited by the knowledge of the experts that were available for the workshop. In most cases the experts had sufficient knowledge to create robust maps. There were however some cases where the knowledge of the participants was limited, or the available scientific knowledge on the topic was limited (particularly for the ‘inter-reefal gardens’ attribute) or the exact meaning of the value attribute was poorly understood or could not be agreed up on (particularly for the social and indigenous heritage maps). This information was noted with the maps. These connectivity maps should be considered as an initial assessment of the connections between each of the regions and should not be used as authoritative maps without consulting with additional sources of information. Each of the connectivity links between regions was recorded with a level of confidence, however these were self-reported, and each assessment was performed relatively quickly, with little time for reflection or review of all the available evidence. It is likely that in many cases the experts tended to have a bias to mark links with strong confidence. During subsequent revisions of some maps there were substantial corrections and adjustments even for connections with a strong confidence, indicating that there could be significant errors in the maps where the experts were not available for subsequent revisions. Each of the maps were reviewed by several project team members with broad general knowledge. Not all connection combinations were captured in this process due to the limited expert time available. A focus was made on capturing the connections between the GBR and its neighbouring regions. Where additional time was available the connections within 4 regions in the GBR was also captured. The connectivity maps only show connections between immediately neighbouring regions, not far connections such as between Torres Strait and Great Sandy Strait. In some cases the connection information for longer distances was recorded from the experts but not used in the mapping process. The coastline polygon and the region boundaries in the maps are not spatially accurate. They were simplified to make the maps more diagrammatic. This was done to reduce the chance of misinterpreting the connection arrows on the map as being spatially explicit.

Format:

This dataset is made up of a spreadsheet that contains all the connectivity information recorded from the expert elicitation and all the GIS files needed to recreate the generated maps.

original/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_Master_v2018-09-05.xlsx: ‘Values connectivity’: This sheet contains the raw connectivity codes transcribed from the templates produced prepared by the subject experts. This is the master copy of the connection information. Subsequent sheets in the spreadsheet are derived using formulas from this table. 1-Vertical-data: This is a transformation of the ‘Values connectivity’ sheet so that each source and destination connection is represented as a single row. This also has the connection mechanism codes split into individual columns to allow easier processing in the map generation. This sheet pulls in the spatial information for the arrows on the maps (‘LinkGeom’ attribute) or crosses that represent no connections (‘NoLinkGeom’) using lookup tables from the ‘Arrow-Geom-LUT’ and ‘NoConnection-Geom-LUT’ sheets. 2.Point-extract: This contains all the ‘no connection’ points from the ‘Values connectivity’ dataset. This was saved as working/ GBR_NESP-TWQ-3-3-3_Seascape-connectivity_no-con-pt.csv and used by the QGIS maps to draw all the crosses on the maps. This table is created by copy and pasting (values only) the ‘1-Vertical-data’ sheet when the ‘NoLinkGeom’ attribute is used to filter out all line features, by unchecking blank rows in the ‘NoLinkGeom’ filter. 2.Line-extract: This contains all the ‘connections’ between regions from the ‘Values connectivity’ dataset. This was saved as working/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_arrows.csv and used by the QGIS maps to draw all the arrows on the maps. This table is created by copy and pasting (values only) the ‘1-Vertical-data’ sheet when the ‘LinkGeom’ attribute is used to filter out all point features, by unchecking blank rows in the ‘LinkGeom’ filter. Map-Atlas-Settings: This contains the metadata for each of the maps generated by QGIS. This sheet was exported as working/GBR_NESP-TWQ-3-3-3_Seascape-connectivity_map-atlas-settings.csv and used by QGIS to drive its Atlas feature to generate one map per row of this table. The AttribID is used to enable and disable the appropriate connections on the map being generated. The WKT attribute (Well Known Text) determines the bounding box of the map to be generated and the other attributes are used to display text on the map. map-image-metadata: This table contains metadata descriptions for each of the value attribute maps. This metadata was exported as a CSV and saved into the final generated JPEG maps using the eAtlas Image Metadata Editor Application

Reason for SelectionHardbottom provides an anchor for important seafloor habitats such as deep-sea corals, plants, and sponges. Hardbottom is also sometimes associated with chemosynthetic communities that form around cold seeps or hydrothermal vents. In these unique ecosystems, micro-organisms that convert chemicals into energy form the base of complex food webs (Love et al. 2013). Hardbottom and associated species provide important habitat structure for many fish and invertebrates (NOAA 2018). Hardbottom areas serve as fish nursery, spawning, and foraging grounds, supporting commercially valuable fisheries like snapper and grouper (NCDEQ 2016).According to Dunn and Halpin (2009), “hardbottom habitats support high levels of biodiversity and are frequently used as a surrogate for it in marine spatial planning.” Artificial reefs arealso known to provide additional habitat that is quickly colonized to provide a suite of ecosystem services commonly associated with naturally occurring hardbottom (Wu et al. 2019). We did not include active oil and gas structures as human-created hardbottom. Although they provide habitat, because of their temporary nature, risk of contamination, and contributions to climate change, they do not have the same level of conservation value as other artificial structures.Input DataSoutheast Blueprint 2024 extentSoutheast Blueprint 2024 subregionsCoral & hardbottomusSEABED Gulf of America sediments, accessed 12-14-2023; download the data; view and read more about the data on the National Oceanic and Atmospheric Administration (NOAA) Gulf of Mexico Atlas (select Physical --> Marine geology --> 1. Dominant bottom types and habitats)Bureau of Ocean Energy Management (BOEM) Gulf of America, seismic water bottom anomalies, accessed 12-20-2023The Nature Conservancy’s (TNC)South Atlantic Bight Marine Assessment(SABMA); chapter 3 ofthe final reportprovides more detail on the seafloor habitats analysisNOAA deep-sea coral and sponge locations, accessed 12-20-2023 on theNOAA Deep-Sea Coral & Sponge Map PortalFlorida coral and hardbottom habitats, accessed 12-19-2023Shipwrecks & artificial reefsNOAA wrecks and obstructions layer, accessed 12-12-2023 on theMarine CadastreLouisiana Department of Wildlife and Fisheries (LDWF) Artificial Reefs: Inshore Artificial Reefs, Nearshore Artificial Reefs, Offshore and Deepwater Artificial Reefs (Google Earth/KML files), accessed 12-19-2023Texas Parks and Wildlife Department (TPWD) Artificial Reefs, accessed 12-19-2023; download the data fromThe Artificial Reefs Interactive Mapping Application(direct download from interactive mapping application)Mississippi Department of Marine Resources (MDMR) Artificial Reef Bureau: Inshore Reefs, Offshore Reefs, Rigs to Reef (lat/long coordinates), accessed 12-19-2023Alabama Department of Conservation and Natural Resources (ADCNR) Artificial Reefs: Master Alabama Public Reefs v2023 (.xls), accessed 12-19-2023Florida Fish and Wildlife Conservation Commission (FWC):Artificial Reefs in Florida(.xlsx), accessed 12-19-2023Defining inland extent & split with AtlanticMarine Ecoregions Level III from the Commission for Environmental Cooperation North American Environmental Atlas, accessed 12-8-20212023NOAA 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-2024National Oceanic and Atmospheric Administration (NOAA)Characterizing Spatial Distributions of Deep-sea Corals and Hardbottom Habitats in the U.S. Southeast Atlantic;read the final report; data shared prior to official release on 2-4-2022 by Matt Poti with the NOAA National Centers for Coastal Ocean Science (NCCOS) (matthew.poti@noaa.gov)Predictive Modeling and Mapping of Hardbottom Seafloor Habitats off the Southeast U.S: unpublished NOAA data anddraft final report entitled Assessment of Benthic Habitats for Fisheries Managementprovided on 1-28-2021 by Matt Poti with NOAA NCCOS (matthew.poti@noaa.gov)Mapping StepsNote: Most of the mapping steps were accomplished using the graphical modeler in QGIS 3.34. Individual models were created to combine data sources and assign ranked values. These models were combined in a single model to assemble all the data sources and create a summary raster.Create a seamless vector layer to constrain the extent of the Atlantic coral and hardbottom indicator to marine and estuarine areas <1 m in elevation. This defines how far inland it extends.Merge together all coastal relief model rasters (.nc format) using the create virtual raster tool in QGIS.Save the merged raster to .tif format and import it into ArcPro.Reclassify the NOAA coastal relief model data to assign a value of 1 to areas from deep marine to 1 m elevation. Assign all other areas (land) a value of 0.Convert the raster produced above to vector using the raster to polygon tool.Clip to the 2024 Blueprint subregions using the pairwise clip tool.Hand-edit to remove terrestrial polygons (one large terrestrial polygon and the Delmarva peninsula).Dissolve the resulting data layer to produce a seamless polygon defining marine and estuarine areas <1 m in elevation.Hand-edit to select all but the main marine polygon and delete.Define the extent of the Gulf version of this indicator to separate it from the Atlantic. This split reflects the extent of the different datasets available to represent coral and hardbottom habitat in the Atlantic and Gulf, rather than a meaningful ecological transition.Use the select tool to select the Florida Keys class from the Level III marine ecoregions (“NAME_L3 = "Florida Keys"“).Buffer the “Florida Keys” Level III marine ecoregion by 2 km to extend it far enough inland to intersect the inland edge of the <1 m elevation layer.Reclassify the two NOAA Atlantic hardbottom suitability datasets to give all non-NoData pixels a value of 0. Combine the reclassified hardbottom suitability datasets to define the total extent of these data. Convert the raster extent to vector and dissolve to create a polygon representing the extent of both NOAA hardbottom datasets.Union the buffered ecoregion with the combined NOAA extent polygon created above. Add a field and use it to dissolve the unioned polygons into one polygon. This leaves some holes inside the polygon, so use the eliminate polygon part tool to fill in those holes, then convert the polygon to a line.Hand-edit to extract the resulting line between the Gulf and Atlantic.Hand-edit to use this line to split the <1 m elevation layer created earlier in the mapping steps to create the separation between the Gulf and Atlantic extent.From the BOEM seismic water bottom anomaly data, extract the following shapefiles: anomaly_confirmed_relic_patchreefs.shp, anomaly_Cretaceous.shp, anomaly_relic_patchreefs.shp, seep_anomaly_confirmed_buried_carbonate.shp, seep_anomaly_confirmed_carbonate.shp, seep_anomaly_confirmed_organisms.shp, seep_anomaly_positives.shp, seep_anomaly_positives_confirmed_gas.shp, seep_anomaly_positives_confirmed_oil.shp, seep_anomaly_positives_possible_oil.shp, seep_anomaly_confirmed_corals.shp, seep_anomaly_confirmed_hydrate.shp.To create a class of confirmed BOEM features, merge anomaly_confirmed_relic_patchreefs.shp, seep_anomaly_confirmed_organisms.shp, seep_anomaly_confirmed_corals.shp, and seep_anomaly_confirmed_hydrate.shp and assign a value of 6.To create a class of predicted BOEM features, merge the remaining extracted shapefiles and assign a value of 3.From usSEABED sediments data, use the field “gom_domnc” to extract polygons: rock (dominant and subdominant) receives a value of 2 and gravel (dominant and subdominant) receives a value of 1.From the wrecks database, extract locations having “high” and “medium” confidence (positionQuality = “high” and positionQuality = “medium”). Buffer these locations by 150 m and assign a value of 4. The buffer distance used here, and later for coral locations, follows guidance from the Army Corps of Engineers for setbacks around artificial reefs and fish havens (Riley et al. 2021).Merge artificial reef point locations from FL, AL, MS and TX. Buffer these locations by 150 m. Merge this file with the three LA artificial reef polygons and assign a value of 5.From the NOAA deep-sea coral and sponge point locations, select all points. Buffer the point locations by 150 m and assign a value of 7.From the FWC coral and hardbottom dataset polygon locations, fix geometries, reproject to EPSG=5070, then assign coral reefs a value of 7, hardbottom a value of 6, hardbottom with seagrass a value of 6, and probable hardbottom a value of 3. Hand-edit to remove an erroneous hardbottom polygon off of Matagorda Island, TX, resulting from a mistake by Sheridan and Caldwell (2002) when they digitized a DOI sediment map. This error is documented on page 6 of the Gulf of Mexico Fishery Management Council’s5-Year Review of the Final Generic Amendment Number 3.From the TNC SABMA data, fix geometries and reproject to EPSG=5070, then select all polygons with TEXT_DESC = "01. mapped hard bottom area" and assign a value of 6.Union all of the above vector datasets together—except the vector for class 6 that combines the SABMA and FL data—and assign final indicator values. Class 6 had to be handled separately due to some unexpected GIS processing issues. For overlapping polygons, this value will represent the maximum value at a given location.Clip the unioned polygon dataset to the buffered marine subregions.Convert both the unioned polygon dataset and the separate vector layer for class 6 using GDAL “rasterize”.Fill NoData cells in both rasters with zeroes and, using Extract by Mask, mask the resulting raster with the Gulf indicator extent. Adding zero values helps users better understand the extent of this indicator and to make this indicator layer perform better in online tools.Use the raster calculator to evaluate the maximum value among

Introduction

This travel time matrix records travel times and travel distances for routes between all centroids (N = 13231) of a 250 × 250 m grid over the populated areas in the Helsinki metropolitan area by walking, cycling, public transportation, and private car. If applicable, the routes have been calculated for different times of the day (rush hour, midday, off-peak), and assuming different physical abilities (such as walking and cycling speeds), see details below.

The grid follows the geometric properties and enumeration of the versatile Yhdyskuntarakenteen seurantajärjestelmä (YKR) grid used in applications across many domains in Finland, and covers the municipalities of Helsinki, Espoo, Kauniainen, and Vantaa in the Finnish capital region.

Data formats

The data is available in multiple different formats that cater to different requirements, such as different software environments. All data formats share a common set of columns (see below), and can be used interchangeably.

• `Helsinki_Travel_Time_Matrix_2023.csv.zst`: comma-separated values (CSV) of all data columns, without geometries. This data set contains all routes in one file, and can be filtered by origin or destination according to the analysis at hand. The data records can also be joined to the geometries as available below. The file is compressed using the Zstandard algorithm, that many data science libraries, for instance, pandas, support transparently, directly, and automatically.
• `Helsinki_Travel_Time_Matrix_2023_travel_times.gpkg.zip`: an OGC GeoPackage standard file containing all data columns and the geometries that relate to the destination grid cell. The data set is delivered as a ZIP archive, which many GIS systems and libraries, e.g., GDAL/OGR, QGIS, or geopandas, support natively.
• `Helsinki_Travel_Matrix_2023_travel_times.csv.zip`: a set of 13231 comma-separated value files containing the routes to one destination grid cell each. The files contain all data columns, no geometry, and can be joined to the geometries as available below. Filenames of the individual files within the ZIP archive follow the pattern `Helsinki_Travel_Time_Matrix_2023_travel_times_to_5787545.csv` where `5787545` is replaced by the `to_id` by which the rows in the file are grouped. Use the `from_id` column to join with the geometries from one of the files below.

Geometry, only:

• `Helsinki_Travel_Time_Matrix_2023_grid.gpkg.zip`: an OGC GeoPackage standard file containing the geometries and IDs of the grid used in the analysis. This file can be joined both to the `from_id` and `to_id` columns of the data files. The data set is delivered as a ZIP archive, which many GIS systems and libraries, e.g., GDAL/OGR, QGIS, or geopandas, support natively.
• `Helsinki_Travel_Time_Matrix_2023_grid.shp.zip`: an ESRI Shapefile archive containing the geometries and IDs of the grid used in the analysis. This file can be joined both to the `from_id` and `to_id` columns of the data files.

Table structure

from_id

to_id

walk_avg

walk_slo

bike_avg

bike_fst

bike_slo

pt_r_avg

pt_r_slo

pt_m_avg

pt_m_slo

pt_n_avg

pt_n_slo

car_r

car_m

car_n

walk_d

Data for 2013, 2015, and 2018

At the Digital Geography Lab, we started computing travel time matrices in 2013. Our methodology has changed in between the iterations, and naturally, there are systematic differences between the iterations’ results. Not all input data sets are available to recompute the historical matrices with new methods, however, we were able to repeat the 2018 calculation using the same methods as the 2023 data set, please find the results below, in the same format.

For the travel time matrices for 2013 and 2015, as well as for 2018 using an older methodology, please refer to DOI:10.5281/zenodo.3247563.

Methodology

Computations were carried out for Wednesday, 15 February, 2023, and Monday, 29 January, 2018, respectively. ‘Rush hour’ refers to an 1-hour window between 8 and 9 am, ‘midday’ to 12 noon to 1 pm, and ‘nighttime’ to 2-3 am.

All routes have been calculated using r5py, a Python library making use of the R⁵ engine by Conveyal, with modifications to consider local characteristics of the Helsinki use case and to inform the computation models from local real-world data sets. In particular, we made the following modifications:

Walking

Walking speeds, and in turn walking times, are based on the findings of Willberg et al., 2023, in which we measured walking speeds of people of different age groups in varying road surface conditions in Helsinki. Specifically, we chose to use the average measured walking speed in summer conditions for `walk_avg` (as well as the respective `pt_*_walk_avg`), and the slowest quintile of all measured walker across all conditions for `walk_slo` (and the respective `pt_*_walk_slo`).

Cycling

Cycling speeds are derived from two input data sets. First, we averaged cycling speeds per network segment from Strava data, and computed a ratio between the speed ridden in each segment and the overall average speed. We then use these ratios to compute fast, slow, and average cycling speeds for each segment, based on the mean overall Strava speed, the mean speeds cycled in the Helsinki City Bike bike-share system, and the mean between the two.

Further, in line with the values observed by Jäppinen (2012), we add a flat 30 seconds each for unlocking and locking the bicycle at the origin and destination.

Public Transport

We used public transport schedules in General Transit Feed Specification (GTFS) format published by

AbstractCoastline for Antarctica created from various mapping and remote sensing sources, provided as polygons with ‘land’, ‘ice shelf’, ‘ice tongue’ or ‘rumple’ attribute. Covering all land and ice shelves south of 60°S. Suitable for topographic mapping and analysis. This dataset has been generalised from the high resolution vector polygons. Medium resolution versions of ADD data are suitable for scales smaller than 1:1,000,000, although certain regions will appear more detailed than others due to variable data availability and coastline characteristics.Changes in v7.10 include updates to the coastline of Alexander Island and surrounding islands, and the ice shelf fronts of the Wilkins and Brunt ice shelves.Data compiled, managed and distributed by the Mapping and Geographic Information Centre and the UK Polar Data Centre, British Antarctic Survey on behalf of the Scientific Committee on Antarctic Research.Further information and useful linksMap projection: WGS84 Antarctic Polar Stereographic, EPSG 3031. Note: by default, opening this layer in the Map Viewer will display the data in Web Mercator. To display this layer in its native projection use an Antarctic basemap.The currency of this dataset is November 2024 and will be reviewed every 6 months. This feature layer will always reflect the most recent version.For more information on, and access to other Antarctic Digital Database (ADD) datasets, refer to the SCAR ADD data catalogue.A related high resolution dataset is also published via Living Atlas, as well medium and high resolution line datasets.For background information on the ADD project, please see the British Antarctic Survey ADD project page.LineageDataset compiled from a variety of Antarctic map and satellite image sources. The dataset was created using ArcGIS and QGIS GIS software programmes and has been checked for basic topography and geometry checks, but does not contain strict topology. Quality varies across the dataset and certain areas where high resolution source data were available are suitable for large scale maps whereas other areas are only suitable for smaller scales. Each polygon contains a ‘surface’ attribute with either ‘land’, ‘ice shelf’, ‘ice tongue’ or ‘rumple’. Details of when and how each line was created can be found in the attributes of the high or medium resolution polyline coastline dataset. Data sources range in time from 1990s-2024 - individual lines contain exact source dates. This medium resolution version has been generalised from the high resolution version. All polygons <0.1km² not intersecting anything else were deleted and the ‘simplify’ tool was used in ArcGIS with the ‘retain critical points’ algorithm and a smoothing tolerance of 50 m.CitationGerrish, L., Ireland, L., Fretwell, P., & Cooper, P. (2024). Medium resolution vector polygons of the Antarctic coastline (Version 7.10) [Data set]. NERC EDS UK Polar Data Centre. https://doi.org/10.5285/93ac35af-9ec7-4594-9aaa-0760a2b289d5If using for a graphic or if short on space, please cite as 'data from the SCAR Antarctic Digital Database, 2024'

Summary:

The files contained herein represent green roof footprints in NYC visible in 2016 high-resolution orthoimagery of NYC (described at https://github.com/CityOfNewYork/nyc-geo-metadata/blob/master/Metadata/Metadata_AerialImagery.md). Previously documented green roofs were aggregated in 2016 from multiple data sources including from NYC Department of Parks and Recreation and the NYC Department of Environmental Protection, greenroofs.com, and greenhomenyc.org. Footprints of the green roof surfaces were manually digitized based on the 2016 imagery, and a sample of other roof types were digitized to create a set of training data for classification of the imagery. A Mahalanobis distance classifier was employed in Google Earth Engine, and results were manually corrected, removing non-green roofs that were classified and adjusting shape/outlines of the classified green roofs to remove significant errors based on visual inspection with imagery across multiple time points. Ultimately, these initial data represent an estimate of where green roofs existed as of the imagery used, in 2016.

These data are associated with an existing GitHub Repository, https://github.com/tnc-ny-science/NYC_GreenRoofMapping, and as needed and appropriate pending future work, versioned updates will be released here.

Terms of Use:

The Nature Conservancy and co-authors of this work shall not be held liable for improper or incorrect use of the data described and/or contained herein. Any sale, distribution, loan, or offering for use of these digital data, in whole or in part, is prohibited without the approval of The Nature Conservancy and co-authors. The use of these data to produce other GIS products and services with the intent to sell for a profit is prohibited without the written consent of The Nature Conservancy and co-authors. All parties receiving these data must be informed of these restrictions. Authors of this work shall be acknowledged as data contributors to any reports or other products derived from these data.

Associated Files:

As of this release, the specific files included here are:

• GreenRoofData2016_20180917.geojson is in the human-readable, GeoJSON format, in geographic coordinates (Lat/Long, WGS84; EPSG 4263).
• GreenRoofData2016_20180917.gpkg is in the GeoPackage format, which is an Open Standard readable by most GIS software including Esri products (tested on ArcMap 10.3.1 and multiple versions of QGIS). This dataset is in the New York State Plan Coordinate System (units in feet) for the Long Island Zone, North American Datum 1983, EPSG 2263.
• GreenRoofData2016_20180917_Shapefile.zip is a zipped folder containing a Shapefile and associated files. Please note that some field names were truncated due to limitations of Shapefiles, but columns are in the same order as for other files and in the same order as listed below. This dataset is in the New York State Plan Coordinate System (units in feet) for the Long Island Zone, North American Datum 1983, EPSG 2263.
• GreenRoofData2016_20180917.csv is a comma-separated values file (CSV) with coordinates for centroids for the green roofs stored in the table itself. This allows for easily opening the data in a tool like spreadsheet software (e.g., Microsoft Excel) or a text editor.

Column Information for the datasets:

Some, but not all fields were joined to the green roof footprint data based on building footprint and tax lot data; those datasets are embedded as hyperlinks below.

• fid - Unique identifier
• bin - NYC Building ID Number based on overlap between green roof areas and a building footprint dataset for NYC from August, 2017. (Newer building footprint datasets do not have linkages to the tax lot identifier (bbl), thus this older dataset was used). The most current building footprint dataset should be available at: https://data.cityofnewyork.us/Housing-Development/Building-Footprints/nqwf-w8eh. Associated metadata for fields from that dataset are available at https://github.com/CityOfNewYork/nyc-geo-metadata/blob/master/Metadata/Metadata_BuildingFootprints.md.
• bbl - Boro Block and Lot number as a single string. This field is a tax lot identifier for NYC, which can be tied to the Digital Tax Map (http://gis.nyc.gov/taxmap/map.htm) and PLUTO/MapPLUTO (https://www1.nyc.gov/site/planning/data-maps/open-data/dwn-pluto-mappluto.page). Metadata for fields pulled from PLUTO/MapPLUTO can be found in the PLUTO Data Dictionary found on the aforementioned page. All joins to this bbl were based on MapPLUTO version 18v1.
• gr_area - Total area of the footprint of the green roof as per this data layer, in square feet, calculated using the projected coordinate system (EPSG 2263).
• bldg_area - Total area of the footprint of the associated building, in square feet, calculated using the projected coordinate system (EPSG 2263).
• prop_gr - Proportion of the building covered by green roof according to this layer (gr_area/bldg_area).
• cnstrct_yr - Year the building was constructed, pulled from the Building Footprint data.
• doitt_id - An identifier for the building assigned by the NYC Dept. of Information Technology and Telecommunications, pulled from the Building Footprint Data.
• heightroof - Height of the roof of the associated building, pulled from the Building Footprint Data.
• feat_code - Code describing the type of building, pulled from the Building Footprint Data.
• groundelev - Lowest elevation at the building level, pulled from the Building Footprint Data.
• qa - Flag indicating a positive QA/QC check (using multiple types of imagery); all data in this dataset should have 'Good'
• notes - Any notes about the green roof taken during visual inspection of imagery; for example, it was noted if the green roof appeared to be missing in newer imagery, or if there were parts of the roof for which it was unclear whether there was green roof area or potted plants.
• classified - Flag indicating whether the green roof was detected image classification. (1 for yes, 0 for no)
• digitized - Flag indicating whether the green roof was digitized prior to image classification and used as training data. (1 for yes, 0 for no)
• newlyadded - Flag indicating whether the green roof was detected solely by visual inspection after the image classification and added. (1 for yes, 0 for no)
• original_source - Indication of what the original data source was, whether a specific website, agency such as NYC Dept. of Parks and Recreation (DPR), or NYC Dept. of Environmental Protection (DEP). Multiple sources are separated by a slash.
• address - Address based on MapPLUTO, joined to the dataset based on bbl.
• borough - Borough abbreviation pulled from MapPLUTO.
• ownertype - Owner type field pulled from MapPLUTO.
• zonedist1 - Zoning District 1 type pulled from MapPLUTO.
• spdist1 - Special District 1 pulled from MapPLUTO.
• bbl_fixed - Flag to indicate whether bbl was manually fixed. Since tax lot data may have changed slightly since the release of the building footprint data used in this work, a small percentage of bbl codes had to be manually updated based on overlay between the green roof footprint and the MapPLUTO data, when no join was feasible based on the bbl code from the building footprint data. (1 for yes, 0 for no)

For GreenRoofData2016_20180917.csv there are two additional columns, representing the coordinates of centroids in geographic coordinates (Lat/Long, WGS84; EPSG 4263):

• xcoord - Longitude in decimal degrees.
• ycoord - Latitude in decimal degrees.

Acknowledgements:

This work was primarily supported through funding from the J.M. Kaplan Fund, awarded to the New York City Program of The Nature Conservancy, with additional support from the New York Community Trust, through New York City Audubon and the Green Roof Researchers Alliance.

This dataset contains open vector data for railways, forests and power lines, as well an open digital elevation model (DEM) for a small area around a sample forest range in Europe (Germany, Upper Bavaria, Kochel Forest Range, some 70 km south of München, at the edge of Bavarian Alps). The purpose of this dataset is to provide a documented sample dataset in order to demonstrate geospatial preprocessing at FOSS4G2019 based on open data and software. This sample has been produced based on several existing open data sources (detailed below), therefore documenting the sources for obtaining some data needed for computations related to forest accessibility and wood harvesting. For example, they can be used with the open methodology and QGIS plugin Seilaplan for optimising the geometric layout cable roads or with additional open software for computing the forest accessibility for wood harvesting. The vector data (railways, forests and power lines) was extracted from OpenStreetMap (data copyrighted OpenStreetMap contributors and available from https://www.openstreetmap.org). The railways and forests were downloaded and extracted on 18.05.2019 using the open sources QGIS (https://www.qgis.org) with the QuickOSM plugin, while the power lines were downloaded a couple of days later on 23.05.2019. Additional notes for vector data: Please note that OpenStreeMap data extracts such as forests, roads and railways (except power lines) can also be downloaded in a GIS friendly format (Shapefile) from http://download.geofabrik.de/ or using the QGIS built-in download function for OpenStreetMap data. The most efficient way to retrieve specific OSM tags (such as power=line) is to use the QuickOSM plugin for QGIS (using the Overpass API - https://wiki.openstreetmap.org/wiki/Overpass_API) or directly using overpass turbo (https://overpass-turbo.eu/). Finally, the digitised perimeter of the sample forest range is also made available for reproducibility purposes, although any perimeter or area can be digitised freely using the QGIS editing toolbar. The DEM was originally adapted and modified also with QGIS (https://www.qgis.org) based on the elevation data available from two different sources, by reprojecting and downsampling datasets to 25m then selecting, for each individual raster cell, the elevation value that was closer to the average. These two different elevation sources are: - Copernicus Land Monitoring Service - EU-DEM v.1.1 (TILE ID E40N20, downloaded from https://land.copernicus.eu/imagery-in-situ/eu-dem/eu-dem-v1.1; this original DEM was produced by the Copernicus Land Monitoring Service “with funding by the European Union” based on SRTM and ASTER GDEM) - Digitales Geländemodell 50 m Gitterweite (https://opendata.bayern.de/detailansicht/datensatz/digitales-gelaendemodell-50-m-gitterweite/), produced by the Bayerische Vermessungsverwaltung – www.geodaten.bayern.de –and downloaded from http://www.geodaten.bayern.de/opendata/DGM50/dgm50_epsg4258.tif This methodology was chosen as a way of performing a basic quality check, by comparing the EU-DEM v.1.1 derived from globally available DEM data (such as SRTM) with more authoritative data for the randomly selected region, since using authoritative data is preferred (if open and available). For other sample regions, where authoritative open data is not available, such comparisons cannot longer be performed. Additional notes DEM: a very good DEM open data source for Germany is the open data set collected and resampled by Sonny (sonnyy7@gmail.com) and made available on the Austrian Open Data Portal http://data.opendataportal.at/dataset/dtm-germany. In order to simplify end-to-end reproducibility of the paper planned for FOSS4G2019, we use and distribute an adapted (reprojected and resampled to 25 meters) sample of the above mentioned dataset for the selected forest range. This sample dataset is accompanied by software in Python, as a Jupiter Notebook that generates harmonized output rasters with the same extent from the input data. The extent is given by the polygon vector dataset (Perimeter). These output rasters, such as obstacles, aspect, slope, forest cover, can serve as input data for later computations related to forest accessibility and wood harvesting questions. The obstacles output is obtained by transforming line vector datasets (railway lines, high voltage power lines) to raster. Aspect and slope are both derived from the sample digital elevation model.

This layer contains the relative heat severity for every pixel for every city in the United States. This 30-meter raster was derived from Landsat 8 imagery band 10 (ground-level thermal sensor) from the summers of 2019 and 2020.Federal statistics over a 30-year period show extreme heat is the leading cause of weather-related deaths in the United States. Extreme heat exacerbated by urban heat islands can lead to increased respiratory difficulties, heat exhaustion, and heat stroke. These heat impacts significantly affect the most vulnerable—children, the elderly, and those with preexisting conditions.The purpose of this layer is to show where certain areas of cities are hotter than the average temperature for that same city as a whole. Severity is measured on a scale of 1 to 5, with 1 being a relatively mild heat area (slightly above the mean for the city), and 5 being a severe heat area (significantly above the mean for the city). The absolute heat above mean values are classified into these 5 classes using the Jenks Natural Breaks classification method, which seeks to reduce the variance within classes and maximize the variance between classes. Knowing where areas of high heat are located can help a city government plan for mitigation strategies.This dataset represents a snapshot in time. It will be updated yearly, but is static between updates. It does not take into account changes in heat during a single day, for example, from building shadows moving. The thermal readings detected by the Landsat 8 sensor are surface-level, whether that surface is the ground or the top of a building. Although there is strong correlation between surface temperature and air temperature, they are not the same. We believe that this is useful at the national level, and for cities that don’t have the ability to conduct their own hyper local temperature survey. Where local data is available, it may be more accurate than this dataset. Dataset SummaryThis dataset was developed using proprietary Python code developed at The Trust for Public Land, running on the Descartes Labs platform through the Descartes Labs API for Python. The Descartes Labs platform allows for extremely fast retrieval and processing of imagery, which makes it possible to produce heat island data for all cities in the United States in a relatively short amount of time.What can you do with this layer?This layer has query, identify, and export image services available. Since it is served as an image service, it is not necessary to download the data; the service itself is data that can be used directly in any Esri geoprocessing tool that accepts raster data as input.In order to click on the image service and see the raw pixel values in a map viewer, you must be signed in to ArcGIS Online, then Enable Pop-Ups and Configure Pop-Ups.Using the Urban Heat Island (UHI) Image ServicesThe data is made available as an image service. There is a processing template applied that supplies the yellow-to-red or blue-to-red color ramp, but once this processing template is removed (you can do this in ArcGIS Pro or ArcGIS Desktop, or in QGIS), the actual data values come through the service and can be used directly in a geoprocessing tool (for example, to extract an area of interest). Following are instructions for doing this in Pro.In ArcGIS Pro, in a Map view, in the Catalog window, click on Portal. In the Portal window, click on the far-right icon representing Living Atlas. Search on the acronyms “tpl” and “uhi”. The results returned will be the UHI image services. Right click on a result and select “Add to current map” from the context menu. When the image service is added to the map, right-click on it in the map view, and select Properties. In the Properties window, select Processing Templates. On the drop-down menu at the top of the window, the default Processing Template is either a yellow-to-red ramp or a blue-to-red ramp. Click the drop-down, and select “None”, then “OK”. Now you will have the actual pixel values displayed in the map, and available to any geoprocessing tool that takes a raster as input. Below is a screenshot of ArcGIS Pro with a UHI image service loaded, color ramp removed, and symbology changed back to a yellow-to-red ramp (a classified renderer can also be used): Other Sources of Heat Island InformationPlease see these websites for valuable information on heat islands and to learn about exciting new heat island research being led by scientists across the country:EPA’s Heat Island Resource CenterDr. Ladd Keith, University of ArizonaDr. Ben McMahan, University of Arizona Dr. Jeremy Hoffman, Science Museum of Virginia Dr. Hunter Jones, NOAA Daphne Lundi, Senior Policy Advisor, NYC Mayor's Office of Recovery and ResiliencyDisclaimer/FeedbackWith nearly 14,000 cities represented, checking each city's heat island raster for quality assurance would be prohibitively time-consuming, so The Trust for Public Land checked a statistically significant sample size for data quality. The sample passed all quality checks, with about 98.5% of the output cities error-free, but there could be instances where the user finds errors in the data. These errors will most likely take the form of a line of discontinuity where there is no city boundary; this type of error is caused by large temperature differences in two adjacent Landsat scenes, so the discontinuity occurs along scene boundaries (see figure below). The Trust for Public Land would appreciate feedback on these errors so that version 2 of the national UHI dataset can be improved. Contact Pete.Aniello@tpl.org with feedback.Terms of UseYou understand and agree, and will advise any third party to whom you give any or all of the data, that The Trust for Public Land is neither responsible nor liable for any viruses or other contamination of your system arising from use of The Trust for Public Land’s data nor for any delays, inaccuracies, errors or omissions arising out of the use of the data. The Trust for Public Land’s data is distributed and transmitted "as is" without warranties of any kind, either express or implied, including without limitation, warranties of title or implied warranties of merchantability or fitness for a particular purpose. The Trust for Public Land is not responsible for any claim of loss of profit or any special, direct, indirect, incidental, consequential, and/or punitive damages that may arise from the use of the data. If you or any person to whom you make the data available are downloading or using the data for any visual output, attribution for same will be given in the following format: "This [document, map, diagram, report, etc.] was produced using data, in whole or in part, provided by The Trust for Public Land."

Instructions (with screenshots) to replicate results from Section 3 of the manuscript are available in "Step-by-step Instructions to Replicate Results.pdf".-------------------------------------------------------------------------------------------------------------------Step 1: Download the replication materialsDownload the whole replication folder on figshare containing the code, data and replication files.Step 2: Replicate Tables in Section 3All of the data is available inside the sub-folder replication/Data. To replicate Tables 1 and 2 from section 3 of the manuscript run the Python file replicate_section3_tables.py locally on your computer. This will produce two .csv files containing Tables 1 and 2 (already provided). Note that it is not necessary to run the code in order to replicate the tables. The output data needed for replication is provided.Step 3: Replicate Figures in QGISThe Figures must be replicated using QGIS, freely available at https://www.qgis.org/. Open the QGIS project replicate_figures.qgz inside the replication/Replicate Figures sub-folder. It should auto-find the layer data. The Figures are replicated as layers in the project. Step 4: Running the code from scratchThe accompanying code for the manuscript IJGIS-2024-1305, entitled "Route-based Geocoding of Traffic Congestion-Related Social Media Texts on a Complex Network" runs on Google Colab as Python notebooks. Please follow the instructions below to run the entire geocoder and network mapper from scratch. The expected running time is of the order of 10 hours on free tier Google Colab. 4a) Upload to Google DriveUpload the entire replication folder to your Google Drive. Note the path (location) to which you have uploaded it. There are two Google Colab notebooks that need to be executed in their entirety. These are Code/Geocoder/The_Geocoder.ipynb and Code/Complex_Network/Complex_network_code.ipynb. They need to be run in order (Geocoder first and Complex Network second). 4b) Set the path In each Google Colab notebook, you have to set the variable called “REPL_PATH” to the location on your Google Drive where you uploaded the replication folder. Include the replication folder in the path. For example "/content/drive/MyDrive/replication"4c) Run the codeThe code is available in two sub-folders, replication/Code/Geocoder and replication/Code/Complex_Network. You may simply open the Google Colab notebooks inside each folder, mount your Google Drive, set the path and run all cells.

Here is an image of the overall municipal tax rate (foncier bati + habitation, for municipalities and inter-municipalities). http://physaphae.noip.me/Img/2015_Rate_54" alt="Local tax rate 54 of 2015" title="Local tax rate 54 of 2015">

Given that it is at the departmental mesh, it is not useful to include the departmental rate, and national... That would not be part of the comparison.

To do it again yourself you will need: - QQGIS software (Free: https://www.qgis.org/en/site/forusers/download.html), - a qgs file of your department (http://www.actualitix.com/shapefiles-des-departements-de-france.html) - an export of tax rates (https://www.data.gouv.fr/en/datasets/local taxes/)

Procedure: Install QGIS Open your department's .qgs

Add columns - Right click property on the main layer - Go to the fields menu (on the left) - Add (via the pencil) the desired columns (here municipal tax rate, intercommunal built land and housing) - These are reals of a precision 2, and a length 4 - Register

Insert data: - Right click on the layer "Open attribute table" - Select all - Copy - Paste into excel (or openOffice calcs) - Put the ad hoc formulas in excel (SUM.SI.ENS to recover the rate) - Save the desired tab in CSV DOS with the new values - In QGIS > Menu > Layer > Add a delimited text layer - Import the CSV

Present the data: - To simplify I advise you to make one layer per rate, and layers are. Thus rots you in three clicks take out the image of the desired rate - For each layer (or rate) - Right click properties on the csv layer - Labels to add the name of the city and the desired rate - Style for coloring in fct of a csv field

Print the data in pdf: - To print, you need to define a print template - In the menu choose new print dialler - choose the format (a department in A0 is rather readable) - Add vas legend, ladder, and other - Print and voila...

Notice: this is not the latest Heat Island Severity image service. For 2023 data, visit https://tpl.maps.arcgis.com/home/item.html?id=db5bdb0f0c8c4b85b8270ec67448a0b6. This layer contains the relative heat severity for every pixel for every city in the contiguous United States. This 30-meter raster was derived from Landsat 8 imagery band 10 (ground-level thermal sensor) from the summer of 2021, patched with data from 2020 where necessary.Federal statistics over a 30-year period show extreme heat is the leading cause of weather-related deaths in the United States. Extreme heat exacerbated by urban heat islands can lead to increased respiratory difficulties, heat exhaustion, and heat stroke. These heat impacts significantly affect the most vulnerable—children, the elderly, and those with preexisting conditions.The purpose of this layer is to show where certain areas of cities are hotter than the average temperature for that same city as a whole. Severity is measured on a scale of 1 to 5, with 1 being a relatively mild heat area (slightly above the mean for the city), and 5 being a severe heat area (significantly above the mean for the city). The absolute heat above mean values are classified into these 5 classes using the Jenks Natural Breaks classification method, which seeks to reduce the variance within classes and maximize the variance between classes. Knowing where areas of high heat are located can help a city government plan for mitigation strategies.This dataset represents a snapshot in time. It will be updated yearly, but is static between updates. It does not take into account changes in heat during a single day, for example, from building shadows moving. The thermal readings detected by the Landsat 8 sensor are surface-level, whether that surface is the ground or the top of a building. Although there is strong correlation between surface temperature and air temperature, they are not the same. We believe that this is useful at the national level, and for cities that don’t have the ability to conduct their own hyper local temperature survey. Where local data is available, it may be more accurate than this dataset. Dataset SummaryThis dataset was developed using proprietary Python code developed at The Trust for Public Land, running on the Descartes Labs platform through the Descartes Labs API for Python. The Descartes Labs platform allows for extremely fast retrieval and processing of imagery, which makes it possible to produce heat island data for all cities in the United States in a relatively short amount of time.What can you do with this layer?This layer has query, identify, and export image services available. Since it is served as an image service, it is not necessary to download the data; the service itself is data that can be used directly in any Esri geoprocessing tool that accepts raster data as input.In order to click on the image service and see the raw pixel values in a map viewer, you must be signed in to ArcGIS Online, then Enable Pop-Ups and Configure Pop-Ups.Using the Urban Heat Island (UHI) Image ServicesThe data is made available as an image service. There is a processing template applied that supplies the yellow-to-red or blue-to-red color ramp, but once this processing template is removed (you can do this in ArcGIS Pro or ArcGIS Desktop, or in QGIS), the actual data values come through the service and can be used directly in a geoprocessing tool (for example, to extract an area of interest). Following are instructions for doing this in Pro.In ArcGIS Pro, in a Map view, in the Catalog window, click on Portal. In the Portal window, click on the far-right icon representing Living Atlas. Search on the acronyms “tpl” and “uhi”. The results returned will be the UHI image services. Right click on a result and select “Add to current map” from the context menu. When the image service is added to the map, right-click on it in the map view, and select Properties. In the Properties window, select Processing Templates. On the drop-down menu at the top of the window, the default Processing Template is either a yellow-to-red ramp or a blue-to-red ramp. Click the drop-down, and select “None”, then “OK”. Now you will have the actual pixel values displayed in the map, and available to any geoprocessing tool that takes a raster as input. Below is a screenshot of ArcGIS Pro with a UHI image service loaded, color ramp removed, and symbology changed back to a yellow-to-red ramp (a classified renderer can also be used): Other Sources of Heat Island InformationPlease see these websites for valuable information on heat islands and to learn about exciting new heat island research being led by scientists across the country:EPA’s Heat Island Resource CenterDr. Ladd Keith, University of ArizonaDr. Ben McMahan, University of Arizona Dr. Jeremy Hoffman, Science Museum of Virginia Dr. Hunter Jones, NOAA Daphne Lundi, Senior Policy Advisor, NYC Mayor's Office of Recovery and ResiliencyDisclaimer/FeedbackWith nearly 14,000 cities represented, checking each city's heat island raster for quality assurance would be prohibitively time-consuming, so The Trust for Public Land checked a statistically significant sample size for data quality. The sample passed all quality checks, with about 98.5% of the output cities error-free, but there could be instances where the user finds errors in the data. These errors will most likely take the form of a line of discontinuity where there is no city boundary; this type of error is caused by large temperature differences in two adjacent Landsat scenes, so the discontinuity occurs along scene boundaries (see figure below). The Trust for Public Land would appreciate feedback on these errors so that version 2 of the national UHI dataset can be improved. Contact Dale.Watt@tpl.org with feedback.

Additional supporting information includes data, R script, and QGIS file supporting the main text:

CSV (Data Set)

residual_abyssal_peridotites.csv: Compilations of residual abyssal peridotites (n = 1162) and depleted MORB-mantle (n = 1)

residual_abyssal_peridotites_coda_results.csv: Filtered data and results of PCA and k-means clustering (n = 267)

model_cpx.csv: Clinopyroxene compositions obtained by open-system melting model

test.csv: csv file for testing new data

  R

abyssal_cpx_pca.Rproj

coda.R: R script implemented in this study

test_your_data.R: R script to test new data comparing to abyssal clinopyroxenes

and modeled clinopyroxenes

QGIS

residual_abyssal_peridotites.qgz: QGIS using residual_abyssal_peridotites.csv and residual_abyssal_peridotites_coda_results.csv for Figure 1 and Figure S7

color_etopo1_ice_low_modified.tiff: ETOPO1 is a 1 arc-minute global relief model of Earth's surface that integrates land topography and ocean bathymetry from NOAA

1. Instruction

We prepared an R script to compare new (your) clinopyroxene data with clinopyroxene from abyssal peridotites. New data will be plotted using the principal components derived from the natural clinopyroxene database presented in this paper.

The procedure is as follows:

1. add data below the second row in test.csv
2. Do not change the file name
3. Do not change the first row

4. Add clinopyroxene data (10 elements) and its label replacing under 2nd row * Label of data can be sample name, lithology, locality etc.

5. Open abyssal_cpx_pca.Rproj by R studio (double click) 3. Open test_your_data.R (double click)

6. Implement test_your_data.R.

To use test_your_data.R, first press cmd+A (ctrl+A) and press Run/cmd+enter (ctrl+enter).

1. Results files 5-1. abyssalcpx_vs_test.csv: PC1&PC2 values using abyssal clinopyroxene PC coordinates 5-2. plot1.pdf: abyssal clinopyroxene (cluster) vs. test data plot 5-3. plot2.pdf: modeled clinopyroxene vs. test data plot 5-4. spider_cl1.pdf: PM-normalized trace elements patterns of cluster 1 from abyssal peridotites 5-5. spider_cl2.pdf: PM-normalized trace elements patterns of cluster 2 from abyssal peridotites 5-6. spider_cl3.pdf: PM-normalized trace elements patterns of cluster 3 from abyssal peridotites 5-7. spider_cl4.pdf: PM-normalized trace elements patterns of cluster 4 from abyssal peridotites 5-8. spider_test.pdf: PM-normalized trace elements patterns of new data (your data) 5-9. plot3.pdf: Discrimination diagram for clinopyroxene trace elements compositions. PM normalized Sr/Nd ratio vs. Ce/Yb ratio of clinopyroxenes from abyssal peridotites vs. test 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. 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 Data

Southeast Blueprint 2023 subregions: Caribbean
Southeast Blueprint 2023 extent
National Oceanic and Atmospheric Administration (NOAA) National Centers for Environmental Information (NCEI) Coastal Relief Model, accessed 11-22-2022
Protected Areas Database of the United States (PAD-US) 3.0: VI, PR, and Marine Combined Fee Easement
Puerto 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 census
OpenStreetMap data “multipolygons” layer, accessed 3-14-2023

A 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-2023
U.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 Steps

Most 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 values Indicator values are assigned as follows: 6 = 75+ acre urban park 5 = >50 to <75 acre urban park 4 = 30 to <50 acre urban park 3 = 10 to <30 acre urban park 2 = 5 to <10 acre urban park 1 = <5 acre urban park 0 = Not identified as an urban park Known Issues

This 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 Mind

This 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

Important note: If you get a message that .zip archive is corrupt, please try updating WinRAR or right-click the folder and select Extract All on Windows or use unzip command on Linux terminal. If the issue persists, email: kamath.harsh@utexas.edu

Abstract

We introduce GLObal Building heights for Urban Studies (UT-GLOBUS), a dataset providing building heights and urban canopy parameters (UCPs) for major cities worldwide. UT-GLOBUS combines open-source spaceborne altimetry (ICESat-2 and GEDI) and coarse resolution urban canopy elevation data with a random forest model to estimate building-level information. Validation using LiDAR data from six U.S. cities showed UT-GLOBUS-derived building heights had an RMSE of 9.1 meters, and mean building height within 1-km² grid cells had an RMSE of 7.8 meters. Testing the UCPs in the urban Weather Research and Forecasting (WRF-Urban) model resulted in a significant improvement (~55% in RMSE) in intra-urban air temperature representation compared to the existing table-based local climate zone approach in Houston, TX. Additionally, we demonstrated the dataset's utility for simulating heat mitigation strategies and building energy consumption using WRF-Urban, with test cases in Chicago, IL, and Austin, TX. Street-scale mean radiant temperature simulations using the SOlar and LongWave Environmental Irradiance Geometry (SOLWEIG) model, incorporating UT-GLOBUS and LiDAR-derived building heights, confirmed the dataset’s effectiveness in modeling human thermal comfort at Baltimore, MD (daytime RMSE = 2.85°C). Thus, UT-GLOBUS can be used for modeling urban hazards with significant socioeconomic and ecological risks, enabling finer scale urban climate simulations and overcoming previous limitations due to the lack of building information.

Data

We are also supplying a vector file to represent the data coverage, and this file will receive updates as data for new city is added. Building-level data is accessible in vector file format (GeoPackage: .gpkg), which can be converted into raster file format (geoTIFF). These formats are compatible with the SUEWS and SOLWEIG models for the simulation of urban energy balance and thermal comfort. The vector files employ the Universal Transverse Mercator (UTM) projection. Both the vector and raster files are compatible with GIS platforms like QGIS and ArcGIS and can be imported for analysis using programming languages such as Python. We are also providing UCPs required by the BEP-BEM urban model in the urban WRF system in binary file format. Additionally, we provide the urban fractions calculated using ESA world cover dataset (https://esa-worldcover.org/en) for WRF model in binary file format. These files can be directly incorporated into the WRF pre-processing system (WPS). The UT-GLOBUS UCPs are determined using a moving kernel with a size of 1 km2 and spacing of 300 meters in both the X and Y directions

Data coverage

The 'Coverage_xxxx.gpkg' files provide that geographical extents of cities that are included in our dataset.

How to find your city in the UT-GLOBUS dataset

Open the 'coverage' geopackage (.gpkg) files in QGIS or ArcGIS. Click on the city polygons and get the 'Label'/City name. Find a folder with the same 'Label'/City name. All the data for the periticular city will be in the folder.

How to run BEP-BEM model in WRF using UT-GLOBUS urban canopy parameters