Find research datasets worth reusing

opencc-by-4.0Sep 2020View details →

Sonic Kayaks geolocated air pollution, water turbidity, temperature and hydrophone analysis

These data sets are the result of five trips using <a href="https://fo.am/activities/kayaks/">Sonic Kayaks</a> to collect data as part of the <a href="https://actionproject.eu/">ACTION Project</a>. The sampling was carried out in the Penryn river, around Falmouth docks and the Helford estuary. A variety of sensors were used: <ol> <li>Thermometer recording water temperature.</li> <li>PMS7003 air pollution sensor recording a variety of particulate sizes.</li> <li>DolphinEar DE PRO hydrophone for detecting noise pollution and biological signals.</li> <li>A custom turbidity sensor to detect changes in water cloudiness.</li> </ol> The sound has been processed in this data set in order to classify sound sources from different boat engines. More information, source code and <a href="https://github.com/fo-am/sonic-kayaks/wiki">open hardware plans for construction can be found here</a>.

opencc-by-4.0Nov 2024View details →

Migration Route of Swiss Ring Ouzels with Multi-Sensor Geolocator

This GeoLocator Datapackage contains the raw data for 5 multi-sensor geolocators and 4 light-level geolocators data equipped on Alpine Ring Ouzels (Turdus torquatus alpestris) in Switzerland between 2017-2020. The data has been processed using the GeoPressureR package to produce trajectories for the 5 multi-sensor tags. Code can be found on Github <a href="https://github.com/Rafnuss/migration-route-of-swiss-ring-ouzels">Rafnuss/migration-route-of-swiss-ring-ouzels</a>. The raw data has been used in <a href="https://doi.org/10.1111/jav.02860">10.1111/jav.02860</a>

opencc-by-4.0Jul 2022View details →

100 geolocated oil spills in the Gulf of Guinea

Shapefile containing 100 geolocated oil spills in the Gulf of Guinea and including oil spill from ship and oil spill from platform

opencc-by-4.0Aug 2023View details →

GO-FISH: Geolocated Ocean-Fishery Identified Spawning Habitats

