OUTDATED. See the current data at https://data.cityofchicago.org/d/hz9b-7nh8 -- Building footprints in Chicago. Metadata may be viewed and downloaded at http://bit.ly/HZVDIY. The data can be viewed on the Chicago Data Portal with a web browser. However, to view or use the files outside of a web browser, you will need to use compression software and special GIS software, such as ESRI ArcGIS (shapefile) or Google Earth (KML or KMZ), is required.

These data accompany the 2018 manuscript published in PLOS One titled "Mapping the yearly extent of surface coal mining in Central Appalachia using Landsat and Google Earth Engine". In this manuscript, researchers used the Google Earth Engine platform and freely-accessible Landsat imagery to create a yearly dataset (1985 through 2015) of surface coal mining in the Appalachian region of the United States of America. This specific dataset is a collection of Esri shapefiles of the mining areas as determined by this study for each year from 1985 through 2015. Individual file names within the dataset indicate the specific year. These files show the mining “footprint” in Appalachia for that given year, indicating that mining was occurring in a given location during that year. These files do not, however, indicate the year at which mining began or ceased in any given location.

Building footprints in Chicago. Metadata may be viewed and downloaded at http://bit.ly/HZVDIY. The data can be viewed on the Chicago Data Portal with a web browser. However, to view or use the files outside of a web browser, you will need to use compression software and special GIS software, such as ESRI ArcGIS (shapefile) or Google Earth (KML or KMZ), is required.

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 (not yet published) 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.

Change Log: 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.

22 Nov 2023: 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.

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.

Marine satellite imagery (Sentinel 2 and Landsat 8) (AIMS), https://eatlas.org.au/data/uuid/5d67aa4d-a983-45d0-8cc1-187596fa9c0c - World_AIMS_Marine-satellite-imagery

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.

