- API-users - lists.gbif.org

GBIF API changes - GRSciColl
by Marie Grosjean 30 Apr '24

30 Apr '24

Dear GBIF API users, We are changing the API to access and edit collection and institution entries in the Global Registry of Scientific Collections<https://scientific-collections.gbif.org/> (GRSciColl) (see the current documentation here<https://techdocs.gbif.org/en/openapi/v1/registry#/Collections>). These changes will affect scripts and website that use the GRSciColl part of the API, you will need to adapt them. Here are the changes: * The following fields will be discarded: indexHerbariorum, institution geographicDescription, institution taxonomicDescription, citesPermitNumber (https://github.com/gbif/registry/issues/545) * The following fields are lists: types, institutionalGovernances, catalogueUrls, apiUrls (https://github.com/gbif/registry/issues/550) * The following fields will be using vocabularies<https://techdocs.gbif.org/en/openapi/v1/vocabulary> instead of enumerations<https://techdocs.gbif.org/en/openapi/#enumerations>: types, institutionalGovernances, discipline, contentType, preservationType, accessionStatus (https://github.com/gbif/registry/issues/549) * The collection “geography” field is renamed “geographicCoverage” (https://github.com/gbif/registry/issues/551) * New fields are added: collection temporalCovergage, featuredImageUrl, featuredImageLicense (https://github.com/gbif/registry/issues/552) These changes are part of the implementation of the GRSciColl road map 2023/2024<https://scientific-collections.gbif.org/road-map>. You can learn more about the GRSciColl developments by watching our latest community call here<https://vimeo.com/936568304>. We will deploy those changes on the 20th of May 2024. Please let us know if you have any question. All the best, Marie -- Marie Grosjean (mgrosjean(a)gbif.org<mailto:mgrosjean@gbif.org>) Data Administrator GBIF Secretariat Universitetsparken 15 DK-2100 Copenhagen, DENMARK URL: http://www.gbif.org<http://www.gbif.org/>

1 0

API change: eventDate ranges
by Matthew Blissett 25 Jan '24

25 Jan '24

Dear GBIF API users, Last year we announced an upcoming change to how the GBIF API would handle ranges in the Darwin Core eventDate field. Date ranges formatted using the ISO 8601 standard will retain their meaning, and the API will return values like "2000-05" or "2007-11-13/2007-11-15". The changes have been visible on the test system, GBIF-UAT.org, since late September. We are currently reprocessing the data for GBIF.org, and expect to make the change visible tomorrow afternoon (around 24 hours from now). For more information, see the GitHub issue or Discourse discussion: → https://github.com/gbif/gbif-api/issues/4#issuecomment-1735378954/ → https://discourse.gbif.org/t/gbif-api-supporting-ranges-in-occurrence-event… If you find errors with how the eventDate field is processed, for example if processing has failed to handle a well-formatted eventDate, please give feedback in the usual way — with the link on the top right of the occurrence page. If you have a GitHub account, you can also create an issue (or comment on an existing issue) at https://github.com/gbif/portal-feedback/issues The new technical documentation website has a page on date and time interpretation: https://techdocs.gbif.org/en/data-processing/temporal-interpretation Tomorrow's deployment will also support the Darwin Core terms introduced last year, and allow searching using several paleontological terms. Thanks, Matt

1 0

API change proposal: supporting ranges in occurrence eventDate
by Matthew Blissett 26 Sep '23

26 Sep '23

