The Residential Schools Locations Dataset in Geodatabase format (IRS_Locations.gbd) contains a feature layer "IRS_Locations" that contains the locations (latitude and longitude) of Residential Schools and student hostels operated by the federal government in Canada. All the residential schools and hostels that are listed in the Residential Schools Settlement Agreement are included in this dataset, as well as several Industrial schools and residential schools that were not part of the IRRSA. This version of the dataset doesn’t include the five schools under the Newfoundland and Labrador Residential Schools Settlement Agreement. The original school location data was created by the Truth and Reconciliation Commission, and was provided to the researcher (Rosa Orlandini) by the National Centre for Truth and Reconciliation in April 2017. The dataset was created by Rosa Orlandini, and builds upon and enhances the previous work of the Truth and Reconcilation Commission, Morgan Hite (creator of the Atlas of Indian Residential Schools in Canada that was produced for the Tk'emlups First Nation and Justice for Day Scholar's Initiative, and Stephanie Pyne (project lead for the Residential Schools Interactive Map). Each individual school location in this dataset is attributed either to RSIM, Morgan Hite, NCTR or Rosa Orlandini. Many schools/hostels had several locations throughout the history of the institution. If the school/hostel moved from its’ original location to another property, then the school is considered to have two unique locations in this dataset,the original location and the new location. For example, Lejac Indian Residential School had two locations while it was operating, Stuart Lake and Fraser Lake. If a new school building was constructed on the same property as the original school building, it isn't considered to be a new location, as is the case of Girouard Indian Residential School.When the precise location is known, the coordinates of the main building are provided, and when the precise location of the building isn’t known, an approximate location is provided. For each residential school institution location, the following information is provided: official names, alternative name, dates of operation, religious affiliation, latitude and longitude coordinates, community location, Indigenous community name, contributor (of the location coordinates), school/institution photo (when available), location point precision, type of school (hostel or residential school) and list of references used to determine the location of the main buildings or sites. Access Instructions: there are 47 files in this data package. Please download the entire data package by selecting all the 47 files and click on download. Two files will be downloaded, IRS_Locations.gbd.zip and IRS_LocFields.csv. Uncompress the IRS_Locations.gbd.zip. Use QGIS, ArcGIS Pro, and ArcMap to open the feature layer IRS_Locations that is contained within the IRS_Locations.gbd data package. The feature layer is in WGS 1984 coordinate system. There is also detailed file level metadata included in this feature layer file. The IRS_locations.csv provides the full description of the fields and codes used in this dataset.

This layer comprises road centrelines for all roads controlled by Main Roads (State Roads) and all roads controlled by Local Government (Local Roads) that are assigned road numbers in the state of Western Australia. Other centreline is also included for paths and unknown roads.The Road Network are attributed with a road number as identified in Main Roads’ corporate Integrated Road Information System (IRIS) and the local government Road Management database (ROMAN). The purpose of this layer is to identify roads as identified in IRIS.Note that you are accessing this data pursuant to a Creative Commons (Attribution) Licence which has a disclaimer of warranties and limitation of liability. You accept that the data provided pursuant to the Licence is subject to changes.Pursuant to section 3 of the Licence you are provided with the following notice to be included when you Share the Licenced Material:- The Commissioner of Main Roads is the creator and owner of the data and Licenced Material, which is accessed pursuant to a Creative Commons (Attribution) Licence, which has a disclaimer of warranties and limitation of liability.Creative Commons CC BY 4.0 https://creativecommons.org/licenses/by/4.0/

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

For a full description of the methodology and results, please see the following article:

Demarquet, Q., Rapinel, S., Gore, O., Dufour, S., Hubert-Moy, L., 2024. Continuous change detection outperforms traditional post-classification change detection for long term monitoring of wetlands. International Journal of Applied Earth Observation and Geoinformation 133, 104142. https://doi.org/10.1016/j.jag.2024.104142

Datasets

Points datasets are projected in WGS84 (EPSG:4326), and are provided in the open source GeoPackage format.

The first dataset (Dataset_1.gpkg) contains training and validation points for random forest classification of EUNIS habitats in the Poitevin Marsh. This dataset consists of 3360 training and 840 validation points (total: 4200).Fields description:

"ID": unique identifier

"CLASS": EUNIS first level habitat type, classified as following:

1: EUNIS habitat A

2: EUNIS habitat B

3: EUNIS habitat C1J5

4: EUNIS habitat C3

5: EUNIS habitat E

6: EUNIS habitat G

7: EUNIS habitat I

8: EUNIS habitat J

"DATE": Date associated with EUNIS habitat sample

"LON": Point longitude in decimal degrees

"LAT": Point latitude in decimal degrees

"TYPE": Either training ("train") or validation ("test") sample

The second dataset (Dataset_2.gpkg) contains points for the Olofsson correction method. This dataset consists of 326 points where the change classes are classified as following: -10 (wetland loss), 10 (wetland gain), 100 (stable existing wetland), and 200 (stable damaged wetland).Fields description:

"ID": unique identifier

"LON": Point longitude in decimal degrees

"LAT": Point latitude in decimal degrees

"REFERENCE": Change class reference

"CCDC": Change class obtained from the Continuous Change Detection and Classification approach

"PCCD": Change class obtained from the Post-Classification Change Detection approach

Supplementary layout files (Dataset_1.qml and Dataset_2.qml) support formatting of the points in QGIS software.

EUNIS habitat

Maps are projected in WGS84 (EPSG:4326), and are provided in the GeoTiff format at 30m of spatial resolution.

Habitat maps are given for the two approaches in years 1984 and 2022:

CCDC: Continuous Change Detection and Classification (CCDC_HABITAT_1984.tif and CCDC_HABITAT_2022.tif)

PCCD: Traditional post-classification approach (PCCD_HABITAT_1984.tif and PCCD_HABITAT_2022.tif)

Supplementary layout files (CCDC_HABITAT_1984.qml, CCDC_HABITAT_2022.qml, PCCD_HABITAT_1984.qml, PCCD_HABITAT_2022.qml) support formatting of raster layers in QGIS software.

Change detection during the 1984-2022 period

Maps are projected in WGS84 (EPSG:4326), and are provided in the GeoTiff format at 30m of spatial resolution. Raster values follow the classification scheme used in Dataset_2.

Change detection maps are given for the two approaches:

CCDC: Continuous Change Detection and Classification (CCDC_CHANGE_1984_2022.tif)

PCCD: Traditional post-classification approach (PCCD_CHANGE_1984_2022.tif)

Supplementary layer files (CCDC_CHANGE_1984_2022.qml and PCCD_CHANGE_1984_2022.qml) support formatting of the raster layers in QGIS software.

GEE repository

To get direct access to GEE scripts and assets, please follow those two links:

https://code.earthengine.google.com/?accept_repo=users/demarquetquentin/CCDC_Poitevin

https://code.earthengine.google.com/?asset=projects/ee-quen-dem/assets/CCDC_Poitevin

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/data/dataset/previous-versions-of-the-geoscape-administrative-boundaries

Geoscape Administrative Boundaries is Australia’s most comprehensive national collection of boundaries, including government, statistical and electoral boundaries. It is built and maintained by Geoscape Australia using authoritative government data. Further information about contributors to Administrative Boundaries is available here.

This dataset comprises seven Geoscape products:

• Localities
• Local Government Areas (LGAs)
• Wards
• Australian Bureau of Statistics (ABS) Boundaries
• Electoral Boundaries
• State Boundaries and
• Town Points

Updated versions of Administrative Boundaries are published on a quarterly basis.

Users have the option to download datasets with feature coordinates referencing either GDA94 or GDA2020 datums.

Notable changes in the May 2025 release

• Victorian Wards have seen almost half of the dataset change now reflecting the boundaries from the 2024 subdivision review. https://www.vec.vic.gov.au/electoral-boundaries/council-reviews/ subdivision-reviews.

  • There have been spatial changes (area) greater than 1 km2 to 66 wards in Victoria.

• One new locality ‘Kenwick Island’ has been added to the local Government area ‘Mackay Regional’ in Queensland.

  • There have been spatial changes(area) greater than 1 km2 to the local government areas 'Burke Shire' and 'Mount Isa City' in Queensland.

• There have been spatial changes(area) greater than 1 km2 to the localities ‘Nicholson’, ‘Lawn Hill’ and ‘Coral Sea’ in Queensland and ‘Calguna’, ‘Israelite Bay’ and ‘Balladonia’ in Western Australia.

• An update to the NT Commonwealth Electoral Boundaries has been applied to reflect the redistribution of the boundaries gazetted on 4 March 2025.

• Geoscape has become aware that the DATE_CREATED and DATE_RETIRED attributes in the commonwealth_electoral_polygon MapInfo TAB tables were incorrectly ordered and did not match the product data model. These attributes have been re-ordered to match the data model for the May 2025 release.

IMPORTANT NOTE: correction of issues with the 22 November 2022 release

• On 28 November 2022, the Administrative Boundaries dataset originally released on 22 November 2022 was amended and re-uploaded after Geoscape identified some issues with the original data for 'Electoral Boundaries'.
• As a result of the error, some shapefiles were published in 3D rather than 2D, which may affect some users when importing data into GIS applications.
• The error affected the Electoral Boundaries dataset, specifically the Commonwealth boundary data for Victoria and Western Australia, including 'All States'.
• Only the ESRI Shapefile formats were affected (both GDA94 and GDA2020). The MapInfo TAB format was not affected.
• Because the datasets are zipped into a single file, once the error was fixed by Geoscape all of Administrative Boundaries shapefiles had to be re-uploaded, rather than only the affected files.
• If you downloaded either of the two Administrative Boundary ESRI Shapefiles between 22 November and 28 November 2022 and plan to use the Electoral Boundary component, you are advised to download the revised version dated 28 November 2022. Apologies for any inconvenience.

Further information on Administrative Boundaries, including FAQs on the data, is available here or through Geoscape Australia’s network of partners. They provide a range of commercial products based on Administrative Boundaries, including software solutions, consultancy and support.

Note: On 1 October 2020, PSMA Australia Limited began trading as Geoscape Australia.

The Australian Government has negotiated the release of Administrative Boundaries to the whole economy under an open CCBY 4.0 licence.

Users must only use the data in ways that are consistent with the Australian Privacy Principles issued under the Privacy Act 1988 (Cth).

Users must also note the following attribution requirements:

Preferred attribution for the Licensed Material:

Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International license (CC BY 4.0).

Preferred attribution for Adapted Material:

Incorporates or developed using Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International licence (CC BY 4.0).

What to Expect When You Download Administrative Boundaries

Administrative Boundaries is large dataset (around 1.5GB unpacked), made up of seven themes each containing multiple layers.

Users are advised to read the technical documentation including the product change notices and the individual product descriptions before downloading and using the product.

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/dataset/ds-dga-b4ad5702-ea2b-4f04-833c-d0229bfd689e/details?q=previous

License Information

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.

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 shapefile boundaries for CA State, counties and places from the US Census Bureau's 2023 MAF/TIGER database. Current geography in the 2023 TIGER/Line Shapefiles generally reflects the boundaries of governmental units in effect as of January 1, 2023.

Dataset for: Regional Correlations in the layered deposits of Arabia Terra, Mars

Overview:

This repository contains the map-projected HiRISE Digital Elevation Models (DEMs) and the map-projected HiRISE image for each DEM and for each site in the study. Also contained in the repository is a GeoPackage file (beds_2019_08_28_09_29.gpkg) that contains the dip corrected bed thickness measurements, longitude and latitude positions, and error information for each bed measured in the study. GeoPackage files supersede shapefiles as a standard geospatial data format and can be opened in a variety of open source tools including QGIS, and proprietary tools such as recent versions of ArcGIS. For more information about GeoPackage files, please use https://www.geopackage.org/ as a resource. A more detailed description of columns in the beds_2019_08_28_09_29.gpkg file is described below in a dedicated section. Table S1 from the supplementary is also included as an excel spreadsheet file (table_s1.xlsx).

HiRISE DEMs and Images:

Each HiRISE DEM, and corresponding map-projected image used in the study are included in this repository as GeoTiff files (ending with .tif). The file names correspond to the combination of the HiRISE Image IDs listed in Table 1 that were used to produce the DEM for the site, with the image with the smallest emission angle (most-nadir) listed first. Files ending with “_align_1-DEM-adj.tif” are the DEM files containing the 1 meter per pixel elevation values, and files ending with “_align_1-DRG.tif” are the corresponding map-projected HiRISE (left) image. Table 1 Image Pairs correspond to filenames in this repository in the following way: In Table 1, Sera Crater corresponds to HiRISE Image Pair: PSP_001902_1890/PSP_002047_1890, which corresponds to files: “PSP_001902_1890_PSP_002047_1890_align_1-DEM-adj.tif” for the DEM file and “PSP_001902_1890_PSP_002047_1890_align_1-DRG.tif” for the map-projected image file. Each site is listed below with the DEM and map-projected image filenames that correspond to the site as listed in Table 1. The DEM and Image files can be opened in a variety of open source tools including QGIS, and proprietary tools such as recent versions of ArcGIS.

· Sera

o DEM: PSP_001902_1890_PSP_002047_1890_align_1-DEM-adj.tif

o Image: PSP_001902_1890_PSP_002047_1890_align_1-DRG.tif

· Banes

o DEM: ESP_013611_1910_ESP_014033_1910_align_1-DEM-adj.tif

o Image: ESP_013611_1910_ESP_014033_1910_align_1-DRG.tif

· Wulai 1

o DEM: ESP_028129_1905_ESP_028195_1905_align_1-DEM-adj.tif

o Image: ESP_028129_1905_ESP_028195_1905_align_1-DRG.tif

· Wulai 2

o DEM: ESP_028129_1905_ESP_028195_1905_align_1-DEM-adj.tif

o Image: ESP_028129_1905_ESP_028195_1905_align_1-DRG.tif

· Jiji

o DEM: ESP_016657_1890_ESP_017013_1890_align_1-DEM-adj.tif

o Image: ESP_016657_1890_ESP_017013_1890_align_1-DRG.tif

· Alofi

o DEM: ESP_051825_1900_ESP_051970_1900_align_1-DEM-adj.tif

o Image: ESP_051825_1900_ESP_051970_1900_align_1-DRG.tif

· Yelapa

o DEM: ESP_015958_1835_ESP_016235_1835_align_1-DEM-adj.tif

o Image: ESP_015958_1835_ESP_016235_1835_align_1-DRG.tif

· Danielson 1

o DEM: PSP_002733_1880_PSP_002878_1880_align_1-DEM-adj.tif

o Image: PSP_002733_1880_PSP_002878_1880_align_1-DRG.tif

· Danielson 2

o DEM: PSP_008205_1880_PSP_008930_1880_align_1-DEM-adj.tif

o Image: PSP_008205_1880_PSP_008930_1880_align_1-DRG.tif

· Firsoff

o DEM: ESP_047184_1820_ESP_039404_1820_align_1-DEM-adj.tif

o Image: ESP_047184_1820_ESP_039404_1820_align_1-DRG.tif

· Kaporo

o DEM: PSP_002363_1800_PSP_002508_1800_align_1-DEM-adj.tif

o Image: PSP_002363_1800_PSP_002508_1800_align_1-DRG.tif

Description of beds_2019_08_28_09_29.gpkg:

The GeoPackage file “beds_2019_08_28_09_29.gpkg” contains the dip corrected bed thickness measurements among other columns described below. The file can be opened in a variety of open source tools including QGIS, and proprietary tools such as recent versions of ArcGIS.

(Column_Name: Description)

sitewkn: Site name corresponding to the bed (i.e. Danielson 1)

section: Section ID of the bed (sections contain multiple beds)

meansl: The mean slope (dip) in degrees for the section

meanaz: The mean azimuth (dip-direction) in degrees for the section

ang_error: Angular error for a section derived from individual azimuths in the section

B_1: Plane coefficient 1 for the section

B_2: Plane coefficient 2 for the section

lon: Longitude of the centroid of the Bed

lat: Latitude of the centroid of the Bed

thickness: Thickness of the bed BEFORE dip correction

dipcor_thick: Dip-corrected bed thickness

lon1: Longitude of the centroid of the lower layer for the bed (each bed has a lower and upper layer)

lon2: Longitude of the centroid of the upper layer for the bed

lat1: Latitude of the centroid of the lower layer for the bed

lat2: Latitude of the centroid of the upper layer for the bed

meanc1: Mean stratigraphic position of the lower layer for the bed

meanc2: Mean stratigraphic position of the upper layer for the bed

uuid1: Universally unique identifier of the lower layer for the bed

uuid2: Universally unique identifier of the upper layer for the bed

stdc1: Standard deviation of the stratigraphic position of the lower layer for the bed

stdc2: Standard deviation of the stratigraphic position of the upper layer for the bed

sl1: Individual Slope (dip) of the lower layer for the bed

sl2: Individual Slope (dip) of the upper layer for the bed

az1: Individual Azimuth (dip-direction) of the lower layer for the bed

az2: Individual Azimuth (dip-direction) of the upper layer for the bed

meanz: Mean elevation of the bed

meanz1: Mean elevation of the lower layer for the bed

meanz2: Mean elevation of the upper layer for the bed

rperr1: Regression error for the plane fit of the lower layer for the bed

rperr2: Regression error for the plane fit of the upper layer for the bed

rpstdr1: Standard deviation of the residuals for the plane fit of the lower layer for the bed

rpstdr2: Standard deviation of the residuals for the plane fit of the upper layer for the bed

Since 1998, approximately 148,134,806 m2 (14,813.5 Ha) of seagrass habitat has been mapped across the United Kingdom coastline. This was calculated from a total of 1,872 polygons from 67 datasets of mapped seagrass meadows using various methodologies of surveying (diving, aerial photography, hydrographic surveys, walking surveys, drone mapping, in situ assessments) and various resolutions. This data was collated from a wide range of databases outlined in the paper by Green et al. (2021; doi:10.3389/fpls.2021.629962). The datasets were subsequently projected into QGIS, merged, and dissolved into one layer as one single shapefile. The resulting dataset is a composite shapefile depicting mapped seagrass distribution across the United Kingdom, saved as a QGIS polygon shapefile, using the Assigned Coordinate Reference System (CRS) EPSG:4326 – WGS 84.

Coastline for Antarctica created from various mapping and remote sensing sources, consisting of the following coast types: ice coastline, rock coastline, grounding line, ice shelf and front, ice rumple, and rock against ice shelf. Covering all land and ice shelves south of 60°S. Suitable for topographic mapping and analysis. High resolution versions of ADD data are suitable for scales larger than 1:1,000,000. The largest suitable scale is changeable and dependent on the region.

Major changes in v7.5 include updates to ice shelf fronts in the following regions: Seal Nunataks and Scar Inlet region, the Ronne-Filchner Ice Shelf, between the Brunt Ice Shelf and Riiser-Larsen Peninsula, the Shackleton and Conger ice shelves, and Crosson, Thwaites and Pine Island. Small areas of grounding line and ice coastlines were also updated in some of these regions as needed.

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 links

Map 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 May 2022 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 medium resolution dataset is also published via Living Atlas, as well medium and high resolution polygon datasets.

For background information on the ADD project, please see the British Antarctic Survey ADD project page.

Lineage

Dataset 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 line has attributes detailing the source which can give the user further indications of its suitability for specific uses. Attributes also give information including 'surface' (e.g. grounding line, ice coastline, ice shelf front) and revision date. Compiled from sources ranging in time from 1990s-2022 - individual lines contain exact source dates.

The GIS database contains the data of aufeis (naleds) in the Indigirka River basin (Russia) from historical and nowadays sources, and complete ArcGIS 10.1/10.2 and Qgis 3* projects to view and analyze the data. All data and projects have WGS 1984 coordinate system (without projection). ArcGIS and Qgis projects contain two layers, such as Aufeis_kadastr (historical aufeis data collection, point objects) and Aufeis_Landsat (satellite-derived aufeis data collection, polygon objects). Historical data collection is created based on the Cadastre of aufeis (naleds) of the North-East of the USSR (1958). Each aufeis was digitized as point feature by the inventory map (scale 1:2 000 000), or by topographic maps. Attributive data was obtained from the Cadastre of aufeis. According to the historical data, there were 896 aufeis with a total area 2063.6 km² within the studied basin. Present-day aufeis dataset was created by Landsat-8 OLI images for the period 2013-2017. Each aufeis was delineated by satellite images as polygon. Cloud-free Landsat images are obtained immediately after snowmelt season (e.g. between May, 15 and June, 18), to detect the highest possible number of aufeis. Critical values of Normalized Difference Snow Index (NDSI) were used for semi-automated aufeis detection. However, a detailed expert-based verification was performed after automated procedure, to distinguish snow-covered areas from aufeis and cross-reference historical and satellite-based data collections. According to Landsat data, the number of aufeis reaches 1213, with their total area about 1287 km². The difference between the Cadastre (1958) and the satellite-derived data may indicate significant changes of aufeis formation environments.

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

The Plan de Ville Communal et Intercommunal (PVCI) of Rennes Métropole is the official map plan of the community. It consists of some fifty layers of geographic data managed by the Geographic Information Service and various other services of the community but also by other partners (OSM, IGNF). You will find at the address below, several map productions in PDF format generated from these data: ‘HTTPS://PUBLIC.SIG.RENNESMETROPOLE.FR/HEADER/CARTES’. These data are available as a GeoPackage (*.gpkg) for use under QGIS software. This GeoPackage is accompanied by a pvci_list_layches.ods file that lists and describes each data layer (if applicable, a link to the metadata is available). The data is updated approximately every 2 months. Click here to download this dataset (zip format of 250 MB). It is also possible to connect to the data streams (OCC web services) of the public server of Rennes Métropole. Below you will find documentation to connect to these streams under QGIS: Click here to access PVCI in data stream mode

Aim: Effective management decisions depend on knowledge of species distribution and habitat use. Maps generated from species distribution models are important in predicting previously unknown occurrences of protected species. However, if populations are seasonally dynamic or locally adapted, failing to consider population level differences could lead to erroneous determinations of occurrence probability and ineffective management. The study goal was to model the distribution of a species of special concern, Townsend’s big-eared bats (Corynorhinus townsendii), in California. We incorporate seasonal and spatial differences to estimate the distribution under current and future climate conditions. Methods: We built species distribution models using all records from statewide roost surveys and by subsetting data to seasonal colonies, representing different phenological stages, and to Environmental Protection Agency Level III Ecoregions to understand how environmental needs vary based on these factors. We projected species’ distribution for 2061-2080 in response to low and high emissions scenarios and calculated the expected range shifts. Results: The estimated distribution differed between the combined (full dataset) and phenologically-explicit models, while ecoregion-specific models were largely congruent with the combined model. Across the majority of models, precipitation was the most important variable predicting the presence of C. townsendii roosts. Under future climate scnearios, distribution of C. townsendii is expected to contract throughout the state, however suitable areas will expand within some ecoregions. Main conclusion: Comparison of phenologically-explicit models with combined models indicate the combined models better predict the extent of the known range of C. townsendii in California. However, life history-explicit models aid in understanding of different environmental needs and distribution of their major phenological stages. Differences between ecoregion-specific and statewide predictions of habitat contractions highlight the need to consider regional variation when forecasting species’ responses to climate change. These models can aid in directing seasonally explicit surveys and predicting regions most vulnerable under future climate conditions. Methods Study area and survey data The study area covers the U.S. state of California, which has steep environmental gradients that support an array of species (Dobrowski et al. 2011). Because California is ecologically diverse, with regions ranging from forested mountain ranges to deserts, we examined local environmental needs by modeling at both the state-wide and ecoregion scale, using U.S. Environmental Protection Agency (EPA) Level III ecoregion designations and there are thirteen Level III ecoregions in California (Table S1.1) (Griffith et al. 2016). Species occurrence data used in this study were from a statewide survey of C. townsendii in California conducted by Harris et al. (2019). Briefly, methods included field surveys from 2014-2017 following a modified bat survey protocol to create a stratified random sampling scheme. Corynorhinus townsendii presence at roost sites was based on visual bat sightings. From these survey efforts, we have visual occurrence data for 65 maternity roosts, 82 hibernation roosts (hibernacula), and 91 active-season non-maternity roosts (transition roosts) for a total of 238 occurrence records (Figure 1, Table S1.1). Ecogeographical factors We downloaded climatic variables from WorldClim 2.0 bioclimatic variables (Fick & Hijmans, 2017) at a resolution of 5 arcmin for broad-scale analysis and 30 arcsec for our ecoregion-specific analyses. To calculate elevation and slope, we used a digital elevation model (USGS 2022) in ArcGIS 10.8.1 (ESRI, 2006). The chosen set of environmental variables reflects knowledge on climatic conditions and habitat relevant to bat physiology, phenology, and life history (Rebelo et al. 2010, Razgour et al. 2011, Loeb and Winters 2013, Razgour 2015, Ancillotto et al. 2016). To trim the global environmental variables to the same extent (the state of California), we used the R package “raster” (Hijmans et al. 2022). We performed a correlation analysis on the raster layers using the “layerStats” function and removed variables with a Pearson’s coefficient > 0.7 (see Table 1 for final model variables). For future climate conditions, we selected three general circulation models (GCMs) based on previous species distribution models of temperate bat species (Razgour et al. 2019) [Hadley Centre Global Environment Model version 2 Earth Systems model (HadGEM3-GC31_LL; Webb, 2019), Institut Pierre-Simon Laplace Coupled Model 6th Assessment Low Resolution (IPSL-CM6A-LR; Boucher et al., 2018), and Max Planck Institute for Meteorology Earth System Model Low Resolution (MPI-ESM1-2-LR; Brovkin et al., 2019)] and two contrasting greenhouse concentration trajectories (Shared Socio-economic Pathways (SSPs): a steady decline pathway with CO2 concentrations of 360 ppmv (SSP1-2.6) and an increasing pathway with CO2 reaching around 2,000 ppmv (SSP5-8.5) (IPCC6). We modeled distribution for present conditions future (2061-2080) time periods. Because one aim of our study was to determine the consequences of changing climate, we changed only the climatic data when projecting future distributions, while keeping the other variables constant over time (elevation, slope). Species distribution modeling We generated distribution maps for total occurrences (maternity + hibernacula + transition, hereafter defined as “combined models”), maternity colonies , hibernacula, and transition roosts. To estimate the present and future habitat suitability for C. townsendii in California, we used the maximum entropy (MaxEnt) algorithm in the “dismo” R package (Hijmans et al. 2021) through the advanced computing resources provided by Texas A&M High Performance Research Computing. We chose MaxEnt to aid in the comparisons of state-wide and ecoregion-specific models as MaxEnt outperforms other approaches when using small datasets (as is the case in our ecoregion-specific models). We created 1,000 background points from random points in the environmental layers and performed a 5-fold cross validation approach, which divided the occurrence records into training (80%) and testing (20%) datasets. We assessed the performance of our models by measuring the area under the receiver operating characteristic curve (AUC; Hanley & McNeil, 1982), where values >0.5 indicate that the model is performing better than random, values 0.5-0.7 indicating poor performance, 0.7-0.9 moderate performance and values of 0.9-1 excellent performance (BCCVL, Hallgren et al., 2016). We also measured the maximum true skill statistic (TSS; Allouche, Tsoar, & Kadmon, 2006) to assess model performance. The maxTSS ranges from -1 to +1:values <0.4 indicate a model that performs no better than random, 0.4-0.55 indicates poor performance, (0.55-0.7) moderate performance, (0.7-0.85) good performance, and values >0.80 indicate excellent performance (Samadi et al. 2022). Final distribution maps were generated using all occurrence records for each region (rather than the training/testing subset), and the models were projected onto present and future climate conditions. Additionally, because the climatic conditions of the different ecoregions of California vary widely, we generated separate models for each ecoregion in an attempt to capture potential local effects of climate change. A general rule in species distribution modeling is that the occurrence points should be 10 times the number of predictors included in the model, meaning that we would need 50 occurrences in each ecoregion. One common way to overcome this limitation is through the ensemble of small models (ESMs) (Breiner et al. 2015., 2018; Virtanen et al. 2018; Scherrer et al. 2019; Song et al. 2019) included in ecospat R package (references). For our ESMs we implemented MaxEnt modeling, and the final ensemble model was created by averaging individual bivariate models by weighted performance (AUC > 0.5). We also used null model significance testing with to evaluate the performance of our ESMs (Raes and Ter Steege 2007). To perform null model testing we compared AUC scores from 100 null models using randomly generated presence locations equal to the number used in the developed distribution model. All ecoregion models outperformed the null expectation (p<0.002). Estimating range shifts For each of the three GCMs and each RCP scenario, we converted the probability distribution map into a binary map (0=unsuitable, 1=suitable) using the threshold that maximizes sensitivity and specificity (Liu et al. 2016). To create the final maps for each SSP scenario, we summed the three binary GCM layers and took a consensus approach, meaning climatically suitable areas were pixels where at least two of the three models predicted species presence (Araújo and New 2007, Piccioli Cappelli et al. 2021). We combined the future binary maps (fmap) and the present binary maps (pmap) following the formula fmap x 2 + pmap (from Huang et al., 2017) to produce maps with values of 0 (areas not suitable), 1 (areas that are suitable in the present but not the future), 2 (areas that are not suitable in the present but suitable in the future), and 3 (areas currently suitable that will remain suitable) using the raster calculator function in QGIS. We then calculated the total area of suitability, area of maintenance, area of expansion, and area of contraction for each binary model using the “BIOMOD_RangeSize” function in R package “biomod2” (Thuiller et al. 2021).

This 1:30,000 scale geological map describes Oxia Planum, Mars, the landing site for the ExoMars Rosalind Franklin rover mission. The map represents our current understanding of bedrock units and their relationships prior to Rosalind Franklin’s exploration of this location. The map details 15 bedrock units organised into 6 groups and 7 textural and surficial units. The bedrock units were identified using visible and near-infrared remote sensing datasets. The objectives of this map are (i) to identify where the most astrobiologically relevant rocks are likely to be found, (ii) to show where hypotheses about their geological context (within Oxia Planum and in the wider geological history of Mars) can be tested, (iii) to inform both the long-term (hundreds of metres to ~1 km) and the short-term (tens of metres) activity planning for rover exploration, and (iv) to allow the samples analysed by the rover to be interpreted within their regional geological context.This data set contains:1/ A geodatabase of feature classes for the high resolution geological mapFile name: (DATA_MapGeodatabase_v1.gbd).zipUnzip with: winzip, File explorer, ExpressZipOpens with: ESRI ArcPro, ESRI ArcMap, QGIS.2/ The Map sheet (A0) as published in Fawdon et al., 2024 "The high-resolution map of Oxia Planum, Mars; the landing site of the ExoMars Rosalind Franklin rover mission"File name: ExoMars_Landingsitemap_v1.pdfOpens with: Adobe acrobat reader3/ Shapefiles for the high resolution geological map - [not yet complete, available from the author on request]Filenames:(TBD.shp).zipUnzip with: winzip, File explorer, ExpressZipOpens with: ESRI ArcPro, ESRI ArcMap, QGIS.4/ AcrPro layer files and symbolization information for the shapefiles - [not yet complete, available from the author on request]Filenames: TBD.lyrxOpens with: ESRI ArcPro, ESRI ArcMap, QGIS and other standard gis applications5/ Raters images (geofit) of the major geological units - [not yet complete, available from the author on request]Filenames: TBD.tifOpens with: ESRI ArcPro, ESRI ArcMap, QGIS and other standard gis applications, image processing softwereAdditionally a browsable web-map of the the data is available at https://arcg.is/0y4bSa

This dataset is a high spatial resolution Land Use / Land Cover (LULC) map of the region of Tori-Bossito, southern Benin. Its spatial resolution is 10 m. It was produced in 2011 and made available for a wide range of uses. It has been produced to study the environmental determinants of the presence and abundance of three malaria mosquito species. It contains 14 land cover classes: Freshwater, Herbswamp, Aquatic grassland, Coco tree, Eucalyptus tree, Thicket, Palm tree, Savanna, Teak tree, Pineapple, Degraded riparian forest, Degraded surfaces, Rain-fed agriculture, Forest. The method used to generate the map involved a supervised object-based image classification using mono- and multi-spectral SPOT 5 satellite products from 2010, ground-truth data (> 200 plots) acquired by fieldwork (2010-2011), and nearest-neighbor classifier. The classification accuracy was 98%. In addition to the LULC georeferenced raster data, we propose the following files in this release: the raster attribute table, as an .ods (libreoffice) file, including names and definitions of the land cover classes in both English and French ; a QGIS layer style file (.qml) for visualizing the raster in QGIS ; two color map files (.clr) (English and French) to be used in a variety of GIS software. the map as a .png miniature image ; representative pictures of the land cover classes ; The methodology used to generate the data was detailed in french in Moiroux 2012 (https://theses.hal.science/tel-00812118, p. 79-85 ) and in English, in a more concise way in Moiroux et al. 2013 ( https://doi.org/10.1186/1756-3305-6-71).

The GIS database contains the data of aufeis (naled) in the Chukotka region from historical and nowadays sources, and complete ArcGIS 10.1/10.2 and Qgis 3* projects to view and analyze the data. All data and projects have WGS 1984 coordinate system (without projection). ArcGIS and Qgis projects contain two layers, such as Aufeis_kadastr (historical aufeis data collection, point objects) and Aufeis_Landsat (satellite-derived aufeis data collection, polygon objects). Historical data collection is created based on the Cadastre of aufeis (naled) of the North-East of the USSR (1958). Each aufeis was digitized as point feature by the inventory map (scale 1:2 000 000), or by topographic maps. Attributive data was obtained from the Cadastre of aufeis. According to the historical data, there were 2024 aufeis with a total area 2976.9 km² within the studied area. Present-day aufeis dataset was created by Landsat-8 OLI images for the period 2013-2019. Each aufeis was delineated by satellite images as polygon. Cloud-free Landsat images are obtained immediately after snowmelt season, to detect the highest possible number of aufeis. Critical values of Normalized Difference Snow Index (NDSI) were used for semi-automated aufeis detection. However, a detailed expert-based verification was performed after automated procedure, to distinguish snow-covered areas from aufeis and cross-reference historical and satellite-based data collections. According to Landsat data, the number of aufeis reaches 2758, with their total area about 1147.1 km². The difference between the Cadastre (1958) and the satellite-derived data may indicate significant changes of aufeis formation environments.

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.

This city boundary shapefile was extracted from Esri Data and Maps for ArcGIS 2014 - U.S. Populated Place Areas. This shapefile can be joined to 500 Cities city-level Data (GIS Friendly Format) in a geographic information system (GIS) to make city-level maps.