-180

180

90

-90

1936-03-01

2016-06-09

Kingdom

Animalia

Phylum

Chordata

Class

Aves

Order

Accipitriformes

Order

Passeriformes

Order

Charadriiformes

Order

Anseriformes

Order

Coraciiformes

Order

Galliformes

Order

Apodiformes

Order

Pelecaniformes

Order

Strigiformes

Order

Procellariiformes

Order

Caprimulgiformes

Order

Ciconiiformes

Order

Cuculiformes

Order

Columbiformes

Order

Piciformes

Order

Falconiformes

Order

Gruiformes

Order

Otidiformes

Order

Suliformes

Order

Phoenicopteriformes

Order

Podicipediformes

Order

Pteroclidiformes

Order

Bucerotiformes

ADMINISTRATIVE_POINT_OF_CONTACT

The original file was downloaded from the ICNF geocatalog ( https://geocatalogo.icnf.pt/catalogo_tema2.html) in shapefile format and was imported into a GIS program, where it was converted to WGS84 and exported in CSV format. The original dataset contained codes in most of its fields, according to the EURING Exchange Code 2000+ v117- January 2018 rules. To facilitate their interpretation, their meanings have been added followed by the original code in square brackets. Original dataset fields that were not converted to Darwin Core have been added to the dynamicProperties. We present below the summary of the translation of codes and respective decisions.

Using two distinct applications in Java, the following information was obtained based on coordinates: timezone (considering the date, due to DST), country, countryCode, stateProvince and municipality.

With a third application and using the list of species in the database as a basis, the following fields were collected: kingdom, phylum, class, order, family, genus, specificEpithet, infraspecificEpithet, acceptedNameUsage and scientificNameAuthorship. After this collection, the scientific names were compared with the names present in “Aves de Portugal” ( http://www.avesdeportugal.info/avesdeportugal-cient-alf.html), and the different names were updated to the most recent taxonomy, based on Avibase ( https://avibase.bsc-eoc.org/avibase.jsp?lang=EN). The taxonomicStatus column was introduced to notify the user of spelling errors in the original taxonomy or updates, present in their most current form in the acceptedNameUsage field.

The lifeStage column was created based on the original "age" column; however, it was decided to leave the original column present in the dynamicProperties to be more informative. The codes were translated as follows:

0 – “blank”; 1 – juvenile; Every other code – adult.

In samplingProtocol is described the methodology used in the capture of birds, and eventRemarks field contains information regarding the use of bait in the bird capture methodology. In occurrenceRemarks, the information regarding the condition and circumstance has been added. In the case of ring destroyed or lost, this same note was added, as well as when the original lifeStage value was unlikely, regarding the reference values (Euring Code). In the case of line 332203, the previous ring number of the respective bird was also added (the only case in the dataset in which this notification occurred).

The eventTime field resulted from the conversion of the original “time” field. Values alone (e.g. 1 or 2) were converted to hourly intervals (1:00-1:59) after checking the preferred time of activity of the recorded species. Null or unregistered values remain empty, but the timezone was still added, in ISO format. Some original date values were impossible to translate (recorded in the verbatimEventDate field), but some (e.g. 3013) were easily convertible (e.g. 2013) so the eventDate, day, month and year fields were filled in with plausible values.

The field coordinateUncertaintyInMeteres resulted from the conversion of the original field “coord_ac”. However, when the original value was 0 (which by the translation of the EURING code corresponded to the perfect match with the location of the coordinates), the value of 100 meters was placed because it was reasonable lower limit before 2020-05-01 of a GPS reading under good conditions (Darwin Core suggestion) because all dates are before 2020: 0 – 100m; 1 – 5000m; 2 – 10000m; 9 – “blank”.

The island and islandGroup fields were created based on coordinates, compared to a shapefile with islands worldwide. A match was made between the points and this shapefile, and the names of the respective islands were collected. After this collection, the name of the respective archipelago was added, when it existed. Due to possible projection deviations, and the fact that some coordinates have been collected at sea (despite being next to islands), there may be information actually collected on islands and whose fields island and islandGroup are not filled.

The original column with locality contained coding errors. To correct it, it was necessary to select the locations with an error and do a search for the correct names. Locality names like #REF, UNKNOWN and others impossible to translate, were left in the verbatimLocality field but blank in the locality field. After this cleanup, the database was imported into OpenRefine and using cluster algorithms, similar names of localities were grouped and written equally (e.g. LOURINHA LOURINHÃ -> LOURINHÃ).

Finally, the file was exported in CSV format with UTF-8 encoding.

The geographic scope of this study focuses mainly on birds ringed and recaptured in Portugal, but also all other countries where birds originally ringed in Portugal were recaptured.

The data collection is done in the application called "Ring Access", which is a programme for the management of ringing information, controls and ring retrieval. The data format is by principle EURING 2000 with some national adjustments. Several parameters can be saved, but not necessarily all of them have to be used.

The activity of bird ringing for scientific purposes is regulated by Decree-Law nº 140/99, of 24th April (article 18), as amended by Decree-Law nº 49/2005, of 24th February, which transposes into national legislation the Community Birds (Directive 2009/147/EC of 30th November, which revoked Directive 79/409/EEC) and Habitats (92/43/EC) Directives.

All initial data was inserted in a specific relational database built specifically for the project, which implemented several quality control methods. In the preparation of the dataset for GBIF publication, data consistency was verified using cluster algorithms using OpenRefine.