The Ontario government, generates and maintains thousands of datasets. Since 2012, we have shared data with Ontarians via a data catalogue. Open data is data that is shared with the public. Click here to learn more about open data and why Ontario releases it. Ontario’s Open Data Directive states that all data must be open, unless there is good reason for it to remain confidential. Ontario’s Chief Digital and Data Officer also has the authority to make certain datasets available publicly. Datasets listed in the catalogue that are not open will have one of the following labels: If you want to use data you find in the catalogue, that data must have a licence – a set of rules that describes how you can use it. A licence: Most of the data available in the catalogue is released under Ontario’s Open Government Licence. However, each dataset may be shared with the public under other kinds of licences or no licence at all. If a dataset doesn’t have a licence, you don’t have the right to use the data. If you have questions about how you can use a specific dataset, please contact us. The Ontario Data Catalogue endeavors to publish open data in a machine readable format. For machine readable datasets, you can simply retrieve the file you need using the file URL. The Ontario Data Catalogue is built on CKAN, which means the catalogue has the following features you can use when building applications. APIs (Application programming interfaces) let software applications communicate directly with each other. If you are using the catalogue in a software application, you might want to extract data from the catalogue through the catalogue API. Note: All Datastore API requests to the Ontario Data Catalogue must be made server-side. The catalogue's collection of dataset metadata (and dataset files) is searchable through the CKAN API. The Ontario Data Catalogue has more than just CKAN's documented search fields. You can also search these custom fields. You can also use the CKAN API to retrieve metadata about a particular dataset and check for updated files. Read the complete documentation for CKAN's API. Some of the open data in the Ontario Data Catalogue is available through the Datastore API. You can also search and access the machine-readable open data that is available in the catalogue. How to use the API feature: Read the complete documentation for CKAN's Datastore API. The Ontario Data Catalogue contains a record for each dataset that the Government of Ontario possesses. Some of these datasets will be available to you as open data. Others will not be available to you. This is because the Government of Ontario is unable to share data that would break the law or put someone's safety at risk. You can search for a dataset with a word that might describe a dataset or topic. Use words like “taxes” or “hospital locations” to discover what datasets the catalogue contains. You can search for a dataset from 3 spots on the catalogue: the homepage, the dataset search page, or the menu bar available across the catalogue. On the dataset search page, you can also filter your search results. You can select filters on the left hand side of the page to limit your search for datasets with your favourite file format, datasets that are updated weekly, datasets released by a particular organization, or datasets that are released under a specific licence. Go to the dataset search page to see the filters that are available to make your search easier. You can also do a quick search by selecting one of the catalogue’s categories on the homepage. These categories can help you see the types of data we have on key topic areas. When you find the dataset you are looking for, click on it to go to the dataset record. Each dataset record will tell you whether the data is available, and, if so, tell you about the data available. An open dataset might contain several data files. These files might represent different periods of time, different sub-sets of the dataset, different regions, language translations, or other breakdowns. You can select a file and either download it or preview it. Make sure to read the licence agreement to make sure you have permission to use it the way you want. Read more about previewing data. A non-open dataset may be not available for many reasons. Read more about non-open data. Read more about restricted data. Data that is non-open may still be subject to freedom of information requests. The catalogue has tools that enable all users to visualize the data in the catalogue without leaving the catalogue – no additional software needed. Have a look at our walk-through of how to make a chart in the catalogue. Get automatic notifications when datasets are updated. You can choose to get notifications for individual datasets, an organization’s datasets or the full catalogue. You don’t have to provide and personal information – just subscribe to our feeds using any feed reader you like using the corresponding notification web addresses. Copy those addresses and paste them into your reader. Your feed reader will let you know when the catalogue has been updated. The catalogue provides open data in several file formats (e.g., spreadsheets, geospatial data, etc). Learn about each format and how you can access and use the data each file contains. A file that has a list of items and values separated by commas without formatting (e.g. colours, italics, etc.) or extra visual features. This format provides just the data that you would display in a table. XLSX (Excel) files may be converted to CSV so they can be opened in a text editor. How to access the data: Open with any spreadsheet software application (e.g., Open Office Calc, Microsoft Excel) or text editor. Note: This format is considered machine-readable, it can be easily processed and used by a computer. Files that have visual formatting (e.g. bolded headers and colour-coded rows) can be hard for machines to understand, these elements make a file more human-readable and less machine-readable. A file that provides information without formatted text or extra visual features that may not follow a pattern of separated values like a CSV. How to access the data: Open with any word processor or text editor available on your device (e.g., Microsoft Word, Notepad). A spreadsheet file that may also include charts, graphs, and formatting. How to access the data: Open with a spreadsheet software application that supports this format (e.g., Open Office Calc, Microsoft Excel). Data can be converted to a CSV for a non-proprietary format of the same data without formatted text or extra visual features. A shapefile provides geographic information that can be used to create a map or perform geospatial analysis based on location, points/lines and other data about the shape and features of the area. It includes required files (.shp, .shx, .dbt) and might include corresponding files (e.g., .prj). How to access the data: Open with a geographic information system (GIS) software program (e.g., QGIS). A package of files and folders. The package can contain any number of different file types. How to access the data: Open with an unzipping software application (e.g., WinZIP, 7Zip). Note: If a ZIP file contains .shp, .shx, and .dbt file types, it is an ArcGIS ZIP: a package of shapefiles which provide information to create maps or perform geospatial analysis that can be opened with ArcGIS (a geographic information system software program). A file that provides information related to a geographic area (e.g., phone number, address, average rainfall, number of owl sightings in 2011 etc.) and its geospatial location (i.e., points/lines). How to access the data: Open using a GIS software application to create a map or do geospatial analysis. It can also be opened with a text editor to view raw information. Note: This format is machine-readable, and it can be easily processed and used by a computer. Human-readable data (including visual formatting) is easy for users to read and understand. A text-based format for sharing data in a machine-readable way that can store data with more unconventional structures such as complex lists. How to access the data: Open with any text editor (e.g., Notepad) or access through a browser. Note: This format is machine-readable, and it can be easily processed and used by a computer. Human-readable data (including visual formatting) is easy for users to read and understand. A text-based format to store and organize data in a machine-readable way that can store data with more unconventional structures (not just data organized in tables). How to access the data: Open with any text editor (e.g., Notepad). Note: This format is machine-readable, and it can be easily processed and used by a computer. Human-readable data (including visual formatting) is easy for users to read and understand. A file that provides information related to an area (e.g., phone number, address, average rainfall, number of owl sightings in 2011 etc.) and its geospatial location (i.e., points/lines). How to access the data: Open with a geospatial software application that supports the KML format (e.g., Google Earth). Note: This format is machine-readable, and it can be easily processed and used by a computer. Human-readable data (including visual formatting) is easy for users to read and understand. This format contains files with data from tables used for statistical analysis and data visualization of Statistics Canada census data. How to access the data: Open with the Beyond 20/20 application. A database which links and combines data from different files or applications (including HTML, XML, Excel, etc.). The database file can be converted to a CSV/TXT to make the data machine-readable, but human-readable formatting will be lost. How to access the data: Open with Microsoft Office Access (a database management system used to develop application software). A file that keeps the original layout and

