A locality is a specific place associated with one or more Collecting Events.  Ultimately, each locality should be a unique circle in geographic space.  The center is a point defined by latitude and longitude, and the radius is a linear estimate of error.  For electronic mapping, we convert such data to decimal degrees with estimates of error in meters.  Interfaces to the data are more flexible.

A locality has these related elements:

Unfortunately, not all localities are even crudely georeferenced.  Thus much of the descriptive data is hierarchical (e.g., continent, country, state, county, specific locality).  Applying coordinates and errors (georeferencing) to such descriptions is error-prone and even subjective.  Therefore, multiple georeferencing determinations can be applied to a single locality even though only the “accepted” determination is routinely displayed.  Some caveats:

Locality Nickname

Locality Nickname is a globally-unique human-readable “locality ID” commonly used to unambiguously associate one or more specimens to a locality.

Specific Locality

Locality . Spec_Locality VARCHAR2 (255) null

refers to the locality from which the specimen was collected from the wild, regardless of whether the animal was brought into captivity and killed at a different time and place.  If the wild-caught locality is not known, put the location where the animal died, was killed, or was purchased (e.g., the zoo, aviary, pet store, lab, or market) in the Specific Locality field (see Collecting Events for more details).

  1. When writing Specific Localities, the highest priority should be to maximize clarity and minimize confusion for a global audience.  Do not include higher geography (continent, ocean, sea, island group, island, country, state, province, county, feature) in the Specific Locality unless it references a place-name in another geopolitical subdivision, in which case include that subdivision in parentheses. The following example is located in California.


Locality . Maximum_Elevation

Locality . Minimum_Elevation


Locality . Orig_Elev_Units VARCHAR2 (2) null


are a height above mean sea level.  If elevation data are part of the verbatim locality, they should be entered into Minimum Elevation, Maximum Elevation, and Elevation Units (ft, m).  If the Verbatim Locality contains a range for an elevation, e.g., 500-600 ft, these values should be entered into the minimum and maximum elevation fields, respectively.  If a single elevation is given in Verbatim Locality, put that value in both the minimum and maximum elevation fields.


Locality . Max_Depth

Locality . Min_Depth


Locality . Depth_Units VARCHAR2 (2) null


are a distance below the surface of a body of water.  The body of water may or may not be at sea level, e.g., a mountain lake.  If depth data are part of the verbatim locality, they should be entered three fields for elevation: Minimum Depth, Maximum Depth, and Depth Units (ft, m).  If the verbatim locality contains a depth range, e.g., 500-600 ft, these values should be entered into the minimum and maximum depth fields, respectively.  If a single depth is given in the verbatim locality, put that value in both the minimum and maximum elevation fields.

Deprecated:Township, Range, and Section (TRS) information is sometimes given for localities.  If TRS data are part of the Verbatim Locality, they should be entered into the TRS fields associated with Specific Locality in the database.  Legal descriptions to 1 mile square sections have 4 parts: the Meridian, Range, Township and Section.  Note that an official legal description is always written from the smallest scale to the largest.  For example, the NW1/4 SE1/4, sec. 12, T11N, R15E, San Bernardino Meridian is the northwest quarter of the southeast quarter of section 12, Township 11 North, Range 15 East, San Bernardino Meridian.  This example describes a square 1/16th of a mile on each side.  Collectors often neglect the Meridian in TRS data, and we do not store this information in the database because it can usually be inferred from the state and county.  There are 6 fields in the database to accommodate TRS data: 1) Township, 2) Township Direction, 3) Range, 4) Range Direction, 5) Section, and 6) Part.  In the above example, the data would be entered as:

  1. Township = 11
  2. Township Direction = N
  3. Range = 15
  4. Range Direction = E
  5. Section = 12
  6. NW1/4 SE1/4 (variations on section part may be: SE 1/4, “western half,” NW corner, etc.)

A thorough description of TRS data, along with a tool to translate them to latitude and longitude can be found at the following URL:



The assigning of latitudes and longitudes to verbal locality data is called georeferencing. Latitude describes a position in degrees north or south of the equator. Longitude describes a position in degrees east or west of the Greenwich meridian. However, coordinates alone are of limited use without information on uncertainty and the coordinate frame of reference (datum).

Protocols for georeferencing natural history collections are described in the MaNIS Georeferencing Guidelines.  Tools that automate these protocols include the Georeferencing Calculator, BioGeomancer, and GeoLocate.  GeoLocate is called as a web service by applications within Arctos.

Coordinates are stored with collecting events and with locality, both optional. Collecting event coordinates are “verbatim” and should reflect some data associated with specimen events. Locality coordinates are part of georeferences, and may be standardizations or corrections of, or additions to verbatim coordinates.

Any locality has zero or one coordinate assertions. “Unaccepted coordinates” are handled by having multiple specimen events referencing multiple localities.

Data Entry has (for brevity) one place for coordinate information, and these data are stored as both verbatim and locality coordinates. Events and localities may be pre-made and selected when these limitations prevent accurately representing the data.

Original Units

collecting_event . Orig_Lat_long_Units VARCHAR(20) null



for geographic coordinates vary with the source of the data.  Classically, latitude and longitude have been recorded in degrees, minute and seconds.  Now, modern GIS applications generally use degrees only, including decimal fractions for all levels of precision.  In Arctos, coordinates are stored and displayed in their original format.  Except for UTMs, coordinates are also translated to, and stored as, decimal degrees for standardization and mapping.  There is not yet programming to convert UTMs to decimal degrees. Include as many digits of precision as are provided in the original data.  Forms in Arctos are customized according to which format is chosen, and the vocabulary and formats are defined and described by a code table.