This dataset represents geocoded spawning regions for 1,045 marine fish species described in the Fishbase (https://www.fishbase.se/) and Science and Conservation of Fish Aggregations (SCRFA, <a href="https://www.scrfa.org/database/">https://www.scrfa.org/database/</a>) datasets. These global databases have painstakingly aggregated the fieldwork of countless biologists and ecologists to summarize our knowledge of fish species. We further constrained geographic locations using AquaMaps (<a href="https://www.aquamaps.org/">https://www.aquamaps.org</a>) to produce 2,931 polygons or groups of polygons, which we call "spawning regions". Reproduction code for the dataset is available at <a href="https://github.com/openmodels/spawning-dataset">https://github.com/openmodels/spawning-dataset</a>, archived at <a href="../records/11098955">https://zenodo.org/records/11098955</a>.

opencc-by-4.0May 2020View details →

Geolocation of German Academic Institutions

The dataset has four columns; Name of the institution, Homepage, Latitude, Longitude.  The entries in each row are delimited by a semicolon.

opencc-by-4.0Mar 2022View details →

Data for Yunjun et al. (2022) on SAR Range Geolocation

This repository contains the data used in Yunjun et al. (2022, IEEE-TGRS). <ul> <li>Yunjun, Z., Fattahi, H., Pi, X., Rosen, P., Simons, M., Agram, P., & Aoki, Y. (2022). Range Geolocation Accuracy of C-/L-band SAR and its Implications for Operational Stack Coregistration. IEEE Transactions on Geoscience and Remote Sensing, 60, doi:<a href="https://doi.org/10.1109/TGRS.2022.3168509">10.1109/TGRS.2022.3168509</a>.</li> </ul> It includes the following 3 test sites: <ul> <li>Sentinel-1 ascending track 149 in northern Chile</li> <li>Sentinel-1 descending track 156 in northern Chile</li> <li>ALOS-2 descending track 23 in southern Kyushu, Japan</li> </ul> For each test site, it includes the following datasets: <ul> <li>SAR range and azimuth offset stack (using <a href="https://github.com/isce-framework/isce2">ISCE-2</a> / <a href="https://github.com/isce-framework/isce2/tree/main/contrib/PyCuAmpcor">PyCuAmpcor</a>)</li> <li>SAR range offset time series (using <a href="https://github.com/insarlab/MintPy">MintPy</a>)</li> <li>JPL high-resolution Global Ionospheric Maps (GIM) and the topside TEC for ChileSenAT149.</li> <li>Solid Earth tides prediction (using <a href="https://github.com/insarlab/PySolid">PySolid</a>)</li> <li>ERA5 tropospheric delay prediction (using <a href="https://github.com/insarlab/PyAPS">PyAPS</a>)</li> </ul> Useful links: <ul> <li>HDF-EOS5 file (*.he5) structure is described in <a href="https://mintpy.readthedocs.io/en/latest/hdfeos5/">https://mintpy.readthedocs.io/en/latest/hdfeos5/</a>.</li> <li>HDF5/MintPy file (*.h5) structure is described in <a href="https://mintpy.readthedocs.io/en/latest/api/data_structure/">https://mintpy.readthedocs.io/en/latest/api/data_structure/</a>.</li> <li>Related Notebooks at <a href="https://github.com/yunjunz/2022-Geolocation">https://github.com/yunjunz/2022-Geolocation</a>.</li> </ul>

dryad40/100

Double-tagging scores of seabirds reveals that light-level geolocator accuracy is limited by species idiosyncrasies and equatorial solar profiles

Light-level geolocators are popular bio-logging tools, with advantageous sizes, longevity, and affordability. Biologists tracking seabirds often presume geolocator spatial accuracies between 186-202 km from previously-innovative, yet taxonomically, spatially, and computationally limited, studies. Using recently developed methods, we investigated whether assumed uncertainty norms held across a larger-scale, multispecies study. We field-tested geolocator spatial accuracy by synchronously deploying these with GPS loggers on scores of seabirds across five species and 11 Mediterranean Sea, East Atlantic and South Pacific breeding colonies. We first interpolated geolocations using the geolocation package FLightR without prior knowledge of GPS tracked routes. We likewise applied another package, probGLS, additionally testing whether sea-surface temperatures could improve route accuracy. Geolocator spatial accuracy was lower than the ~200km often assumed. probGLS produced the best accuracy (mean ± SD = 304 ± 413 km, n = 185 deployments) with 84.5% of GPS-derived latitudes and 88.8% of longitudes falling within resulting uncertainty estimates. FLightR produced lower spatial accuracy (408 ± 473 km, n = 171 deployments) with 38.6% of GPS-derived latitudes and 27% of longitudes within package-specific uncertainty estimates. Expected inter-twilight period (from GPS position and date) was the strongest predictor of accuracy, with increasingly equatorial solar profiles (i.e., closer temporally to equinoxes and/or spatially to the Equator) inducing more error. Individuals, species and geolocator model also significantly affected accuracy, while the impact of distance travelled between successive twilights depended on the geolocation package. Geolocation accuracy is not uniform among seabird species and can be considerably lower than assumed. Individual idiosyncrasies and spatiotemporal dynamics (i.e., shallower inter-twilight shifts by date and latitude) mean that practitioners should exercise greater caution in interpreting geolocator data and avoid universal uncertainty estimates. We provide a function capable of estimating relative accuracy of positions based on geolocator-observed inter-twilight period.

opencc-zeroAug 2021View details →

openother-openDec 2022View details →

Design and Development of a Smartphone-Based Geolocalized Exposure Therapy Software for Anxiety Disorders: SyMptOMS-ET -- Reproducibility Package

R Notebook and datasets for the submitted paper "Towards a self-applied, mobile-based geolocated exposure therapy software for anxiety disorders: SyMptOMS-ET app" <blockquote> Alberto González-Pérez, Laura Diaz-Sanahuja, Miguel Matey-Sanz, Jorge Osma, Carlos Granell, Juana Bretón-López, Sven Casteleyn. Towards a self-applied, mobile-based geolocated exposure therapy software for anxiety disorders: SyMptOMS-ET app. <a href="https://journals.sagepub.com/home/dhj">Digital Health Journal</a> [Submitted] </blockquote> Experiments were conducted using the v1.2.0 version of the SyMptOMS-ET open-source app, which can be found <a href="https://github.com/GeoTecINIT/symptoms-mobile-app/releases/tag/v1.2.0">here</a>.

opencc-by-4.0Jan 2023View details →

Timing of migration and African non-breeding grounds of geolocator-tracked Pied Flycatchers: A multi-population assessment

We provide raw geolocator data from eight pied flycatchers tracked by light geolocators from breeding sites in the Czech Republic. Geolocator model GDL2.0 with 7 mm light stalk, producer Swiss Ornithological Institute. A script for R with calibration method for the equinox period is provided.

opencc-by-4.0Sep 2022View details →

Swiss Dwellings: A large dataset of apartment models including aggregated geolocation-based simulation results covering viewshed, natural light, traffic noise, centrality and geometric analysis

Introduction This dataset contains detailed data on over 45,000 apartments (370,000 rooms) in ~3,100 buildings including their geometries, room typology as well as their visual, acoustical, topological, and daylight characteristics. Additionally, we have included location-specific characteristics for the buildings, including climatic data and points of interest within walking distance. Changelog <ul> <li>v3.0.0 (2023-03-31): <ul> <li>Updated the dataset increasing the total number of apartments to 45176 and incorporating fixes to some of the sites. The update includes re-digitized apartments and thus alters some ID values.</li> </ul> </li> <li>v2.2.1 (2023-03-10): <ul> <li>A file, <code>location_ratings.csv</code>, has been included to provide ratings of the locations in which the buildings are situated. The ratings, provided by <a href="https://en.fpre.ch/">Fahrländer Partner AG</a>, give insights into the living situation at the buildings' addresses. Details for the different dimensions are provided below.</li> <li>The file <code>location.csv</code> has been updated to include the minimum and maximum temperatures for the locations in which the buildings are situated.</li> </ul> </li> <li>v2.1.0 (2022-12-23): <ul> <li>A file, <code>locations.csv</code>, has been included to provide information on the climatic and infrastructural characteristics of the locations in which each building is situated</li> </ul> </li> <li>v2.0.0 (2022-10-17): <ul> <li>Additional to the residential units, we also include the commercial and public parts (such as staircases) of the models. The field <code>unit_usage</code> describes whether an area belongs to a commercial, residential, janitor or public part of the building</li> <li>Added the fields <code>elevation</code> and <code>height</code> to geometries.csv to describe the elevation above the terrain surface and the height of objects.</li> <li>Added the field <code>plan_id</code> which allows identifying which floors are based on the same floor plan (in some cases multiple floors of a building share the same floor plan</li> <li>Improved the ordering of fields in the CSV files (instead of alphabetic order)</li> <li>Minor changes to individual sites</li> </ul> </li> </ul> Procurement The data is sourced from commercial clients of <a href="https://www.archilyse.com/">Archilyse AG</a> specializing on the digitization and analysis of buildings. The existing building plans of clients are converted into a geo-referenced, semantically annotated representation and undergo a manual Q/A process to ensure the accuracy of the data and to ensure a maximum 5%-deviation in the apartments' areas (validated with a median deviation of 1.2%). Geometries The dataset contains a file <code>geometries.csv</code> which contains the geometries of all areas, walls, railings, columns, windows, doors and features (sinks, bathtubs, etc.) of an apartment. In total, the datasets contain the 2D geometry of ~1.7 million separators (walls, railings), ~715,000 openings (windows, doors), ca. 520,000 areas (rooms, bathrooms, kitchens, etc.), and ~315,000 features (sinks, toilets, bathtubs, etc.). Each row contains: <ul> <li><code>apartment_id</code>: The ID of the apartment (for features, areas), note: an apartment id is only unique per site</li> <li><code>site_id</code>: The ID of the site</li> <li><code>building_id</code>: The ID of the building</li> <li><code>floor_id</code>: The ID of the floor</li> <li><code>plan_id</code>: The ID of the plan on which the floor is based, multiple floors of a building might be based on the same plan</li> <li><code>unit_id</code>: The ID of the unit in which the element is spatially contained (for features, areas)</li> <li><code>area_id</code>: The ID of the area in which the element is spatially contained (for features)</li> <li><code>unit_usage</code>: The usage of the unit, possible values are: RESIDENTIAL, COMMERCIAL, PUBLIC, JANITOR</li> <li><code>entity_type</code>: The entity type (area, separator, opening, feature)</li> <li><code>entity_subtype</code>: The entity’s sub-type (e.g. WALL)</li> <li><code>geometry</code>: The element’s geometry as a <a href="https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry">WKT</a> geometry in meters. The geometry is given in the site’s local coordinate system. I.e. the position between elements of the same site are correct in respect to each other. The +y direction points northwards, the +x direction points eastwards.</li> <li><code>elevation</code>: The object's elevation above the terrain surface in meters. We assume one terrain baseline per building, thus all walls in a given floor share the same elevation value. However, windows in particular might start at different elevations and have differing heights.</li> <li><code>height</code>: The height of the entity in meters, note: In many cases, a default height is assumed</li> </ul> An example: <table> <thead> <tr> <th scope="col">column</th> <th scope="col"> </th> </tr> </thead> <tbody> <tr> <td>apartment_id</td> <td> d4438f2129b30290845ce7eef98a5ba7 </td> </tr> <tr> <td>site_id</td> <td>127</td> </tr> <tr> <td>building_id</td> <td>164</td> </tr> <tr> <td>plan_id</td> <td>492</td> </tr> <tr> <td>floor_id</td> <td>861</td> </tr> <tr> <td>unit_id</td> <td>63777</td> </tr> <tr> <td>area_id</td> <td>767676</td> </tr> <tr> <td>unit_usage</td> <td>RESIDENTIAL</td> </tr> <tr> <td>entity_type</td> <td>area</td> </tr> <tr> <td>entity_subtype</td> <td>LIVING_ROOM</td> </tr> <tr> <td>geometry</td> <td> POLYGON ((-6.1501158933490139 -4.8490786654693... </td> </tr> <tr> <td>elevation</td> <td>0</td> </tr> <tr> <td>height</td> <td>2.6</td> </tr> </tbody> </table> Simulations Besides the geometrical model, we also provide simulation data on the visual, acoustic, solar, layout, and connectivity-related characteristics of the apartments. The file <code>simulations.csv</code> contains the simulation data aggregated on a per-area basis. Each row contains the identifier columns <code>area_id</code>, <code>unit_id</code>, <code>apartment_id</code>, <code>floor_id</code>, <code>building_id</code>, <code>site_id</code> as defined above as well as 367 simulation columns. Each simulation column is formatted as: <pre><code><simulation_category>_<simulation_dimensions>_<aggregation_function></code></pre> For instance. the column <code>view_buildings_median</code> describes the amount of building surface that can be seen from any point in a given room. The aggregation methods vary per simulation category and are described in detail below. Layout The layout features represent simple features based on the geometry and composition of a room, the dataset provides the following information in an unaggregated form. Area Basics / Geometry <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_area_type</td> <td>The area’s area type</td> </tr> <tr> <td>layout_net_area</td> <td>The area’s share of the apartment’s net area (e.g. 0 for a balcony)</td> </tr> <tr> <td>layout_area</td> <td>The area’s actual area</td> </tr> <tr> <td>layout_perimeter</td> <td>The area’s perimeter</td> </tr> <tr> <td>layout_compactness</td> <td>The area’s compactness (the Polsby–Popper score)</td> </tr> <tr> <td>layout_room_count</td> <td>The area’s share to the apartment’s room count</td> </tr> <tr> <td>layout_is_navigable</td> <td>True if the area is navigable by a wheelchair</td> </tr> </tbody> </table> Area Features <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_has_sink</td> <td>True if the area has a sink</td> </tr> <tr> <td>layout_has_shower</td> <td>True if the area has a shower</td> </tr> <tr> <td>layout_has_bathtub</td> <td>True if the area has a bathtub</td> </tr> <tr> <td>layout_has_toilet</td> <td>True if the area has a toilet</td> </tr> <tr> <td>layout_has_stairs</td> <td>True if the area has stairs</td> </tr> <tr> <td>layout_has_entrance_door</td> <td>True if the area is directly leading to an exit of the apartment</td> </tr> </tbody> </table> Area Windows / Doors <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_number_of_doors</td> <td>The number of doors directly leading to the area</td> </tr> <tr> <td>layout_number_of_windows</td> <td>The number of windows of the area</td> </tr> <tr> <td>layout_door_perimeter</td> <td>The sum of all door lengths directly leading to the area</td> </tr> <tr> <td>layout_window_perimeter</td> <td>The sum of all window lengths of the area</td> </tr> </tbody> </table> Area Walls / Railings <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_open_perimeter</td> <td>The sum of all of the boundaries of the area that are neither walls nor railings</td> </tr> <tr> <td>layout_railing_perimeter</td> <td>The sum of all of the boundaries of the area that are railings</td> </tr> <tr> <td>layout_mean_walllengths</td> <td>The mean length of the area’s sides</td> </tr> <tr> <td>layout_std_walllengths</td> <td>The standard deviation of the lengths of the area’s sides</td> </tr> </tbody> </table> Area Adjacency <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>layout_connects_to_bathroom</td> <td>True if the area connects to a bathroom</td> </tr> <tr> <td>layout_connects_to_private_outdoor</td> <td>True if the area connects to an outside area that is private to the apartment</td> </tr> </tbody> </table> View The views from an object help to understand the impact of the surroundings on the object. The view simulation calculates the visible amount of buildings, greenery, water, etc. on each individual hexagon from the analyzed object. The values are expressed in steradians (sr) and represent the amount a particular object category occupies in the spherical field of view. Each of the following dimensions is provided using the room-wise aggregations' min, max, mean, std, median, p20, and p80. For instance, the column <code>view_greenery_p20</code> describes the amount of greenery that can be seen from at least 20% of the positions in the area. <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>view_buildings</td> <td>The amount of visible buildings</td> </tr> <tr> <td>view_greenery</td> <td>The amount of visible greenery</td> </tr> <tr> <td>view_ground</td> <td>The amount of visible ground</td> </tr> <tr> <td>view_isovist</td> <td>The amount of visible isovist</td> </tr> <tr> <td>view_mountains_class_2</td> <td>The amount of visible mountains of UN mountain class 2</td> </tr> <tr> <td>view_mountains_class_3</td> <td>The amount of visible mountains of UN mountain class 3</td> </tr> <tr> <td>view_mountains_class_4</td> <td>The amount of visible mountains of UN mountain class 4</td> </tr> <tr> <td>view_mountains_class_5</td> <td>The amount of visible mountains of UN mountain class 5</td> </tr> <tr> <td>view_mountains_class_6</td> <td>The amount of visible mountains of UN mountain class 6</td> </tr> <tr> <td>view_railway_tracks</td> <td>The amount of visible railway_tracks</td> </tr> <tr> <td>view_site</td> <td>The amount of visible site</td> </tr> <tr> <td>view_sky</td> <td>The amount of visible sky</td> </tr> <tr> <td>view_tertiary_streets</td> <td>The amount of visible tertiary_streets</td> </tr> <tr> <td>view_secondary_streets</td> <td>The amount of visible secondary_streets</td> </tr> <tr> <td>view_primary_streets</td> <td>The amount of visible primary_streets</td> </tr> <tr> <td>view_pedestrians</td> <td>The amount of visible pedestrians</td> </tr> <tr> <td>view_highways</td> <td>The amount of visible highways</td> </tr> <tr> <td>view_water</td> <td>The amount of visible water</td> </tr> </tbody> </table> Sun Sun simulations help to understand the impact of solar radiation on the object. The outcome of the sun simulations helps to identify surfaces that have great solar potential. Sun simulations are defined by the amount of solar radiation on each individual hexagon from the analyzed object. The sun simulation not only includes direct sun but also considers scattered light. The sun simulation values are given in Kilolux (klx). Simulations are performed for the days of the summer solstice, winter solstice, and the vernal equinox. Each of the following dimensions is provided using the room-wise aggregations' min, max, mean, std, median, p20, and p80. For instance, column <code>sun_201806211200_median</code> describes the median amount of direct daylight received on the positions in the area. Vernal Equinox <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201803210800</td> <td>Daylight at 08:00 on 21st of March</td> </tr> <tr> <td>sun_201803211000</td> <td>Daylight at 10:00 on 21st of March</td> </tr> <tr> <td>sun_201803211200</td> <td>Daylight at 12:00 on 21st of March</td> </tr> <tr> <td>sun_201803211400</td> <td>Daylight at 14:00 on 21st of March</td> </tr> <tr> <td>sun_201803211600</td> <td>Daylight at 16:00 on 21st of March</td> </tr> <tr> <td>sun_201803211800</td> <td>Daylight at 18:00 on 21st of March</td> </tr> </tbody> </table> Summer Solstice <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201806210600</td> <td>Daylight at 06:00 on 21st of June</td> </tr> <tr> <td>sun_201806210800</td> <td>Daylight at 08:00 on 21st of June</td> </tr> <tr> <td>sun_201806211000</td> <td>Daylight at 10:00 on 21st of June</td> </tr> <tr> <td>sun_201806211200</td> <td>Daylight at 12:00 on 21st of June</td> </tr> <tr> <td>sun_201806211400</td> <td>Daylight at 14:00 on 21st of June</td> </tr> <tr> <td>sun_201806211600</td> <td>Daylight at 16:00 on 21st of June</td> </tr> <tr> <td>sun_201806211800</td> <td>Daylight at 18:00 on 21st of June</td> </tr> <tr> <td>sun_201806212000</td> <td>Daylight at 20:00 on 21st of June</td> </tr> </tbody> </table> Winter Solstice <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>sun_201812211000</td> <td>Daylight at 10:00 on 21st of December</td> </tr> <tr> <td>sun_201812211200</td> <td>Daylight at 12:00 on 21st of December</td> </tr> <tr> <td>sun_201812211400</td> <td>Daylight at 14:00 on 21st of December</td> </tr> <tr> <td>sun_201812211600</td> <td>Daylight at 16:00 on 21st of December</td> </tr> </tbody> </table> Noise / Window Noise Noise level and the distribution of elements from an area help to understand how an object is exposed to the acoustics of this area. The acoustic simulation calculates the noise intensity on each individual hexagon from the analyzed object considering traffic and train noise datasets. Adjacent buildings are considered noise-blocking elements. The values are expressed in dBA (decibels). Window Noise The noise per window of a given area is aggregated via <code>min</code> and <code>max</code>. For instance, <code>window_noise_train_day_max</code> represents the maximum amount of noise received on any window of the area. <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>window_noise_traffic_day</td> <td>The amount of noise received on the area’s windows from daytime car traffic</td> </tr> <tr> <td>window_noise_traffic_night</td> <td>The amount of noise received on the area’s windows from night-time car traffic</td> </tr> <tr> <td>window_noise_train_day</td> <td>The amount of noise received on the area’s windows from daytime train traffic</td> </tr> <tr> <td>window_noise_train_night</td> <td>The amount of noise received on the area’s windows from night-time train traffic</td> </tr> </tbody> </table> Area-Wise Noise The area-wise noise describes the amount of noise received from a noise source aggregated over the whole area in an unaggregated form. For instance, <code>noise_traffic_night</code> describes the dBA of noise received in the area from car traffic at night when propagating noise from all windows. <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>noise_traffic_day</td> <td>The amount of noise received in the area from daytime car traffic</td> </tr> <tr> <td>noise_traffic_night</td> <td>The amount of noise received in the area from night-time car traffic</td> </tr> <tr> <td>noise_train_day</td> <td>The amount of noise received in the area from daytime train traffic</td> </tr> <tr> <td>noise_train_night</td> <td>The amount of noise received in the area from night-time train traffic</td> </tr> </tbody> </table> Connectivity Centrality simulations help to analyze a floor plan, whether it’s a shopping mall and you want to identify prominent areas in order to select the most prominent spot or it’s an interior design circulation path and you want to determine open floor plan areas. Centrality simulations are done using topological measures that score grid cells by their importance as a part of a grid cell network. The distances and centralities are aggregated via min, max, mean, std, median, p20, and p80. For instance, <code>connectivity_balcony_distance_min</code> describes the shortest distance to the next balcony from the point closest to the balcony in the area. Distances <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>connectivity_room_distance</td> <td>Distance to the next area of type ROOM</td> </tr> <tr> <td>connectivity_living_dining_distance</td> <td>Distance to the next area of type LIVING_DINING</td> </tr> <tr> <td>connectivity_bathroom_distance</td> <td>Distance to the next area of type BATHROOM</td> </tr> <tr> <td>connectivity_kitchen_distance</td> <td>Distance to the next area of type KITCHEN</td> </tr> <tr> <td>connectivity_balcony_distance</td> <td>Distance to the next area of type BALCONY</td> </tr> <tr> <td>connectivity_loggia_distance</td> <td>Distance to the next area of type LOGGIA</td> </tr> <tr> <td>connectivity_entrance_door_distance</td> <td>Distance to the next apartment exit</td> </tr> </tbody> </table> Centralities <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>connectivity_eigen_centrality</td> <td>The Eigen-Centrality value</td> </tr> <tr> <td>connectivity_betweenness_centrality</td> <td>The Betweenness-Centrality value</td> </tr> <tr> <td>connectivity_closeness_centrality</td> <td>The Closeness-Centrality value</td> </tr> </tbody> </table> Location Properties In addition to the apartment-related data, we also provide simulation data on the climatic, and infrastructural characteristics of the locations. The file <code>locations.csv</code> contains the simulation data aggregated on a per-building basis. Each row contains the identifier <code>building_id</code> corresponding to the building ids referenced in <code>geometries.csv</code> and <code>simulations.csv</code>. Climate The climate features represent 39 simple features based on the spatial climate analysis of Meteo Swiss as derived from <a href="https://www.meteoswiss.admin.ch/climate/the-climate-of-switzerland/spatial-climate-analyses.html.">MeteoSwiss</a>.  Each column is formatted as <code>climate_<category>_<period>. </code>For instance, the column <code>climate_tnorm_january</code>  describes the monthly mean temperature in degrees Celsius (from the norm period of 1991-2020) at the location of the building. The aggregation methods vary per simulation category and are described in detail below. Temperature Normals <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_tnorm_year</td> <td>The yearly mean temperature in degrees Celsius of the current norm period from 1991 to 2020 (TnormY9120)</td> </tr> <tr> <td>climate_tnorm_january</td> <td>The monthly mean temperature in January in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tnorm_februry</td> <td>The monthly mean temperature in February in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_tnorm_december</td> <td>The monthly mean temperature in December in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tminnorm_january</td> <td>The monthly minimum temperature in January in degrees Celsius of the current norm period from 1991 to 2020 (TminnormM9120)</td> </tr> <tr> <td>...</td> <td> </td> </tr> <tr> <td>climate_tminnorm_december</td> <td>The monthly minimum temperature in December in degrees Celsius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>climate_tmaxnorm_january</td> <td>The monthly maximum temperature in January in degrees Celcius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> <tr> <td>...</td> <td> </td> </tr> <tr> <td>climate_tmaxnorm_december</td> <td>The monthly maximum temperature in December in degrees Celcius of the current norm period from 1991 to 2020 (TnormM9120)</td> </tr> </tbody> </table> Sunshine Duration Normals <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_snorm_year</td> <td>The yearly mean relative sunshine duration in percent of the current norm period from 1991 to 2020 (SnormY9120). Relative sunshine duration (RSD) is the ratio between the effective sunshine duration and the duration maximally possible if no clouds were covering the sun. A period with sunshine is defined as a period when the direct solar irradiance exceeds 200 W/m²</td> </tr> <tr> <td>climate_snorm_january</td> <td>The monthly mean relative sunshine duration for January in percent of the current norm period</td> </tr> <tr> <td>climate_snorm_februry</td> <td>The monthly mean relative sunshine duration for February in percent of the current norm period</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_snorm_december</td> <td>The monthly mean relative sunshine duration for December in percent of the current norm period</td> </tr> </tbody> </table> Precipitation Normals <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>climate_rnorm_year</td> <td>The yearly mean precipitation in mm of the current norm period  (RnormY9120)</td> </tr> <tr> <td>climate_rnorm_january</td> <td>The monthly mean precipitation for January in mm of the current norm period  (RnormM9120)</td> </tr> <tr> <td>climate_rnorm_februry</td> <td>The monthly mean precipitation for February in mm of the current norm period  (RnormM9120)</td> </tr> <tr> <td>...</td> <td>...</td> </tr> <tr> <td>climate_rnorm_december</td> <td>The monthly mean precipitation for December mm of the current norm period  (RnormM9120)</td> </tr> </tbody> </table> 10-Minute Walkshed Infrastructure Based on OpenStreetMap data and its tagging system we counted all 465 tags (key and value tuples as listed here: https://wiki.openstreetmap.org/wiki/Map_features) which can be reached within a 10-minute walk from the location of the building. Each column is formatted as <code>walkshed_<poi_category>_<poi_type>. </code>For instance, the column <code>walkshed_shop_coffee</code>  describes the number of coffee shops located within 10 minutes of walking from the building. The following is an excerpt of support categories and their corresponding types. <ul> <li><code>shop: antique, art, ...</code></li> <li><code>amenity: art, atm, ...</code></li> <li><code>tourism: alpine, attraction, ...</code></li> <li><code>leisure: amusement, beach, ...</code></li> <li><code>healthcare: clinic, dentist, ...</code></li> <li><code>historic: archaeological, battlefield, ...</code></li> <li><code>ariaelway: station</code></li> </ul> Location Ratings The location ratings, provided by <a href="https://en.fpre.ch/">Fahrländer Partner AG</a>, give insights into the living situation at locations in which the buildings are situated. The file location_ratings.csv provides the following information: <table> <thead> <tr> <th>dimension</th> <th>description</th> </tr> </thead> <tbody> <tr> <td>location_rating_MIKRAT_W</td> <td>Living situation - Overall (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_IMAGE_W</td> <td>Living situation - Image (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_DL_W</td> <td>Living situation - Service Quality (1.0=worst, 5.0=best)</td> </tr> <tr> <td>location_rating_FZ_W</td> <td> Living situation - Leisure Quality (1.0=worst, 5.0=best) </td> </tr> <tr> <td>location_rating_NASE_W_DOM</td> <td>The most dominant segment of demand: 1 Rural-traditional 2 Modern worker 3 Transitional-alternative 4 Traditional middle class 5 Liberal middle class 6 Established alternative 7 Upper middle class 8 Professional elite 9 Urban elite 10 Unknown <a href="https://en.fpre.ch/marktdaten/nachfragersegmente/nachfragersegmente-im-wohnungsmarkt/">More Information</a></td> </tr> <tr> <td>location_rating_FGFRQZ</td> <td> The mean number of pedestrians per hour throughout a day between 7 am and 8 pm of an average working day. 1 <50 2 50-100 3 100-200 4 200-500 5 >500 </td> </tr> </tbody> </table>

opencc-by-4.0May 2023View details →

SERVIR RTC Comparison Geolocation Points and Results

These datasets include point locations and quality descriptions for the geolocation analysis section of the Synthetic Aperture Radar (SAR) radiometric terrain correction (RTC) comparison project led by NASA-USAID SERVIR. 'True' points were collected using DigitalGlobe high resolution MAXAR imagery. The geolocation measurement error for each location was compared across 7 analysis ready SAR products at 10 global locations and measured using ArcMap Desktop. SAR Analysis Ready Data software/methods compared: <ul> <li>RTC: GAMMA, SNAP, ISCE-2</li> <li>GTC in Google Earth Engine</li> <li>GRD in Google Earth Engine</li> </ul>

opencc-by-4.0Aug 2024View details →

Drug Repurposing Central Portal Usage and Geolocation Statistics

Record-level usage and geolocation statistics by country and organization for the Drug Repurposing Central portal. Covered time frame is from October 2021 to August 2024.

dryad40/100

Double-tagging scores of seabirds reveals that light-level geolocator accuracy is limited by species idiosyncrasies and equatorial solar profiles

Open the record for dataset details and reuse information.

publicAug 2021View details →

dryad36/100

Geolocators lead to better measures of timing and renesting in Black-tailed Godwits and reveal the bias of traditional observational methods

Long‐term population studies can identify changes in population dynamics over time. However, to realize meaningful conclusions, these studies rely on accurate measurements of individual traits and population characteristics. Here, we evaluate the accuracy of the observational methods used to measure reproductive traits in individually marked black‐tailed godwits (Limosa limosa limosa). By comparing estimates from traditional methods with data obtained from light‐level geolocators, we provide an accurate estimate of the likelihood of renesting in godwits and the repeatability of the lay dates of first clutches. From 2012 – 2018, we used periods of shading recorded on the light‐level geolocators carried by 68 individual godwits to document their nesting behaviour. We then compared these estimates to those simultaneously obtained by our long‐term observational study. We found that among recaptured geolocator‐carrying godwits, all birds renested after a failed first clutch, regardless of the date of nest loss or the number of days already spent incubating. We also found that 43% of these godwits laid a second replacement clutch after a failed first replacement, and that 21% of these godwits renested after a hatched first clutch. However, the observational study correctly identified only 3% of the replacement clutches produced by geolocator‐carrying individuals and designated as first clutches a number of nests that were actually replacement clutches. Additionally, on the basis of the observational study, the repeatability of lay date was 0.24 (95% CI 0.17 – 0.31), whereas it was 0.54 (95% CI 0.28 – 0.75) using geolocator‐carrying individuals. We use examples from our own and other godwit studies to illustrate how the biases in our observational study discovered here may have affected the outcome of demographic estimates, individual‐level comparisons, and the design, implementation, and evaluation of conservation practices. These examples emphasize the importance of improving and validating field methodologies and show how the addition of new tools can be transformational.

opencc-zeroMar 2020View details →

opencc-by-4.0Sep 2024View details →

GeoLocator Data Package: South African Woodland Kingfisher

This repository contains the raw data and the trajectory information generated with the GeoPressureR workflow, following the <a href="https://raphaelnussbaumer.com/GeoLocator-DP/">GeoLocator Data Package standard</a>. The more complete code used to generate this datapackage can be found on the Github Repository <a href="https://github.com/Rafnuss/WoodlandKingfisher">Rafnuss/WoodlandKingfisher</a>.  It contains 5 tags equipped on Woodland Kingfisher in Mogalakwena, Limpopo, South Africa between 2017-2020.

opencc-by-4.0Jan 2024View details →

Data and code for the paper "Geolocating Bees by Translating the Waggle Dance Into Spatial Coordinates"

The dataset contains the database storing the visual decoding of 10 videos of bees in an observation hive (database.zip). The folder "derived data.zip" contains several files derived with code and GIS tools to obtain the results presented in the paper. The videos are available in the "videos.zip" file. Finally, the Python script "waggle_dance_annulus.py" is the code that generates the box-plot like annulus geometry for dances.

opencc-by-4.0Mar 2022View details →

GeoDAR: Georeferenced global Dams And Reservoirs dataset for bridging attributes and geolocations

Documented March 19, 2023 !!NEW!!! GeoDAR reservoirs were registered to the drainage network! Please see the auxiliary data "<a href="../records/7750736">GeoDAR-TopoCat</a>" at <a href="../records/7750736">https://zenodo.org/records/7750736</a>. "GeoDAR-TopoCat" contains the drainage topology (reaches and upstream/downstream relationships) and catchment boundary for each reservoir in GeoDAR, based on the algorithm used for Lake-TopoCat (doi:10.5194/essd-15-3483-2023).   Documented April 1, 2022 Citation Wang, J., Walter, B. A., Yao, F., Song, C., Ding, M., Maroof, A. S., Zhu, J., Fan, C., McAlister, J. M., Sikder, M. S., Sheng, Y., Allen, G. H., Crétaux, J.-F., and Wada, Y.: GeoDAR: georeferenced global dams and reservoirs database for bridging attributes and geolocations. Earth System Science Data, 14, 1869–1899, 2022, https://doi.org/10.5194/essd-14-1869-2022. Please cite the reference above (which was fully peer-reviewed), NOT the preprint version. Thank you.   Contact Dr. Jida Wang, jidawang@ksu.edu, gdbruins@ucla.edu   Data description and components Data folder “GeoDAR_v10_v11” (.zip) contains two consecutive, peer-reviewed versions (v1.0 and v1.1) of the Georeferenced global Dams And Reservoirs (GeoDAR) dataset: <ul> <li>GeoDAR_v10_dams (in both shapefile format and the comma-separated values (csv) format): GeoDAR version 1.0, including 22,560 dam points georeferenced based on the World Register of Dams (WRD), the International Commission on Large Dams (ICOLD; <a href="https://www.icold-cigb.org">https://www.icold-cigb.org</a>; last access on March 13th, 2019).</li> <li>GeoDAR_v11_dams (in both shapefile and csv): GeoDAR version 1.1 dam points, including 24,783 dams which harmonized GeoDAR_v10_dams and the Global Reservoir and Dam Database (GRanD) v1.3 (Lehner et al., 2011).</li> <li>GeoDAR_v11_reservoirs (in shapefile): GeoDAR version 1.1 reservoirs, including 21,515 reservoir polygons retrieved by associating GeoDAR_v11_dams with GRanD v1.3 reservoirs, HydroLAKES v1.0 (Messager et al., 2016), and the UCLA Circa 2015 Lake Inventory (Sheng et al., 2016). The reservoir retrieval follows a one-to-one relationship between dams and reservoirs.</li> </ul> As by-products of GeoDAR harmonization, folder “GeoDAR_v10_v11” also contains: <ul> <li>GRanD_v13_issues.csv: This file contains the original records of all 7,320 dam points in GRanD v1.3, with 94 of them marked by our identified issues and suggested corrections. These 94 records are placed at the beginning of this table. They include 89 records showing possible georeferencing and/or attribute errors, and another 5 records documented as subsumed or replaced. Our added fields start from column BG and include: <ul> <li>“Issue”: main issue(s) of this record</li> <li>“Description”: more detailed explanation of the issue</li> <li>“Lat_corrected”: suggested correction for latitude (if any) in decimal degree</li> <li>“Lon_corrected”: suggested correction for longitude (if any) in decimal degree</li> <li>“Correction_source”: correction source(s)</li> <li>“Harmonized”: whether this GRanD dam was harmonized in GeoDAR v1.1 and the reason.</li> </ul> </li> <li>Wada_et_al_2017_harmonized.csv: This csv file contains the original records of all 139 georeferenced large dams/reservoirs in Wada et al. (2017; doi:10.1007/s10712-016-9399-6), with our revised storage capacities and spatial coordinates for data harmonization. Our added fields start from column E and include: <ul> <li>Revised_capacity_km3: Our revised reservoir storage capacity in cubic kilometers used for harmonization</li> <li>Revised_lat: Revised latitude in decimal degree</li> <li>Revised_lon: Revised longitude in decimal degree</li> <li>Verification_notes: Description of the issues, verification sources, and other information used for harmonization.</li> </ul> </li> </ul>   Attribute description <table> <tbody> <tr> <td> Attribute </td> <td> Description and values </td> </tr> <tr> <td> v1.0 dams (file name: GeoDAR_v10_dams; format: comma-separated values (csv) and point shapefile) </td> </tr> <tr> <td> id_v10 </td> <td> Dam ID for GeoDAR version 1.0 (type: integer). Note this is not the same as the International Code in ICOLD WRD but is linked to the International Code via encryption. </td> </tr> <tr> <td> lat </td> <td> Latitude of the dam point in decimal degree (type: float) based on datum World Geodetic System (WGS) 1984. </td> </tr> <tr> <td> lon </td> <td> Longitude of the dam point in decimal degree (type: float) on WGS 1984. </td> </tr> <tr> <td> geo_mtd </td> <td> Georeferencing method (type: text). Unique values include “geo-matching CanVec”, “geo-matching LRD”, “geo-matching MARS”, “geo-matching NID”, “geo-matching ODC”, “geo-matching ODM”, “geo-matching RSB”, “geocoding (Google Maps)”, and “Wada et al. (2017)”. Refer to Table 2 in Wang et al. (2022) for abbreviations. </td> </tr> <tr> <td> qa_rank </td> <td> Quality assurance (QA) ranking (type: text). Unique values include “M1”, “M2”, “M3”, “C1”, “C2”, “C3”, “C4”, and “C5”. The QA ranking provides a general measure for our georeferencing quality. Refer to Supplementary Tables S1 and S3 in Wang et al. (2022) for more explanation. </td> </tr> <tr> <td> rv_mcm </td> <td> Reservoir storage capacity in million cubic meters (type: float). Values are only available for large dams in Wada et al. (2017). Capacity values of other WRD records are not released due to ICOLD’s proprietary restriction. Also see Table S4 in Wang et al. (2022). </td> </tr> <tr> <td> val_scn </td> <td> Validation result (type: text). Unique values include “correct”, “register”, “mismatch”, “misplacement”, and “Google Maps”. Refer to Table 4 in Wang et al. (2022) for explanation. </td> </tr> <tr> <td> val_src </td> <td> Primary validation source (type: text). Values include “CanVec”, “Google Maps”, “JDF”, “LRD”, “MARS”, “NID”, “NPCGIS”, “NRLD”, “ODC”, “ODM”, “RSB”, and “Wada et al. (2017)”. Refer to Table 2 in Wang et al. (2022) for abbreviations. </td> </tr> <tr> <td> qc </td> <td> Roles and name initials of co-authors/participants during data quality control (QC) and validation. Name initials are given to each assigned dam or region and are listed generally in chronological order for each role. Collation and harmonization of large dams in Wada et al. (2017) (see Table S4 in Wang et al. (2022)) were performed by JW, and this information is not repeated in the qc attribute for a reduced file size. Although we tried to track the name initials thoroughly, the lists may not be always exhaustive, and other undocumented adjustments and corrections were most likely performed by JW. </td> </tr> <tr> <td> v1.1 dams (file name: GeoDAR_v11_dams; format: comma-separated values (csv) and point shapefile) </td> </tr> <tr> <td> id_v11 </td> <td> Dam ID for GeoDAR version 1.1 (type: integer). Note this is not the same as the International Code in ICOLD WRD but is linked to the International Code via encryption. </td> </tr> <tr> <td> id_v10 </td> <td> v1.0 ID of this dam/reservoir (as in id_v10) if it is also included in v1.0 (type: integer). </td> </tr> <tr> <td> id_grd_v13 </td> <td> GRanD ID of this dam if also included in GRanD v1.3 (type: integer). </td> </tr> <tr> <td> lat </td> <td> Latitude of the dam point in decimal degree (type: float) on WGS 1984. Value may be different from that in v1.0. </td> </tr> <tr> <td> lon </td> <td> Longitude of the dam point in decimal degree (type: float) on WGS 1984. Value may be different from that in v1.0. </td> </tr> <tr> <td> geo_mtd </td> <td> Same as the value of geo_mtd in v1.0 if this dam is included in v1.0. </td> </tr> <tr> <td> qa_rank </td> <td> Same as the value of qa_rank in v1.0 if this dam is included in v1.0. </td> </tr> <tr> <td> val_scn </td> <td> Same as the value of val_scn in v1.0 if this dam is included in v1.0. </td> </tr> <tr> <td> val_src </td> <td> Same as the value of val_src in v1.0 if this dam is included in v1.0. </td> </tr> <tr> <td> rv_mcm_v10 </td> <td> Same as the value of rv_mcm in v1.0 if this dam is included in v1.0. </td> </tr> <tr> <td> rv_mcm_v11 </td> <td> Reservoir storage capacity in million cubic meters (type: float). Due to ICOLD’s proprietary restriction, provided values are limited to dams in Wada et al. (2017) and GRanD v1.3. If a dam is in both Wada et al. (2017) and GRanD v1.3, the value from the latter (if valid) takes precedence. </td> </tr> <tr> <td> har_src </td> <td> Source(s) to harmonize the dam points. Unique values include “GeoDAR v1.0 alone”, “GRanD v1.3 and GeoDAR 1.0”, “GRanD v1.3 and other ICOLD”, and “GRanD v1.3 alone”. Refer to Table 1 in Wang et al. (2022) for more details. </td> </tr> <tr> <td> pnt_src </td> <td> Source(s) of the dam point spatial coordinates. Unique values include “GeoDAR v1.0”, “original GRanD”, “adjusted GRanD” (meaning the original dam point location in GRanD has been adjusted to improve the accuracy), and “corrected GRanD” (meaning the original point in GRanD was misplaced and has been corrected). Also see Table S5 in Wang et al. (2022). </td> </tr> <tr> <td> qc </td> <td> Roles and name initials of co-authors/participants during data QC, validation, and other manual operations. Name initials are given to each assigned dam or region and are listed generally in chronological order for each role. Correction of GRanD (see Table S5 in Wang et al. (2022)) and reservoir polygon QC were performed by JW, and this information is not repeated in the qc attribute to reduce the file size. Although we tried to track the name initials thoroughly, the lists may not be always exhaustive, and other undocumented adjustments and corrections were most likely performed by JW. </td> </tr> <tr> <td> v1.1 reservoirs (file name: GeoDAR_v11_reservoirs; format: polygon shapefile) </td> </tr> <tr> <td> plg_src </td> <td> Source of the retrieved reservoir polygon (type: text). Unique values include “GRanD v1.3”, “HydroLAKES v1.0”, and “UCLA Circa 2015”. Refer to Table 1 in Wang et al. (2022) for more details. </td> </tr> <tr> <td> plg_a_km2 </td> <td> Area of the retrieved reservoir polygon in square kilometres (calculated based on the cylindrical equal area projection on datum WGS 1984). </td> </tr> <tr> <td> All other attributes in v1.1 dams. </td> </tr> </tbody> </table>   Data and code availability GeoDAR v1.0 (dam points) and v1.1 (both dam points and reservoir polygons) are available under the Creative Commons Attribution 4.0 International (CC-BY 4.0) license (<a href="https://creativecommons.org/licenses/by/4.0">https://creativecommons.org/licenses/by/4.0</a>).  Any user who would like to link GeoDAR features to the proprietary WRD attributes the user has purchased in advance from ICOLD should contact the corresponding author JW. Python scripts for geo-matching, geocoding, and reservoir assignment are available at <a href="https://github.com/surf-hydro/georeferencing-ICOLD-dams-and-reservoirs">https://github.com/surf-hydro/georeferencing-ICOLD-dams-and-reservoirs</a>. We request users who adapt or use the scripts to cite Wang et al. (2022). We also request users to cite Wang et al. (2022) if they use our identified issues or suggested corrections for GRanD v1.3 (as provided in “GRanD_v13_issues.csv”).   Disclaimer GeoDAR v1.0 and v1.1 contain knowledge derived from ICOLD WRD (<a href="https://www.icold-cigb.org/GB/world_register/acknowledgements_wrd.asp">https://www.icold-cigb.org/GB/world_register/acknowledgements_wrd.asp</a>) but release no original values of the proprietary WRD attributes (except the storage capacities of a few large dams used to verify/correct Wada et al. (2017); see Table S4 in Wang et al. (2022)). The production and dissemination of GeoDAR abide by ICOLD’s legal policies (<a href="https://www.icold-cigb.org/GB/legal.asp">https://www.icold-cigb.org/GB/legal.asp</a>) and were approved by ICOLD’s Central Office. GeoDAR v1.0 represents an initial effort of georeferencing WRD at the global scale. The resultant dam distribution may be skewed towards regions where georeferencing sources are more abundant, and therefore, may not accurately reflect the distribution of all WRD records. The authors are not responsible for any consequence arising from this limitation. GeoDAR v1.1 absorbed most of the spatial features (i.e., dam point coordinates and reservoir polygons) in GRanD v1.3. To acknowledge the originality of GRanD, we request users to cite Lehner et al. (2011) if they only use the subset of GeoDAR v1.1 from GRanD alone. If the user adopts the spatial coordinates we corrected for GRanD (see “GRanD_v13_issues.csv”), we recommend users citing Wang et al. (2022) as well. The source of each spatial feature in GeoDAR v1.1 is specified in the attributes “har_src” and “pnt_src” for dam points and the attribute “plg_src” for reservoir polygons. For any questions about data citation, please contact the corresponding author JW. Authors of this paper claim no responsibility or liability for any consequences related to the use, citation, or dissemination of GeoDAR.   Other notes We provide another auxiliary folder “GeoDAR_beta_peer_review” (.zip), which stores the versions of GeoDAR before the completion of peer review with ESSD. We here keep these earlier GeoDAR versions on file, but since improvements and corrections were made during the peer review process, we do NOT recommend any application of these earlier versions. Instead, please use the fully peer-reviewed versions in folder “GeoDAR_v10_v11”.  Please also see the readme files in each of the folders.

dryad36/100

Cerulean Warbler light-level geolocator data

The Cerulean Warbler (Setophaga cerulea) is a declining Nearctic-Neotropical migratory species of conservation concern. Implementing full annual cycle conservation strategies to facilitate recovery has been difficult because we know little about the migratory period or connectivity between North American breeding regions and South American non-breeding regions. Between 2014–2017, we deployed geolocators on 282 males at 13 study sites throughout the species' range with the objectives of a) evaluating the strength of connectivity between breeding and non-breeding regions; b) identifying approximate routes and stopover regions, and c) documenting migration phenology. We retrieved migration data from 28 birds and most (14/15; 93%) Appalachian-breeders overwintered in the Colombian/Venezuelan Andes, whereas 5/7 (71%) breeders from the Ozarks overwintered in the southwestern portion of their non-breeding range in Peru/Ecuador. During spring migration, over a 26 d ± 1.2 (SE) period, birds (n = 23) staged at multiple stopover locations between Panama and southern Mexico. The migratory periods were substantial and approximately equal in duration: 38 ± 2 d (SE) in fall and 42 d ± 2 (SE) in spring. Based on the observed connectivity pattern, conservation of Appalachian breeding populations should focus on forest protection and restoration in premontane/lower montane forests of Colombia and Venezuela, whereas Ozark breeding population conservation should focus efforts in Ecuador and Peru. Additionally, protections of forests used by ceruleans during stopovers throughout Central America and southern Mexico, in southeastern United States coastal areas, and in the Mississippi Alluvial Valley are likely to have high conservation value for this species.

opencc-zeroAug 2022View details →

dryad36/100

Data for: Geolocation and immersion loggers reveal year-round residency and consequent nutrient deposition rates of adult red-footed boobies in the Chagos Archipelago, tropical Indian Ocean

Bio-logging has revealed much about high-latitude seabird migratory strategies, but migratory behaviour in tropical species may differ, with implications for understanding nutrient deposition. Here we use combined light-level and saltwater immersion loggers to study the year-round movement behaviour of adult red-footed boobies (Sula sula rubripes) from the Chagos Archipelago, tropical Indian Ocean to assess migratory movements and estimate nutrient deposition rates based on the number of days they spent ashore. Light levels suggest that red-footed boobies are resident in the Chagos Archipelago year-round, although there are large latitudinal errors this close to the equator. Immersion data also indicate residency with tracked birds returning to land every one or two days. Spending an average of 79.86 ± 2.80 days and 280.84 ± 2.64 nights per year on land allows us to estimate that the 21,670 pairs of red-footed boobies deposit 37.34 ± 0.56 tonnes year-1 of guano-derived nitrogen throughout the archipelago. Our findings have implications for tropical seabird conservation and phylogenetics, as well as for assessing the impact of seabird nutrients on coral reef ecosystems.

opencc-zeroApr 2024View details →