GIS shapefiles of all buildings and disturbance detected across Antarctica, manually digitised from Google Earth images. The data set includes point locations for Automated Weather Stations (AWS), lighthouses, flight routes, maintained traverse routes, camp and hut sites, historic sites and monuments, and sites of current and former stations where mapping was not possible.

The following provides descriptions of the attributes within the GIS layers: 'STATION' refers to the name of the Research Station or Base

'NAME' refers to a named building within a station (e.g. 'Brookes Hut' which is part of 'DAVIS' within the 'STATION' attributes.

'Ice_free' refers to if a building is located on ice or in an ice-free environment '0' = a building on ice. '1' = on an ice-free environment.

'STATUS' refers to the use of the buildings: 1 = Closed site 2 = Lighthouse or camp 3 = Field hut or refuge 4 = Summer/seasonal only 5 = Year round operation.

These data were the output of: Brooks, S. T., Jabour, J., van den Hoff, J. and Bergstrom, D. M. Our footprint on Antarctica competes with nature for rare ice-free land. Nature Sustainability, doi:10.1038/s41893-019-0237-y (2019).

This dataset was last updated on the 30 October 2019 with six additional footprint locations added.

OUTDATED. See the current data at https://data.cityofchicago.org/d/hz9b-7nh8 -- Building footprints in Chicago. Metadata may be viewed and downloaded at http://bit.ly/HZVDIY. The data can be viewed on the Chicago Data Portal with a web browser. However, to view or use the files outside of a web browser, you will need to use compression software and special GIS software, such as ESRI ArcGIS (shapefile) or Google Earth (KML or KMZ), is required.

This dataset consists of a shapefile of the reefs, islands, sand banks, cays and rocks of the whole Great Barrier Reef (GBR) including Torres Strait. This dataset is an extension of the mapping in the GBR Marine Park to include Torres Strait. The Torres Strait region was mapped at a scale of 1:50,000 (Lawrey, E. P., Stewart M., 2016) and these new features are referred to as the "Torres Strait Reef and Island Features" dataset.

The Complete GBR Reef and Island Features dataset integrates the "Torres Strait Reef and Island Features" dataset with the existing "GBR Features" (Great Barrier Reef Marine Park Authority, 2007) to create a single composite dataset of the whole Great Barrier Reef. This dataset includes 9600 features overall with 5685 from the "GBR Features" dataset and 3927 from the "Torres Strait Reef and Island Features" dataset.

These two datasets can be easily separated if necessary based on the "DATASET" attribute.

All new mapped features in Torres Strait were allocated permanent IDs (such as 10-479 for Thursday Island and 09-246 for Mabuiag Reef). These IDs are for easy unambiguous communication of features, especially for unnamed features.

The reference imagery used for the mapping of the reefs is available on request as it is large (~45 GB). These files are saved in the eAtlas enduring repository.

Methods:

This project mapped Torres Strait using a combination of existing island datasets as well as a semi-automated and manual digitising of marine features (reefs and sand banks) from the latest aerial and satellite imagery. No features were added to the dataset without confirmed evidence of their existence and position from at least two satellite image sources. The Torres Strait Reef and Island Feature mapping was integrated with the existing "GBR Features" dataset by GBRMPA to ensure that there were no duplicate feature ID allocations and to create a single dataset of the whole GBR. The overall dataset development was as follows: 1. Dataset collation and image preparation: - Collation of existing maps and datasets. - Download and preparation of the Landsat 5, 7, and 8 satellite image archive for Torres Strait. - Spatial position correction of Landsat imagery against a known reference image. 2. Sand Bank features: - Manual digitisation of sand banks from Landsat 5 imagery. - Conversion to a polygon shapefile for integration with the reef features. 3. Reef features: - Semi-automated digitisation of the marine features from Landsat 5 imagery. - Manual trimming, cleaning and checking of marine features against available aerial and satellite imagery. 4. Island features: - Compilation of island features from existing datasets (DNRM 1:25k Queensland Coastline, and Geoscience Australia Geodata Coast 100k 2004) - Correction of the island features from available aerial and Landsat imagery. 5. Merging: of marine and island features into one dataset. 6. Classification: of mapped features, including splitting fringing reefs based on changes in classification. 7. ID allocation: - Clustering to make groups of related features (i.e. an island, plus its fringing reefs and related sand banks; a reef plus its neighbouring patch reefs, etc.).
- Merging with the GBR Features dataset. This was to ensure that there were no duplicate allocations of feature IDs. This involved removing any overlapping features above the Great Barrier Reef Marine Park from the GBR Feature dataset. - Allocation of group IDs (i.e. 10-362) following the scheme used in the GBR Features dataset. Using R scripting. - Allocation of subgroup IDs (10-362b) to each feature in the dataset. Using R scripting. 8. Allocation of names: - Names of features were copied from some existing maps (Nautical Charts, 250k, 100k Topographic maps, CSIRO Torres Strait Atlas). For more information about the methods used in the development of this dataset see the associated technical report (Lawrey, E. P., Stewart M., 2016)

Limitations:

This dataset has mapped features from remote sensing and thus in some parts of Torres Strait where it is very turbid this may result in an underestimate of boundary of features. It also means that some features may be missing from the dataset.

This dataset is NOT SUITABLE FOR NAVIGATION.

The classification of features in this dataset was determined from remote sensing and not in-situ surveys. Each feature has a confidence rating associated with this classification. Features with a 'Low' confidence should be considered only as guidance.

This project only digitised reefs in Torres Strait, no modifications were made to the features from the integrated GBR Features dataset.

Format:

This dataset is available as a shapefile, a set of associated A1 preview maps of the Torres Strait region, ArcMap MXD file with map styling and ArcMap map layer file. The shapefile is also available in KMZ format suitable for viewing in Google Earth. TS_AIMS_NESP_Torres_Strait_Features_V1b_with_GBR_Features.shp (26 MB), TS_AIMS_NESP_Torres_Strait_Features_V1b_with_GBR_Features.kmz: Torres Strait features (3927 polygon features) integrated with the (GBRMPA) GBR Features dataset (5685 polygon features). This dataset covers the entire GBR.

Data Dictionary:

• DATASET: (TS Features, GBR Features) Which dataset this feature belongs to. This attribute is used when the Torres Strait Reef and Island Features dataset is merged with the GBRMPA GBR Features dataset.
• LOC_NAME_S: (e.g. Tobin (Zagarsum) Island (10-147a)) Location Name: Name of the feature and its ID
• GBR_NAME: (e.g. Tobin (Zagarsum) Island) Name of the features with no ID
• CHART_NAME: (e.g. Tobin Island) Name of the feature on the Australian Nautical Charts
• TRAD_NAME: (Zagarsum) Traditional name. From various sources.
• UN_FEATURE: (TRUE, FALSE) Unnamed Feature: If TRUE then the feature is unnamed. Useful for limiting labels in maps to features with names.
• LABEL_ID: (10-147a) ID of the feature
• SORT_GBR_I: (10147) ID of each feature cluster made up from the Latitude ID and Group ID. Used for sorting the features.
• FEAT_NAME: (Island, Rock, Reef, Cay, Mainland, Bank, Terrestrial Reef, Other ) Classification of the feature that is used in the GBR Features dataset. See 3.6 Classification scheme for more information.
• LEVEL_1, LEVEL_2, LEVEL_3: Hierarchical classification of the features. See Appendix 3: Feature Classification Descriptions.
• Checked: (TRUE, FALSE) Flag to record if the feature was reviewed in detail (at a scale of approximately 1:5000) after the initial digitisation. Unchecked features were only reviewed at a coarser scale (1:25000) to spot significant problems.
• IMG_SOURCE: (Aerial, AGRI, Landsat, ESRI) Imagery type used for the final digitisation checking and correction. (AGRI - AGRI PRISM by GA, Landsat is Landsat 8 or Landsat 5, ESRI - ArcMap satellite basemap)
• CLASS_SRC: (Aerial, AGRI, Landsat, Google, Marine Chart) Imagery type used to determine the classification of the feature. Often the classification will be an aggregation of information from multiple image sources. This field will record the highest resolution source used. For some small features the classification was obtained from the Marine Chart, generally for Rocky Reefs.
• CLASS_CONF: (High, Medium, Low) Confidence of the classification applied to the feature. The confidence is dependent on the clarity and range of the imagery available for classification. High - Clear high resolution imagery available (Aerial, Google) with good water visibility. Key characteristics of the classification clear visible. Feature classification fits the context for the neighbouring region. For unconsolidated features (such as sand banks) a High confidence classification would be applied if the shape, colour and context fit and in particular if movement is visible over time-lapse Landsat imagery. Medium - Moderate imagery available (Landsat 8 pan sharpened, some high resolution imagery) that shows key characteristics of the feature and the classification fits the context for the neighbouring region. Low - Only Landsat 5 imagery is available, the feature is small and its origin is unclear from the neighbouring context. This is the default confidence rating for any features that were not individually checked.
• POLY_ORIG: (QLD_DNRM_Coastline_25k, New, GBR_Features, AU_GA_Coast100k_2004) Original source of the polygon prior to any modifications. New features correspond to all the mapped marine features. Most features from the other source would have been modified as part of the checking and trimming of the dataset.
• SUB_NO: (100, 101, ¿) Subgroup number. Numeric count, starting at 100 of each feature in a group. Matches the subgroup ID i.e. 100 -> blank, 101 -> a, 102 -> b, etc.
• CODE: (e.g. 10-147-102-101) Unique code made from the various IDs. This is a GBR Feature attribute.
• UNIQUE_ID: (10147102101) Same as the CODE but without the hyphens, This is a GBR Feature attribute. Note: Version 1b, this attribution is currently out of date.
• FEATURE_C: (100 - 110) Code applied to each of the FEAT_NAMEs.
• QLD_NAME: (Tobin Island) Same as the GBR_NAME
• X_COORD: Longitude in decimal degrees east, in GDA94.
• Y_COORD: Latitude in decimal degrees north, in GDA94.
• SHAPE_AREA: Shape Area in km2
• SHAPE_LEN: Shape perimeter length in km
• CHECKED: (TRUE, FALSE) Whether the features was carefully checked (at a scale of better than ~1:5000) and manually corrected to this level of precision. If FALSE then the feature was only checked to approximately a1:25000 scale.
• PriorityLn: (TRUE, FALSE) Priority Label - If TRUE then this feature's label should be included in a map. Usually correspond to features with names. Use to reduce near duplicate labels of the islands and their surrounding fringing reefs.
• COUNTRY: (Australia, Papua-New Guinea) Sovereignty of the feature. This is based on a spatial join with the Australian Maritime Boundaries 2014a. The Territorial Sea and the Exclusive Economic

This dataset was created by using a new IIASA tool, called “Street Imagery validation” (https://svweb.cloud.geo-wiki.org/) where users could check street level images (e.g., Google Street Level images, Mapillary etc.) and identify the crop type where it is possible. The advantage of this tool is that there are plenty of georeferenced images with dates, going back in time. The disadvantage is that users need to check plenty of images where only few will clearly show cropland fields that are mature enough to be identified. To make the data collection more efficient, we provided our experts with preliminary maps of points in agricultural areas where street level images are available for the year 2021. Then, the experts checked those locations in an opportunistic way. The dataset is completely independent from all the existing maps and the reference datasets.

There are 3 main data records uploaded:

1. sv_croptype_poly.zip – an archive with a shapefile containing all the collected polygons with crop type information. Not all the polygons correspond to actual field boundaries.
2. sv_croptype_validations.csv – a table with crop type observations with centroid coordinates in WGS84
3. sv_worldcereal_validation.csv – a table with a subset of crop type observations used in validation of WorldCereal crop type maps for 2021.

Fields:

• "id" – unique observation identifier;
• "imgSource" – source of imagery used for visual inspection;
• "imgLoc" – image location;
• "svImgDate" – image date;
• "imageIdKey" – image unique identifier;
• "submitedAt" – date of submission of crop type observation;
• "cropType" - crop type observation;
• "irrType" – irrigation type;
• "x", "y" – centroids of submitted polygons in WGS84.

The City of Chicago launched the Micro-Market Recovery Program (MMRP), a coordinated effort among the City, not-for-profit intermediaries, and non-profit and for-profit capital sources to improve conditions, strengthen property values, and create environments supportive of private investment in targeted markets throughout the city. The goal of MMRP is to improve conditions, strengthen property values, and create environments supportive of private investment in targeted areas by strategically deploying public and private capital and other tools and resources in well-defined micro-markets. This dataset shows the areas covered by the MMRP program. The data can be viewed on the Chicago Data Portal with a web browser. However, to view or use the files outside of a web browser, you will need to use compression software and special GIS software, such as ESRI ArcGIS (shapefile) or Google Earth (KML or KMZ). For more information on the MMRP program, please see http://www.regionalhopi.org/content/city-chicago-micro-market-recovery-program-overview.

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

ps-places-metadata-v1.01

SUMMARY

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

RATIONALE

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

METHODOLOGY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PROJECTION

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

ATTRIBUTES

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

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

LICENSE

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

Peter Scott 16/6/2011

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

The City of Chicago launched the Micro-Market Recovery Program (MMRP), a coordinated effort among the City, not-for-profit intermediaries, and non-profit and for-profit capital sources to improve conditions, strengthen property values, and create environments supportive of private investment in targeted markets throughout the city. The goal of MMRP is to improve conditions, strengthen property values, and create environments supportive of private investment in targeted areas by strategically deploying public and private capital and other tools and resources in well-defined micro-markets. This dataset shows the areas covered by the MMRP program. The data can be viewed on the Chicago Data Portal with a web browser. However, to view or use the files outside of a web browser, you will need to use compression software and special GIS software, such as ESRI ArcGIS (shapefile) or Google Earth (KML or KMZ). For more information on the MMRP program, please see http://www.regionalhopi.org/content/city-chicago-micro-market-recovery-program-overview.

Reservoir and Lake Surface Area Timeseries (ReaLSAT) dataset provides an unprecedented reconstruction of surface area variations of lakes and reservoirs at a global scale using Earth Observation (EO) data and novel machine learning techniques. The dataset provides monthly scale surface area variations (1984 to 2015) of 683734 water bodies below 50°N and sizes between 0.1 to 100 square kilometers.

The dataset contains the following files:

1) ReaLSAT.zip: A shapefile that contains the reference shape of waterbodies in the dataset.

2) monthly_timeseries.zip: contains one CSV file for each water body. The CSV file provides monthly surface area variation values. The CSV files are stored in a subfolder corresponding to each 10 degree by 10 degree cell. For example, monthly_timeseries_60_-50 folders contain CSV files of lakes that lie between 60 E and 70 E longitude, and 50S and 40 S.