Dear GBIF API users, /You might prefer to read this email on either GitHub or the community forum, as the formatting is probably better:/ // /GitHub issue discussion: https://github.com/gbif/gbif-api/issues/4#issuecomment-1385497157/ // /Community forum discussion: https://discourse.gbif.org/t/gbif-api-supporting-ranges-in-occurrence-event… A longstanding issue with the GBIF API is the interpretation and formatting of the Darwin Core term "eventDate". *Summary: instead of GBIF changing published |eventDate| values like |2009-03-18/2009-04-13| and |2010| to |2009-03-18| and |2010-01-01| respectively, we propose returning the values |2009-03-18/2009-04-13| and |2010| in the occurrence API and in downloads. Existing code/scripts that use the |eventDate| value may need to be updated.* The recommended best practise for the term is "use a date that conforms to ISO 8601-1:2019" (see https://dwc.tdwg.org/terms/#dwc:eventDate). ISO 8601-1:2019 supports date ranges, and some publishers provide these. Examples are |2000-05|, or |2007-11-13/2007-11-15|. GBIF's current interpretation changes date ranges like this to the first possible day in the range (|2000-05-01| and |2007-11-13|). At least 64 million occurrences are affected. <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#chang…> Change to date interpretation We propose changing the eventDate field in the GBIF API to support ISO 8601-1 date ranges. A range will be returned where one was provided by the publisher, either directly as a range in the |eventDate| field, or through a combination of the |year|, |month|, |day|, |startDayOfYear| and |endDayOfYear| fields. The data quality checks on dates will be improved to check for consistency between these fields: |eventDate|, |year|, |month|, |day|, |startDayOfYear| and |endDayOfYear|. These fields will only be populated if they are constant for the whole range of dates — a range spanning several days in January 2020 will have |year=2020|, |month=January| and |day=(Blank)|. |startDayOfYear| and |endDayOfYear| will also be present if the range is accurate to days. Examples: published event date intepreted eventDate int. year int. month int. day int. sdoy int. edoy 2023-01-13 2023-01-13 2023 1 13 13 13 2023-01 2023-01 2023 1 2023 2023 2023 2023-01-13/2023-01-14 2023-01-13/2023-01-14 2023 1 13 14 2023-01-13/14 2023-01-13/14 2023 1 13 14 2023-01/2023-02 2023-01/2023-02 2023 2023-01/02 2023-01/02 2023 2023/2024 2023/2024 2023-01-01/2023-12-31 2023-01-01/2023-12-31 2023 1 365 Other cases where we can unambiguously determine a date or date range will also be handled, for example a record with a |year| and |month| but no |eventDate|, or non-ISO dates like |January 2023|. <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#api-e…> API example: This record <https://api.gbif.org/v1/occurrence/1234530937> (portal link <https://www.gbif.org/occurrence/1234530937>) is published with |eventDate=2009-03-18/2009-04-13|, |year=2009|, |month=3|, |day=18|. We currently change the |eventDate|: "year":2009, "month":3, "day":18, "eventDate":"2009-03-18T00:00:00", With this proposal, we would preserve the |eventDate| but remove |day|, as it the event crosses several days: "year":2009, "month":3, "eventDate":"2009-03-18/2009-04-13", This record <https://api.gbif.org/v1/occurrence/2382954724> (portal link <https://www.gbif.org/occurrence/2382954724>) is published with |eventDate=2019-04-06T20:00:00/2019-04-10T05:00:00| and no separate |day|, |month| or |year| values. Currently, we process it to this: "year":2019, "month":4, "day":6, "eventDate":"2019-04-06T20:00:00", Instead, we propose returning this: "year":2019, "month":4, "eventDate":"2019-04-06T20:00:00/2019-04-10T05:00:00", "startDayOfYear":96, "endDayOfYear":100, <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#searc…> Searching The search and download APIs will be affected by this change. Occurrences will be returned if the occurrence date/date range is *completely within* the query date or date range. |Search: eventDate=2023-01-11 Record: eventDate=2023-01-11 -- included Record: eventDate=2023-01 -- EXCLUDED Record: eventDate=2023-01-11/12 -- EXCLUDED Search: eventDate=2023-01-11,2023-01-12 Record: eventDate=2023-01-11 -- included Record: eventDate=2023-01 -- EXCLUDED Record: eventDate=2023-01-11/12 -- included Search: eventDate=*,2023-01 (meaning "Before end of January 2023") Record: eventDate=2023-01-11 -- included Record: eventDate=2023-01 -- included Record: eventDate=2023-01-11/12 -- included Search: eventDate=2023-01,2023-01 (meaning "After start of January 2023 AND before end of January 2023") Search: eventDate=2023-01 (same meaning) Record: eventDate=2023-01-11 -- included Record: eventDate=2023-01 -- included Record: eventDate=2023-01-11/12 -- included | This implementation will avoid returning occurrences with eventDates like "2010/2021" in many queries. (There are millions of occurrences with large ranges like this.) <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#densi…> Density maps There is a year filter for the density/pixel maps. An occurrence from 2023-01 will be included, but an occurrence with an eventDate spanning more than a single year (like 2022-13-31/2023-01-01) will no longer be included. <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#quart…> Quarterly analytics, global/regional trends The quarterly analytics include calculations based on the individual dwc:year, dwc:month and dwc:day fields. The statistics will be affected where these values change or become blank. <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#rgbif…> rGBIF, PyGBIF Both libraries will be updated as necessary to support eventDate values containing a date range. <https://gist.github.com/MattBlissett/ff06599559ce86302a6e84d2e3e605ec#feedb…> Feedback We have delayed addressing this issue for a long time, primarily due to concerns about changing the existing behaviour of the API. However, it's also one of the most frequently requested improvements to GBIF's interpretation. If you are aware of software or systems which would have problems adapting to the proposed change, please let us know, either on this mailing list, the GitHub issue, the community forum or by email to me. We will alert users in the same places when the change is ready to be tested on the test system at api.gbif-uat.org, and when the change is to be made live on api.gbif.org. Thank you, Matt GitHub issue discussion: https://github.com/gbif/gbif-api/issues/4#issuecomment-1385497157 Community forum discussion: https://discourse.gbif.org/t/gbif-api-supporting-ranges-in-occurrence-event…

