Skip to content

Commit

Permalink
Merge pull request #48 from gbif/translation_1.0
Browse files Browse the repository at this point in the history
New Crowdin updates
  • Loading branch information
kcopas committed Jan 19, 2022
2 parents 7454b16 + 5203c40 commit ab0458d
Show file tree
Hide file tree
Showing 12 changed files with 9,428 additions and 0 deletions.
134 changes: 134 additions & 0 deletions translations/0100-introduction.es.adoc

Large diffs are not rendered by default.

459 changes: 459 additions & 0 deletions translations/0200-elements-for-describing-a-location.es.adoc

Large diffs are not rendered by default.

778 changes: 778 additions & 0 deletions translations/0300-the-georeferencing-process.es.adoc

Large diffs are not rendered by default.

49 changes: 49 additions & 0 deletions translations/0400-collaborative-georeferencing.es.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
== Collaborative Georeferencing

The characteristics that make a <<georeference,georeferencing>> project collaborative are the aggregation of occurrence records from multiple participating groups (e.g. datasets, collections, institutions), the extraction of distinct <<locality,localities>> as the actual target of georeferencing, the standardization of the geography of the aggregated records to aid record grouping and assignment by geography.

Collaborative georeferencing, if done properly, can have definitive advantages over georeferencing alone. MaNIS (http://georeferencing.org/georefcalculator/docs/GeorefGuide.html[Wieczorek 2001^]) and Australia's Virtual Herbarium (https://www.anbg.gov.au/chah/avh/avh.html[ANBG 2018^]) found that collaborative georeferencing resulted in great efficiency gains, but that including validation checks afterwards by reviewing the records using collector and date, or looking at the records taxonomically to check for outliers, and other such <<data quality>> flags, is important. Advantages and disadvantages of collaborative georeferencing, adapted from http://georeferencing.org/manis/GeorefCollaboration021021.ppt[Wieczorek & Beaman 2002^] and https://doi.org/10.17161/bi.v1i0.7[Stein & Wieczorek 2004^] include:

*Advantages*

* Reduces overall cost of supplies (e.g. maps) – no duplication.
* Expands the pool of resources – geographic expertise and reference materials.
* Takes advantage of regional expertise, knowledge, language skills and resources.
* Increases georeferencing rates – economy of scale.
* Promotes standardization of methods.
* Increases skills in a community.
* Increases exposure and awareness inside and outside of a community - strengthens community relationships.
*Disadvantages*

* Vulnerable to procrastination, delays, uneven levels of training, expertise and commitment.
* Can distance the georeferencing process from useful primary resources (e.g. specimen labels and field notes).
* Introduces time sensitivity to the georeferencing process (locality information for the underlying occurrence records might be subject to changes during the georeferencing process that would render a different result).
* Data repatriation into the originating collection can be a difficult and time-consuming process.
* Requires project-level management.
* Requires a formalized validation process.
One of the greatest impediments to effective collaborative georeferencing is the absence of tools to easily <<repatriate, repatriate>> the georeferenced information back to the data sources (https://doi.org/10.3897/zookeys.209.3205[Barkwell and Murrell 2012^], https://doi.org/10.3897/biss.2.26479[Grant et al. 2018^]). A number of projects are working on this, especially <<GEOLocate>> in conjunction with the Symbiota platform (https://doi.org/10.3897/BDJ.2.e1114[Gries et al. 2014^]). It is hoped that this document will provide consistency of methodology and documentation and lead to more collaborative <<georeference,georeferencing>>.

Some organizations, such as DigiVol (https://digivol.ala.org.au/[Australian Museum n.d.^]) and Notes from Nature https://www.zooniverse.org/organizations/md68135/notes-from-nature[(Zooniverse n.d.)^] use crowdsourcing to <<georeference>>, whereas projects like CoGeo (part of GEOLocate, https://coge.geo-locate.org/[GEOLocate 2018^]), are more constrained in their participants.

[[digivol]]
=== DigiVol

The http://www.ala.org.au/[Atlas of Living Australia^], in collaboration with the http://australianmuseum.net.au/[Australian Museum^], developed DigiVol (http://volunteer.ala.org.au/[Australian Museum n.d.^]) to harness the power of online volunteers (also known as crowdsourcing) to digitize biodiversity data that is locked up in biodiversity collections, field notebooks and survey sheets. Although originally developed in Australia, DigiVol has many projects and expeditions from all over the globe. Not all DigiVol projects (called expeditions) include a <<georeference,georeferencing>> component, but some of them do, and there is no reason that there won’t be more in the future.

The Australian Museum has developed a guide for a mapping tool to use with DigiVol (https://volunteer.ala.org.au/data/volunteer/tutorials/Australian%20Museum%20Tutorials_Mapping%20Tool%20Tutorial.pdf[Edey n.d.^]). The mapping tool, however, has a number of features that we would not recommend. Default positions are given for the "center" of a number of Australian States without an appropriate associated <<uncertainty>> value. The uncertainty of the georeference is added by a pulldown menu that gives three options: 1km, 5km and 10km. Our recommendation would be to make <<uncertainty>> continuous–possibly by selection on the map, or calculated using the body of information in this document, the protocols of the {gqg}[Georeferencing Quick Reference Guide (Zermoglio et al. 2020)^], and the algorithms of the http://georeferencing.org/georefcalculator/gc.html[Georeferencing Calculator (Wieczorek & Wieczorek 2020)^].

=== Notes from Nature

The Notes from Nature project (https://www.notesfromnature.org/[Zooniverse n.d.^]) gives people the opportunity to make scientifically important contributions toward the goal of conserving and making available knowledge about natural and cultural heritage. "Every transcription that is completed brings us closer to filling gaps in our knowledge of global biodiversity and natural heritage". It is very similar to <<digivol,DigiVol>>. Currently, there are no <<georeference,georeferencing>> projects (expeditions) in Notes from Nature, but there are plans to develop this in the future.

=== GEOLocate

The GEOLocate suite of tools includes a web-based collaborative client – CoGeo (https://coge.geo-locate.org/[Rios 2019^]), the goal of which is to provide a mechanism whereby groups of users can form communities to collaboratively <<georeference>> and verify a shared dataset (http://www.geo-locate.org/community/default.html[GEOLocate 2018^]). This allows for the upload of a CSV file and having parts of the dataset allocated to a user. GEOLocate can also be accessed through third party applications via its API.

Using the tools in GEOLocate, a <<georeference>> may be determined along with an <<uncertainty>> (https://epicc.berkeley.edu/wp-content/uploads/2015/11/UsingGeoLocateforCollaborativeGeoreferencing_2016.pdf[Biedron & Famoso 2016^]). An <<uncertainty>> polygon (see also <<shape>> and <<Shape Method>>) can also be drawn in addition to the <<point-radius>> circle. Note that GEOLocate may return more than one candidate <<location>> for a given <<locality>> string and users are advised to always verify and adjust, as needed, to obtain the final accepted result (including uncertainty <<radial,radii>> and polygons). The data can be exported through KML for plotting onto Google Earth. The system allows for review of records and we recommend that this be done for all records where possible.

=== Other Collaborative Georeferencing Projects

Other projects, including the terrestrial vertebrate precursor projects to VertNet (https://doi.org/10.17161/bi.v1i0.7[Stein & Wieczorek 2004^], https://doi.org/10.1525/bio.2010.60.4.2[Guralnick & Constable 2010^]), have, in the past, divided up and distributed the records for <<locality,localities>> from a given geographic region to an institution with expertise in and/or resources about that region to <<georeference>> (see <<Project Workflow Example – MaNIS/HerpNET/ORNIS>>). The major advantages of this approach are that the quantity and <<data quality,quality>> of the raw materials used for georeferencing are probably higher, and the efficiency and quality of the results are also likely higher than if attempted without taking advantage of these resources. However, as mentioned earlier, <<repatriate,repatriation>> of the georeferenced records is an issue that needs solving for this to work most efficiently.
76 changes: 76 additions & 0 deletions translations/0500-sharing-data.es.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
== Sharing Data

<<georeference,Georeferencing>> is only the first step toward making biological (specimen and observation) data available to the world. However, it is an important first step, as it is one of the two most key methods for identifying what and where a specimen is, that is, its scientific name and its location (https://doi.org/10.15468/doc.jrgg-a190[Chapman 2005a^]). Two main standards have been developed for sharing biological data, <<Darwin Core>> (https://doi.org/10.1371/journal.pone.0029715[Wieczorek et al. 2012b^]) and https://www.tdwg.org/standards/abcd/[Access to Biological Collections Data^] (ABCD), both ratified by https://www.tdwg.org/[Biodiversity Information Standards^] (TDWG). We do not treat the ABCD standard separately in this document, as https://github.com/tdwg/dwc/blob/master/vocabulary/term_versions.csv[term mappings between Darwin Core and ABCD are well defined^] for location data. One of the principles of <<Darwin Core>> is to try to provide content for every field possible.

=== Mapping to Darwin Core

The <<Darwin Core>> (denoted with the abbreviated namespace [.term]#dwc#) <<georeference,georeferencing>> concepts that are directly used in this document are:

term:dwc[dwc:decimalLatitude], term:dwc[dwc:decimalLongitude]:: the <<geographic coordinates>> of the center of the <<point-radius>> version of the <<georeference>>

term:dwc[dwc:geodeticDatum]:: the <<EPSG>> code (preferably) or name of the <<coordinate reference system>>, <<geodetic datum>>, or <<ellipsoid>> of the <<point-radius>> version of the <<georeference>>

term:dwc[dwc:coordinateUncertaintyInMeters]:: the <<radial>> of the <<point-radius>> version of the <<uncertainty>> of the <<georeference>>, in meters

term:dwc[dwc:coordinatePrecision]:: the decimal representation of the <<precision>> of the output <<coordinates>> of the <<georeference>>

term:dwc[dwc:footprintWKT]:: the representation of the resulting <<shape>> or <<bounding-box>> <<georeference>>, in Well-Known Text (WKT) (https://www.iso.org/standard/60343.html[ISO 2016^])

term:dwc[dwc:footprintSRS]:: the <<coordinate reference system>> of the resulting <<shape>> or <<bounding-box>> <<georeference>>, in Well-Known Text (WKT) (https://www.iso.org/standard/60343.html[ISO 2016^])

term:dwc[dwc:locality]:: intended to contain a version (perhaps modified from the original) of the parts of the textual description of the <<location>> that do not have another <<Darwin Core>> term appropriate to hold them; in legacy data, may contain any textual information about the location

term:dwc[dwc:verbatimLocality]:: meant to contain all of the unmodified original <<location>> information

term:dwc[dwc:verbatimCoordinates]:: the original <<coordinates>> in the original format, especially if they are not <<latitude>> and <<longitude>>, such as <<UTM>> coordinates

term:dwc[dwc:verbatimLatitude], term:dwc[dwc:verbatimLongitude]:: the original <<latitude>> and <<longitude>> in the original format

term:dwc[dwc:verbatimCoordinateSystem]:: the <<coordinate format>> of the <<coordinates>> that are either in term:dwc[dwc:verbatimCoordinates] or in term:dwc[dwc:verbatimLatitude] and term:dwc[dwc:verbatimLongitude]

term:dwc[dwc:verbatimSRS]:: the <<coordinate reference system>> of either the term:dwc[dwc:verbatimCoordinates] or the combination of term:dwc[dwc:verbatimLatitude] and term:dwc[dwc:verbatimLongitude]

term:dwc[dwc:minimumElevationInMeters], term:dwc[dwc:maximumElevationInMeters]:: the lower and upper limits of the <<elevation>> of the <<location>>, in meters

term:dwc[dwc:verbatimElevation]:: the original <<elevation>> in the original format with the original units

term:dwc[dwc:minimumDepthInMeters], term:dwc[dwc:maximumDepthInMeters]:: the minimum and maximum limits of the <<depth>> of the <<location>>, in meters

term:dwc[dwc:verbatimDepth]:: the original <<depth>> in the original format with the original units

term:dwc[dwc:minimumDistanceAboveSurfaceInMeters], term:dwc[dwc:maximumDistanceAboveSurfaceInMeters]:: the lower and upper limits of the position with respect to a local surface, either at an <<elevation>>, or at a <<depth>> from an <<elevation>>.

term:dwc[dwc:locationAccordingTo]:: the source authority for the <<location>> information, not the <<georeference>> information, for which see term:dwc[dwc:georeferenceSources]

term:dwc[dwc:locationRemarks]:: comments about the <<location>> information, not about the <<georeference>> for the location, for which see term:dwc[dwc:georeferenceRemarks]

term:dwc[dwc:pointRadiusSpatialFit]:: the <<spatial fit>> of the <<point-radius>> <<georeference>> (see <<Determining Spatial Fit>>)

term:dwc[dwc:footprintSpatialFit]:: the <<spatial fit>> of the <<shape>> or <<bounding-box>> <<georeference>> (see <<Determining Spatial Fit>>)

term:dwc[dwc:georeferencedBy]:: who is responsible for the <<georeference>> as it currently stands, could be the person who did the first pass, but could be changed later to the person who verifies it

term:dwc[dwc:georeferencedDate]:: the date on which the data in the <<georeference>> fields reached their current state

term:dwc[dwc:georeferenceProtocol]:: a citation of a published set of rules used to determine a <<georeference>>. For example, “Georeferencing Quick Reference Guide 2020”. Any deviations from the cited protocol should be noted in term:dwc[dwc:georeferenceRemarks]

term:dwc[dwc:georeferenceSources]:: a list of maps, <<gazetteer,gazetteers>>, or other resources used to <<georeference>> the <<locality>>. Should be specific enough that someone else can locate and use the same sources. Example: "USGS 1:24000 Florence Montana Quad 1967; Terrametrics 2008, Google Earth".

term:dwc[dwc:georeferenceVerificationStatus]:: an indicator of the extent to which the <<georeference>> has been verified to represent the best possible spatial description for the occurrence record. By default a newly created georeference should have the status "requires verification". Beyond that, there are really only two other functionally distinct possibilities, either "verified" (by the person mentioned in term:dwc[dwc:georeferencedBy]), and "verified by collector" or equivalent, to designate that the georeference was reviewed for that specific record by the person who recorded it to begin with, and that it can not be further improved. This is the ideal status to aspire to.

term:dwc[dwc:georeferenceRemarks]:: any notes or comments about the spatial description, deviations from the cited protocol, assumptions, or problems with <<georeference,georeferencing>>. For example, "locality too vague to georeference".

=== Generalizing Georeferences for Sensitive Taxa and Locations

As recommended elsewhere in this document, <<georeference,georeferences>> should be recorded and stored at the best possible resolution and <<precision>>. If, however, the <<location>> of a taxon is regarded as sensitive for some reason following the guidelines as set out in https://doi.org/10.15468/doc-5jp4-5g10[Chapman 2020^] and https://doi.org/10.15468/doc-b02j-gt10[Chapman & Grafton 2008^], and it is agreed that the detailed location information should not be shared, we recommend, that the data only be <<generalization,generalized>> at the time of sharing or publishing of the data.

We recommend that if data are to be generalized that it be done by reducing the number of decimal places (for example when using <<decimal degrees>>) at which the data are published (https://doi.org/10.15468/doc-b02j-gt10[Chapman & Grafton 2008^], https://doi.org/10.15468/doc-5jp4-5g10[Chapman 2020^]). Good practice dictates that whatever you do to generalize the data, it be documented so that users of the data know what reliance can be placed on them. As far as the generalization of georeferencing data is concerned it is important to record that the data have been generalized using a ‘_decimal geographic grid_’, and record both:

* Precision of the data provided (e.g. 0.1 degree; 0.001 degree, etc.)
* Precision of the data stored or held (e.g. 0.0001 degree, 0.1 minute, 1 second, etc.)

We recommend that when recording the degree of generalization of data, that <<spatial fit,Spatial Fit>> (<<Determining Spatial Fit>>) be used. For example, the degree to which a record has been generalized to obfuscate the georeference will be a number greater than 1 (see <<img-spatial-fit>> and https://doi.org/10.15468/doc-5jp4-5g10[Chapman 2020^]).

NOTE: Data should never be generalized at the time of collection, when georeferencing or when storing in the database.

Some institutions randomize the data before publishing. This is a practice we do *NOT* recommend, and in fact would discourage it in all circumstances (https://doi.org/10.15468/doc-5jp4-5g10[Chapman 2020^]).
Loading

0 comments on commit ab0458d

Please sign in to comment.