3) monthly_shapes_

4) ReaLSAT.html: a readme python notebook that provides information about reading and visualizing the dataset. The notebook also contains the code to download the data to reduce the overhead of downloading each file manually.

5) evaluation_data.zip: contains the random subsets of the dataset used for evaluation. The zip file contains a README file that describes the evaluation data.

6) generate_realsat_timeseries.ipynb: a Google Colab notebook that provides the code to generate timerseries and surface extent maps for any waterbody.

Please refer to the following papers to learn more about the processing pipeline used to create ReaLSAT dataset:

[1] Khandelwal, Ankush, Rahul Ghosh, Zhihao Wei, Huangying Kuang, Hilary Dugan, Paul Hanson, Anuj Karpatne, and Vipin Kumar. "ReaLSAT: A new Reservoir and Lake Surface Area Timeseries Dataset created using machine learning and satellite imagery." (2020).

[2] Khandelwal, Ankush. "ORBIT (Ordering Based Information Transfer): A Physics Guided Machine Learning Framework to Monitor the Dynamics of Water Bodies at a Global Scale." (2019).

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.

The 3D Global Building Footprints (3D-GloBFP) dataset is the first global-scale building height dataset at the individual building footprint level for the year 2020, generated through the integration of multisource Earth Observation (EO) data and the extreme gradient boosting (XGBoost) model. The reliability and accuracy of 3D-GloBFP have been validated across 33 subregions, achieving R² values ranging from 0.66 to 0.96 and root-mean-square errors (RMSEs) between 1.9 m and 14.6 m.