2 3

How to simple distribution maps
by Mauro Cavalcanti 29 Jul '23

29 Jul '23

Dear ALL, I have already spent some hours now attempting to generate simple distribution maps using the GBIF maps API ( https://www.gbif.org/developer/maps). I have seen the base map examples (https://tile.gbif.org/ui/) and the raster style demos (https://api.gbif.org/v2/map/demo.html), but could not understand how I could get just a simple distribution map, overlaid on a base map in Mercator projection and 'classic' GBIF style, as a PNG (or JPEG) image, *with a single API call* (that is, without css, javascript, etc.). Is this possible? Thanks in advance! With warmest regards, -- Dr. Mauro J. Cavalcanti E-mail: maurobio(a)gmail.com Web: https://github.com/maurobio "Life is complex. It consists of real and imaginary parts."

2 2

Maps API returning nothing
by Mauro Cavalcanti 28 Jul '23

28 Jul '23

Dear ALL, I have been trying the Maps API (https://www.gbif.org/developer/maps), but when attempting to run one of the demos at https://api.gbif.org/v2/map/occurrence/density/{z}/{x}/{y}@1x.png?taxonKey=… I keep getting back an empty ("400") image. What may be the problem? Thanks in advance for any assistance you can provide. With warmest regards, -- Dr. Mauro J. Cavalcanti E-mail: maurobio(a)gmail.com Web: https://github.com/maurobio "Life is complex. It consists of real and imaginary parts."

2 3

Re: [API-users] species match > missing blanks in taxa authorities
by Markus Döring 24 Oct '22

24 Oct '22

Hi Armand, If you take taxa broadly yes a lot as we need to merge many taxonomies into a single one. This is too much to describe here in detail, an overview is here: https://data-blog.gbif.org/post/gbif-backbone-taxonomy/ If it is on names only not so much. We try to prefer IPNI/ZooBank spellings. We show the authority year always with a comma and try to remove all nomenclatural or taxonomic annotations like "s.l." "comb.nov." from the authorship. If the primary source has no authorship or publication we try to augment that from secondary sources, which could also alter the meaning of the primary one. Named hybrids should receive a space after the hybrid marker. That is from the top of my head what is happening to names in the backbone, but likely I am have missed things. Markus On 24. Oct 2022, at 09:15, TURPEL Armand <Armand.TURPEL(a)mnhn.lu<mailto:Armand.TURPEL@mnhn.lu>> wrote: Hi Markus, Thanks for replying. Are there other modifications on taxa data from the gbif backbone side? Best wishes, Armand Von: Markus Döring <mdoering(a)gbif.org<mailto:mdoering@gbif.org>> Gesendet: vendredi 21 octobre 2022 13:22 An: TURPEL Armand <Armand.TURPEL(a)mnhn.lu<mailto:Armand.TURPEL@mnhn.lu>> Cc: informatics <informatics(a)gbif.org<mailto:informatics@gbif.org>> Betreff: Re: species match > missing blanks in taxa authorities Thanks Armand, we receive authorships in various forms from both the zoological and botanical code. Sometimes with sometimes without spaces in between initials and surnames. When we build the backbone we try to normalize authorships to have a consistent format, thereby those blanks everywhere. Best, Markus On 21. Oct 2022, at 10:12, TURPEL Armand <Armand.TURPEL(a)mnhn.lu<mailto:Armand.TURPEL@mnhn.lu>> wrote: Hello, For some reason I couldn’t post to the gbif api mailing list. Here the original post: ____________________________________________________________________ Von: TURPEL Armand Gesendet: vendredi 21 octobre 2022 10:09 An: 'api-users(a)lists.gbif.org<mailto:api-users@lists.gbif.org>' <api-users(a)lists.gbif.org<mailto:api-users@lists.gbif.org>> Betreff: species match > missing blanks in taxa authorities Hi While using the gbif api search backbone i noticed that some taxa authorities miss blanks. In the original data resource the blanks are present. Gbif remove some where the blanks. https://api.gbif.org/v1/species/match?name=Arthopyrenia%20dispersa Example : GBIF : Arthopyrenia dispersa J.Lahm ex Körb. COL : Arthopyrenia dispersa J. Lahm ex Körb. Species Fungorum : Arthopyrenia dispersa J. Lahm ex Körb. As you see the blank between J. and Lahm is missing. There are many taxon authorities where this is the case. Armand Turpel

1 0

orthoptera, amphibian and birds sounds
by Sylvain Ard 06 Oct '22

06 Oct '22

Hi, I want to know if you have in your database orthoptera, amphibian and birds sounds ? If yes please tell me how to view it in API and web interface. Thank you Best regards Sylvain Ard 0549507724 0778380991 sylvain.ard(a)gmail.com http://sylvain-ard.fr Entreprise individuelle SIRET : 80079243400022 Appt 26 Bât A Résidence Le Patio 83 rue de la Bugellerie 86000 Poitiers

1 0

Data user survey: help us assess the value of GBIF
by Kyle Copas 23 Jun '22

23 Jun '22

Dear GBIF colleagues, In the [Twenty-Year Review of GBIF][1] published in 2020, CODATA offered a recommendation (#4a) to commission a targeted study on "the monetary value of sharing biodiversity data and of the added value that data infrastructures provide to it." To that end, the Secretariat has recently commissioned Deloitte Access Economics to assess the economic value and impact of the GBIF network, its data and its services. We would very much like input from data users on this list. [This 10-minute survey for biodiversity data users][2] aims to learn more about how you access and apply GBIF-mediated data, along with other views and experiences you wish to share about any value you gain from the services we provide. The ideal respondents will already access GBIF's global services or (those of a GBIF partner or node) by downloading data, using an API, or accessing cloud-computing services. If you're willing to help us, please complete the survey before it close son Sunday, 17 July 2022, at 11.59pm GMT (UTC+1). If you have any questions about this work, please contact us at [communication(a)gbif.org][3]. You may direct specific questions about the survey to [gbifvaluationsurvey(a)deloitte.com.au][4]. Very best regards, Kyle [1]: https://doi.org/10.35035/ctzm-hz97 [2]: https://surveyapac.deloitte.com/jfe/form/SV_23JpuX4LK0ofHim [3]: mailto:communication@gbif.org [4]: mailto:gbifvaluationsurvey@deloitte.com.au ===== Kyle Copas Communications Manager +45 28 75 14 75 | office +45 35 32 14 75 | skype kylecopas GBIF Secretariat Universitetsparken 15 DK-2100 København Ø DENMARK https://www.gbif.org

1 0

plantnet
by Sylvain Ard 08 Jun '22

08 Jun '22

Hello, how to select photos of a certain plant of PlantNet, I specify that I want only PlantNet photos ? Thank you Best regards Sylvain Ard 0549507724 0778380991 sylvain.ard(a)gmail.com http://sylvain-ard.fr Entreprise individuelle SIRET : 80079243400022 Appt 26 Bât A Résidence Le Patio 83 rue de la Bugellerie 86000 Poitiers

2 4

Re: [API-users] DWC with "extra" images
by Matthew Cruz 03 May '22

03 May '22

Hi Matt, Yes, I did mean "multimedia.txt" and not "metadata.txt". Sorry for the confusion and thanks for seeing past it. I am very happy to learn that extra records in the extension files (media etc) are ignored and that there are no plans to change that. I was hoping for this because of the way we package our DWC file. Our occurrence data comes from our "Specify" database and pulled into the IPT server via a connection. However our multimedia/images are pulled into our "Specify" database via a feed from a separate image-server/database and then this table of data is also read by the IPT server via a connection. Under consideration is using this multimedia/image feed to populate a temporary Symbiota portal within which the occurrence data can be transcribed and entered. The occurrences will intentionally not be given a GUID since Symbiota is the source DB and rather is being used as a tool to prepare the data for import into our source DB which is "Specify". Therefore I was being faced with a question of if we were to put extra images in the "multimedia.txt" that do not have corresponding occurrence IDs yet if that would cause incorrect processing by how GBIF handles the DWC extraction. Therefore, learning that GBIF's algorithm to ignore extra records in extension files that do not match with a GUID in the "occurrence.txt" is great news! Thanks, Matthew ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 May 2022 17:34:13 +0200 > From: Matthew Blissett <mblissett(a)gbif.org> > To: api-users(a)lists.gbif.org > Subject: Re: [API-users] DWC with "extra" images > Message-ID: <08f90ede-83de-3305-339d-fc99b606d42c(a)gbif.org> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Matthew, > > (I think you probably mean a files like media.txt or multimedia.txt) > > In general, extra records in the extension files (media etc) are > ignored. We don't have any plans to change this. > > Cheers, > > Matt > > On 15/04/2022 17:36, Matthew Cruz wrote: > > What would happen in GBIF when processing a published DWC file if the > > metadata.txt file has an ID corresponding to an image, but that ID is > > not found in the occurrence.txt file? > > > > Does the image get ignored or published despite there being no > > corresponding metadata? > > > > What else can you tell me about this process? > > > > Thank you >

1 0