In all formats, include as many digits of precision as are provided in the original data.

(Geodetic) Datum

Collecting_Event . Datum VARCHAR(40) null



The geodetic datum to which the latitude and longitude refer. A geodetic datum describes the size, shape, origin, and orientation of a coordinate system for mapping the earth. Latitude and longitude data referenced to the wrong datum can result in positional errors of hundreds of meters. Therefore, when providing latitude and longitude data, it is important to know from which datum those data are derived. Most GPS units allow you to select the geodetic data from which its coordinates will be determined (default usually set to WGS84, but this should be checked in the field). Maps and gazetteers generally provide this information as well.

Reference Source

Locality . GEOREFERENCE_SOURCE VARCHAR(255) not null



refers to the source(s) of the coordinates and not to the source of the error. Coordinates may be original data collected with the specimen, or they may be provided by after-the-fact georeferencing efforts. In the latter situation, data in Source(s) should be specific enough to allow anyone in the future to use the same resources to validate the coordinates, or to georeference the same locality. These data might be a list of maps, gazetteers or other resources used to georeference the locality. Examples:

In cases where the coordinates are original data, a description of the original source should be provided. Again, these data should make the coordinates as verifiable as possible by referring to records associated with the specimen. Examples:

Georeference Method



is the protocol used to obtain the values for the coordinates and the measure of precision. Different methods and tools have been produced, and are sometimes revised, and these differences can produce different results.  The vocabulary for this field is controlled.

Maximum Uncertainty Distance

Lat_Long . Max_Error_Distance NUMBER null


Lat_Long . Max_Error_Units VARCHAR2(2) null


is the upper limit of the horizontal (as opposed to elevational) distance from the reported latitude and longitude. It describes a circle within which the whole of the described locality lies. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value. Maximum Uncertainty is the sum of GPSAccuracy, Extent, and all other sources of error or imprecision.

This is a simple concept, but there are several sources of error which, when correctly combined, often demonstrate a value larger than intuition might suggest. These sources of error are enumerated in the MaNIS Guidelines, and are combined into estimates of total error by the Georeferencing Calculator.

In some circumstances the greatest source of error is the behavior of the collector and/or any intermediary sources of the data. For example, if a locality names a village, the collector may have obtained specimens from a resident who forages over a large area near the village. The collector may even have provided coordinates for the village, often from some standard source, implying specificity equal to the extent of the village. Estimating error can therefore be subjective, and conservative interpretation demands large values for Maximum Uncertainty. To avoid ambiguous or misleading locality descriptions, see MVZ’s guidelines.

Note that there is no error inherent to coordinates. {Dec_Lat=12,Dec_Long=34} is precisely the same point as {Dec_Lat=12.000000000000000000000000000000,Dec_Long=34.000000000000000000000000000000}. Make no assumptions of coordinate error or “size” (all coordinates describe a point) based on anything other than asserted maximum error.

For most usage, including exportation to federated portals, the value for Maximum Uncertainty is converted from the original units (recorded here) to the value in meters.

## Determiner

Lat_Long . Determined_By_Agent_id INT not null

is the agent (usually a person) who determined that these coordinates and measures of uncertainty apply to this locality. Often, this is the collector or, dear reader, you.  The form will load with the currently logged-in user as the default Determiner for new records.

Sometimes, a determination is developed by two or more successive agents. For example, one agent might locate a named place and provide the coordinates, but little or no information about the uncertainty. A second agent might then evaluate the determination (mapping it and comparing it to the Verbatim Locality) and then develop a Maximum Uncertainty. In this case, we assume that the second agent has re-evaluated the coordinates, and the determination is considered to have been made by the second agent (i.e., the agent who last modified the determination). If there is a need to maintain the identity of the first agent, then the second agent should create a second (separate) determination.If the collector offered a determination in the original data, this determination should not be modified even if it is no longer the accepted determination.

Determination Date

Lat_Long . Determined_Date DATETIME null

is the ISO8601 date that the determination was made. Entry/editing forms load with the current date as a default for new records. ~~

Verification Status

Lat_Long . VerificationStatus VARCHAR(40) not null



A categorical description of the extent to which the georeference has been verified to represent the location where the specimen or observation was collected.  Vocabulary is controlled.

“Verified by collector” indicates that the person who removed the specimen from nature has looked at the coordinates and uncertainty represented on an appropriately scaled map, and believes that these data are accurate and that the represented uncertainty is as small as possible.

~~## Accepted?

Lat_Long . Accepted_Lat_Long_fg TINYINT not null

There can be more than one georeferencing determination per locality but only the accepted determination is routinely displayed. You can revert to an earlier determination by changing its accepted flag from “no” to “yes.”~~


Lat_Long . Lat_Long_Remarks VARCHAR2(4000) null


about the spatial description determination, explaining assumptions made in addition or opposition to the those formalized in the method referred to in Georeference Method.


Locality . NogeorefbecauseVARCHAR2(255) null

is should always be NULL for localities with coordinate determinations.  Otherwise, it may be used to indicate problems with georeferencing the locality, resources needed to georeference, or anything else about the lack of coordinate determinations.

WKT Polygon

provides for a well-known text shape associated with locality data.

Edit Locality Form

Localities used by “verified by….” verificationstatus values may not be edited. If you don’t understand the giant bright red box, please use a contact link.

Many things are paired or dependant. Min, max, and units must be given together for elevation and depth. Coordinates must have datum, source, and protocol. Error cannot exist without coordinates. Fieldset labels on the form will change as form values change to help inform you of these associations.

All coordinates are stored as DD.ddd format. (Verbatim Coordinates are an attribute of Collecting Events.) The form will make conversions.

The webservice data pane has documentation inline. Read it.