This version supplements building footprints and height attributes for some countries in South America, Asia, Africa, and Europe, based on building footprints provided by Microsoft (https://github.com/microsoft/GlobalMLBuildingFootprints), Open Street Map (https://osmbuildings.org/), Google-Microsoft Open Buildings - combined by VIDA (https://source.coop/repositories/vida/google-microsoft-open-buildings), and EUBUCCO (https://eubucco.com/).

The dataset is divided into spatial grid-based tiles, each stored as an individual ShapeFile (.shp) containing estimated building heights (in meters) in attribute tables. See world_grid.shp and readme.txt for details on the spatial grid and file naming.

Data download links are provided in data_links.txt.

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

Reservoir and Lake Surface Area Timeseries (ReaLSAT) dataset provides an unprecedented reconstruction of surface area variations of lakes and reservoirs at a global scale using Earth Observation (EO) data and novel machine learning techniques. The dataset provides monthly scale surface area variations (1984 to 2015) of 683734 water bodies below 50°N and sizes between 0.1 to 100 square kilometers.

The dataset contains the following files:

1) ReaLSAT.zip: A shapefile that contains the reference shape of waterbodies in the dataset.

2) monthly_timeseries.zip: contains one CSV file for each water body. The CSV file provides monthly surface area variation values. The CSV files are stored in a subfolder corresponding to each 10 degree by 10 degree cell. For example, monthly_timeseries_60_-50 folders contain CSV files of lakes that lie between 60 E and 70 E longitude, and 50S and 40 S.

3) monthly_shapes_

4) ReaLSAT.html: a readme python notebook that provides information about reading and visualizing the dataset. The notebook also contains the code to download the data to reduce the overhead of downloading each file manually.

5) evaluation_data.zip: contains the random subsets of the dataset used for evaluation. The zip file contains a README file that describes the evaluation data.

6) generate_realsat_timeseries.ipynb: a Google Colab notebook that provides the code to generate timerseries and surface extent maps for any waterbody.

Please refer to the following papers to learn more about the processing pipeline used to create ReaLSAT dataset:

[1] Khandelwal, Ankush, Rahul Ghosh, Zhihao Wei, Huangying Kuang, Hilary Dugan, Paul Hanson, Anuj Karpatne, and Vipin Kumar. "ReaLSAT: A new Reservoir and Lake Surface Area Timeseries Dataset created using machine learning and satellite imagery." (2020).

[2] Khandelwal, Ankush. "ORBIT (Ordering Based Information Transfer): A Physics Guided Machine Learning Framework to Monitor the Dynamics of Water Bodies at a Global Scale." (2019).

Version Updates

Version 1.3: fixed visualization related bug in generate_realsat_timeseries.ipynb

Version 1.2: added a Google Colab notebook that provides the code to generate timerseries and surface extent maps for any waterbody in ReaLSAT database.

The dataset features SafeGraph data that measures foot-traffic mobility changes around Open Streets in New York City during Covid-19. In addition to the raw counts of visitors to each POI during the week. It contains weekly pattern data collected between May 2nd, 2020, to July 28th , 2021. The point-level POI data is aggregated to census block group neighborhood-level data to maintain a standard level of resolution for all data used for this study. The Open Streets have been manually geocoded in Google Earth and imported the KMZ data as a shapefile into ArcGIS. Once in ArcGIS, the locations of the Open Streets were matched to CBGs, which either bound or intersect with the Open Streets. Since the Open Streets vary in opening dates, we consider the week that a street first opens as an Open Street as Week 0 for each street. For each observation, we consider the time series data three weeks before the week of opening date (Week 0) and six weeks after as our observation period. To create a control sample, we draw a 1 mile buffer area around each Open Street in ArcGIS to minimize spillover effects, and randomly select a CBG that sits outside this buffer area and pair it with each observation. The buffer takes into account the spatial effects an Open Street is likely to have on surrounding neighborhoods, such that a neighborhood that is within a 15-20 minute walk of an Open Street may see increase in walking behaviors after the introduction of the Open Streets Program, even if the Open Street is not located directly within the CBG.

BackgroundAs the world’s most rapidly urbanizing country, China now faces mounting challenges from growing inequalities in the built environment, including disparities in access to essential infrastructure and diverse functional facilities. Yet these urban inequalities have remained unclear due to coarse observation scales and limited analytical scopes. In this study, we present the first building-level functional map of China, covering 110 million individual buildings across 109 cities using 69 terabytes of 1-meter resolution multi-modal satellite imagery. The national-scale map is validated by government reports and 5,280,695 observation points, showing strong agreement with external benchmarks. This enables the first nationwide, multi-dimensional assessment of inequality in the built environment across city tiers, geographical regions, and intra-city zones.About dataBased on the Paraformer framework that we proposed previously, we produced the first nationwide building-level functional map of urban China, processing over 69 TB of satellite data, including 1-meter Google Earth optical imagery (https://earth.google.com), 10-meter nighttime lights (SGDSAT-1) (https://sdg.casearth.cn/en), and building height data (CNBH-10m) (https://zenodo.org/records/7827315). Labels were derived from: (1) Building footprint data, including the CN-OpenData (https://doi.org/10.11888/Geogra.tpdc.271702) and the East Asia Building Dataset (https://zenodo.org/records/8174931); and (2) Land use and AOI data used for constructing urban functional annotation are retrieved from OpenStreetMap (https://www.openstreetmap.org) and EULUC-China dataset (https://doi.org/10.1016/j.scib.2019.12.007). The first 1-meter resolution national-scale land-cover map used to conduct the accessibility analysis is available in our previous study: SinoLC-1 (https://doi.org/10.5281/zenodo.7707461). The housing inequality and infrastructure allocation analysis was conducted based on the 100-meter gridded population dataset from China's seventh census (https://figshare.com/s/d9dd5f9bb1a7f4fd3734?file=43847643).This version of the data includes (1) Building-level functional maps of 109 Chinese cities, and (2) In-situ validation point sets. The building-level functional maps of 109 Chinese cities are organized in the ESRI Shapefile format, which includes five components: “.cpg”, “.dbf”, “.shx”, “.shp”, and “.prj” files. These components are stored in “.zip” files. Each city is named “G_P_C.zip,” where “G” explains the geographical region (south, central, east, north, northeast, northwest, and southwest of China) information, “P” explains the provincial administrative region information, and “C” explains the city name. For example, the building functional map for Wuhan City, Hubei Province is named “Central_Hubei_Wuhan.zip”.Furthermore, each shapefile of a city contains the building functional types from 1 to 8, where the corresponding relationship between the values and the building functions is shown below:Residential buildingCommercial buildingIndustrial buildingHealthcare buildingSport and art buildingEducational buildingPublic service buildingAdministrative buildingAbout validationGiven the importance of accurate mapping for downstream analysis, we conducted a comprehensive evaluation using government reports and in situ validation data outlined in the Data Section. This evaluation comprised two parts. First, a statistical-level evaluation was performed for each city based on official reports from the China Urban-Rural Construction Statistical Yearbook (https://www.mohurd.gov.cn/gongkai/fdzdgknr/sjfb/tjxx/jstjnj/index.html) and China Statistical Yearbook (https://www.stats.gov.cn/sj/ndsj/2023/indexch.htm). Second, a building-level geospatial evaluation was conducted by using 5.28 million field-observed points from Amap Inc. (provided in this data version of "Validation_in-situ_points.zip"), and a confusion matrix was calculated to compare the in situ points with the mapped buildings at the same location. The "Validation_in-situ_points.zip" includes the original point sets of each city, named as the city name (e.g., Wuhan.shp and corresponding “.cpg”, “.dbf”, “.shx”, and “.prj” files).