Best Practices for Reporting Location and Time Related Data – Version 3.3, 2007-03-12 1 

WHITE PAPER 

Best Practices for Reporting Location and Time Related Data 

 Version 3.3, Dec 12, 2007

Council Document 2007-21 
Best Practices for Reporting Location and Time Related Data – Version 3.3, 2007-03-12 2 

Acknowledgements 

A Spatial and Temporal Work Group of the Northwest Environmental Data-Network (NED) have 

developed these Best Practices. 

NED operates under a 2004 Memorandum of Understanding, which supports collaborative action and 

joint activities with respect to improving the collection, management, and sharing of environmental data 

and information. 

Participants in the Spatial and Temporal work group include Michael Beaty (US Bureau of 

Reclamation), Greg Robillard (State of the Salmon Consortium), Brendan Sylvander and Jeff Cowen 

(National Oceanographic and Atmospheric Administration - Fisheries), Bobbi Riggers and Doug Terra 

(Oregon Watershed Enhancement Board). 

The primary authors are Joy Paulus (WA Office of the Interagency Committee) and Stewart Toshach 

(National Oceanographic and Atmospheric Administration - Fisheries). 

Dick O’Connor (Washington Department of Fish and Wildlife), Stan Frazier (US Bureau of Land 

Management), Tom Pansky (Bonneville Power Administration), Curtis Cude (Oregon Department of 

Environmental Quality), Roberto Morganti (US Forest Service), Paul Ocker (US Army Corps of 

Engineers), Tom O’Neil (Northwest Habitat Institute), Kristen Swodoba (US Bureau of Reclamation), 

Mike Banach, Bruce Schmidt and Van Hare (StreamNet), David Graves and Denise Kelsey (Columbia 

River Intertribal Fisheries Commission), John Arterburn (Colville Confederated Tribes) and Rebekka 

Lindskoog (Summit Environmental Consulting Ltd.) all provided valuable reviews. Comments on the 

draft were solicited from the Pacific Northwest Aquatic Monitoring Partnership, the Pacific Northwest 

Regional Geographic Information Council and NED. 

Much of the physical data structure outlined in this document is based on work conducted at the WA 

State Department of Ecology on the Environmental Information Management System initiative in early 

2000. 

Photographs provided by the Washington Office of the Interagency Committee’s Grant Application 

System PRISM. 
Best Practices for Reporting Location and Time Related Data – Version 3.3, 2007-03-12 3 

Introduction and Background 

In the Pacific Northwest there are hundreds of research, monitoring and evaluation and environmental 

management projects creating substantial quantities of data. Most of this data has location and time 

related data elements that are often reported using different standards and formats. 

There is a region-wide need, for multiple 

purposes, to be able to view and analyze these 

data at different landscape-scales. This need 

requires the creation of integrated data products 

(maps, tables, charts, statistical analyses) from 

multiple data sets. Unfortunately, because the 

data has been reported without common 

standards, the data integration task is timeconsuming and expensive. And, because data 

conversion is needed, errors are introduced. In 

many instances the burden of data integration and 

error checking prevents data analysis. 

Version History 

Version 3.2 2006-11-14, replaced version 3.1 (May 2006). The significant change between these 

versions was to adopt a best practice for reporting date that is consistent with International Standards 

Organization standard 8601 standard notation. 

This version, 3.3 2007-03-12, replaces version 3.2 2006-11-14. The change is to include instructions 

at page 8 about how to select the yyyy/mm/dd format for managing date information within cells or 

groups of cells when using Microsoft Excel:

 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 4 

Intended Users of These Guidelines 

The guidelines have been prepared for two types of users: 

1) Users who are not presently tracking environmental project data within a geographic information 

system (GIS) and who are managing their information within a database or spreadsheet. The 

guidelines are focused on the needs of these users.

2) Users who are already employing GIS systems to track monitoring and restoration projects. This 

group is strongly encouraged to track similar elements using established state and federal data and 

metadata (information about data) standards. 

Example of more detailed federal standards can be found at: 

 EPA (for detailed geolocational standards http://iaspub.epa.gov/edr/epastd$.startup

 FGDC (for metadata) http://www.fgdc.gov/standards/ 

 Water Information Coordination Program/Advisory Committee Water Resources (for 

Water monitoring) http://water.usgs.gov/wicp/acwi/

Nothing in these guidelines is intended to diminish existing authorities for information collection or 

reporting. For example, most Federal entities are already required to provide FGDC compliant 

metadata about spatial, temporal, and other data collection efforts. 

These guidelines represent what is considered to be the minimum set of location and time information 

that should be considered for collection and reporting. This is not meant to limit your collecting 

additional information that may be pertinent to, and best determined by, the collecting organization. 

For more information about GIS and other technical terms used in this guidance and what they mean, 

please look at: 

 http://gis.esri.com/showcase/showcase.cfm 

 http://support.esri.com/index.cfm?fa=knowledgebase.gis
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 5 

Why Use Data Standards 

A minimum set of mapping standards is necessary to ensure the successful implementation of a 

multi-agency approach to data collection. Consistent use of common reporting standards would have 

significant benefits to the region by: 

 Reducing errors and improving data quality; 

 Increased understanding of the information content; 

 Leveraging existing technical advances and investments that have been made in spatial and 

temporal data collecting and viewing. In particular: Geographic Positioning Systems (GPS) 

for determining location (and time) and GIS for creating spatial products; 

 Reducing the cost of analysis and increasing confidence in analytical products; 

 Allowing easier and more widespread use of data collected across different programs and 

entities; 

 Increasing data consistency; and 

 Improving data maintenance over time. 

The use of consistent minimum location and 

time data reporting standards are not a 

technical challenge: it is a policy choice. It 

requires action within agencies to support or 

require the use of consistent standards within 

relevant agency projects and programs. 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 6 

Acquiring Latitude and Longitude Coordinates for Your Projects, Sites and 

Features 

All projects have some form of locational information. Locational information about a project may 

include the location of the project itself, the locations where actual site work for the project is 

completed and details of features at sites. Features are things carried out at sites, for example 

building a fence, sampling water quality, or counting fish. It is very important to identify what 

locations are being associated with each project, site or feature, using detailed latitude and longitude 

information. 

For example: a salmon habitat restoration 

project is located on the Skagit River at the 

confluence with the Sauk River (the project 

location). At the confluence there are 3 

separate places of work (site locations) where 

fence installations (feature location 

information) are being completed. If 

monitoring was also completed as a part of the 

project, there may also be records of 

monitoring site locations with feature level 

detail about each of those sites, for example, 

transect location information. 

 

Each case may be different. 

The following sources of coordinate information may help to make reporting information about your 

project area easier. This material is not intended to be a complete guide for working with GIS or 

GPS, but rather, a guide for building the needed attributes in a database so you can track project 

information at the simplest level. 

Hardcopy Map Sources

 USGS quad sheets have lat/long coordinate grids along the side of the map. 

Map Data From Your Computer

 National Geographic sells USGS quad data on CD/DVD’s for individual states that can be 

loaded on your PC. 

Free On-line Map Sources

There are on-line USGS maps that can be accessed on-line from different sources. For example: 

 TopoZone http://www.topozone.com 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 7 

 MapTech’s http://www.maptech.com/

 Microsoft’s http://terraserver.microsoft.com/

These sites allow you to search for your area of interest and then display the area selected. By 

holding your mouse over a point on the map it will display the lat/long coordinates of that point. 

Web Mapping Services

For organizations that need access to frequent and accurate geocoding information there are services 

that can provide you with this sort of support. One example would be ArcWeb Services for 

Geocoding. 

For a glossary on more information about spatial information go to: 

 http://gis.esri.com/showcase/showcase.cfm 

 http://support.esri.com/index.cfm?fa=knowledgebase.gis

 

Reporting Date and Time data for Your Projects, Sites and Features 

The recommended best practice is consistent with the ISO 8601 standard notation. 

Calendar date is reported as an eight digit sequence composed of numeric characters in the format 

YYYY-MM-DD where YYYY is the year in the Gregorian calendar, MM is the month of the year 

between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31. 

Time is reported according to the international standard notation of HH:MM:SS where HH is the 

complete number of hours that have passed since midnight, from 00 to 24, MM is the number of 

complete minutes that have passed since the start of the hour (00-59), and SS is the number of 

complete seconds since the start of the minute. If the hour value is 24, then the minute and second 

values must be zero. 

If the date and the time are stored in the same data field then they should be separated by the Latin 

capital letter T, eg 19950123T235959. 

For these Best Practices the time zone is assumed to be the local time unless there are further 

additions. 

To indicate that a time is being reported in Universal time (UTC) it is necessary to append a Z eg 

23:59:59Z. The Z stands for zero meridian. The strings +HH:MM or +HH can be used to indicate 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 8 

when the local time zone is ahead of the UTC. Strings of –HH:MM or – HH can be used when the 

local time zone is behind UTC. 

Note:

When using Microsoft Excel a user can select the yyyy/mm/dd format for managing date information 

within cells or groups of cells as follows: 

 Select Format/Cells/Date/Locale(Location)/English(Canada) e.g. 2001-03-14 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 9 

Real World Examples of How Data Reporters Can Conform to These 

Guidelines 

The spatial and temporal standards described in this document are for use in any Observation Based 

Data collection effort1

. Observation Based Data are generated during an activity (e.g. fish and 

wildlife counting, habitat survey), performed by participants (e.g. Data Collector) where 

observations (recorded data) are collected about a subject (e.g. fish passage or bird inventory) 

following a methodology (screw trap method 2 or point counts) at a location during a period (2005 

05-04 to 2005-05-08) and for a particular purpose (measuring smolt production or counting various 

birds in an area). 

While data analysts usually want to know all of the italicized information above, this document is 

intended to provide minimum standards for reporting on the location and the period of an 

Observation Based Data collection effort. 

There are many different types of participants involved in data collection and reporting with different 

levels of technical support. Examples are provided below for two types of participants: 

 Data collectors with limited data or GIS resources 

 Data collectors with expanded data or GIS resources (or large organization) data collectors. 

Data collectors with limited data resources would typically be working on smaller scale projects, 

often without support from an enterprise level information system. 

Data collectors with expanded resources would typically be working within an organization that has 

enterprise level GIS support. Most participants working for a government scientific program enjoy 

the support of a GIS department or staff with an established data management system. 

 

1

 Draft Fish Monitoring Protocols Workshop -Data Management Work Group -Welches, OR, May 2005 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 10 

Example 1: Collector with Limited Data Resources 

The participant collects water quality data in a stream environment and determines the sampling 

location from a paper map. The time of sampling is reported as HH:MM:SS from a personal watch 

that is not synchronized. Later, in the office, the user logs onto a map web service (e.g. 

http://www.maptech.com/ or http://www.topozone.com) to identify the sampling latitude and 

longitude (in decimal degrees) from the map web service. 

The participant would report, at the least, a brief description of the location method (along with other 

needed metadata2

): e.g. “I marked the location on a 1:100,000 typographical map in the field and then 

used the http://www.maptech.com/ or http://www.topozone.com or http://terraserver.microsoft.com/

Web service to get a lat/long in decimal degrees. Time of sampling was reported from a personal 

unsynchronized watch”. 

Example 2: Collector with Limited Data Resources 

The collector is validating the planting of an area of riparian planting. While the site can be located, 

survey stakes cannot be located to delineate the work site. The collector walks to the estimated 

center location (centroid) of the tree-planting project and measures the location using a hand-held 

GPS. Later, in the office, the collector reports the data by keying the location information from the 

GPS into a spreadsheet and makes a description of the spatial and temporal data method used as a 

part of the needed metadata record: e.g. “I walked to the approximate center of the planting and 

estimated the location with a “Garmin E-Trex” GPS using an unknown methodology. The datum 

used was NAD83 (North American Datum 1983). I could not locate survey stakes.” 

Example 3: Collector With Expanded Data Resources 

The participant collects water quality data in a stream environment from multiple sites and observes 

and reports the sampling locations in decimal degrees, the date (YYYY-MM-DD), and the time of 

sampling (HH:MM:SS), into a PDA with an integrated “Garmin 18” GPS unit. The time is taken 

from the GPS. When reporting the data, on return to the lab, the GPS data is downloaded from the 

users PDA to a corporate database and a description of the spatial and temporal methods used is 

attached along with other metadata, including a reference to the datum used (NAD83) and the use of 

automatic loading of spatial and temporal data from the Garmin GPS 18 unit. 

 

 

2 Other needed metadata could include: 

1. Description of what the dataset is, who collected, created, or processed the data, and the dates these were 

completed. 

2. Any access/use constraints associated with the data—is it sensitive, copyright, etc. 

3. A descriptive title or naming convention for the dataset. 

4. Originator of the data-who? When it was published. 

5. A point of contact for the data. Name, organization, contact phone number, address or email. 

6. Any processing that was done from the data from it’s original state-who, when, what, where and how. 

7. What is the data quality? Is it complete, logical, consistent? What is the accuracy or precision of the data? 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 11 

Example 4: Collector With Expanded Data Resources

The participant is validating the planting of an area of riparian planting. While the site can be 

located, survey stakes cannot be located to delineate the work site. The collector describes a polygon 

(shape file) for the boundary of the planting by walking the boundary of the planting and using a 

hand held GPS to enter waypoints at changes of direction along the boundary. In the office the data 

is downloaded from the GPS into the corporate database. 

When reporting the data, a description of spatial and temporal methods used and other needed 

metadata, should be attached to the data: For example: “The area of planting was located by walking 

the perimeter of the planting using a hand-held Garmin Map 60 GPS, reporting way points at 

boundary direction changes. The datum was NAD83 (North American Datum 1983). In the office 

the data was downloaded into the database.” 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 12 

How to Understand and Use the “Multi-Level” Guidelines 

These guidelines, for reporting location (spatial) and time (temporal) related data, were designed with 

flexibility in mind. Since some projects are simpler than others, the “Multi-Level” structure allows 

project managers to track projects and location information at the needed level of detail. See Table 1 

for descriptions of Level 1, Level 2, and Level 3. 

Simple projects can typically be tracked using Level 1, which provides managers and end users with 

just enough general information, such as project name, sponsor, and project type, along with a 

general physical description of the project’s location and its time duration. An example of this sort of 

project could be an environmental education project that associated with a scientific program where 

locational data is not collected. 

But, as we know, certain projects can become complex, especially when they entail specific sampling 

or other activities. In these instances, a project can cover a large area with discrete places where 

information is tracked and collected, for example, a project to replace culverts at multiple sites. In 

this case you could track project information at Level 1 and Level 2, which provides for more 

detailed collection. 

In some cases, tracking information at Level 2 may not be sufficient. During some projects, multiple 

sites could be visited many times with the sampling of detailed environmental data at each of the sites 

in addition to the location and time data. Project Sites where water chemistry and a stream’s 

morphology are collected along different reach segments is an example of when Level 3 information 

would be needed. With this complexity you would need to be tracking project information at all 

three levels. 

This “leveled” (or multi-tiered) structure for tracking project location and duration was created for 

this reason. To allow the reporting of information on simple to complex projects as the need arises 

while still being able to connect the project, site, and feature information. 

As you go through these levels, you expose more levels of detail related to your project collection 

and reporting efforts. This is one of the primary benefits of this leveled reporting approach. 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 13 

Using the Location and Time Element Tables 

The standards are designed to support consistent reporting of data that is collected. For example, the 

standards do not require programs or projects to collect the time of water quality sampling to the 

nearest second. But if data is being collected to the nearest second, then the data should be 

consistently reported at that time interval. The data tables are provided as a guideline. The physical 

attribute examples or format may not meet your organizations rules but as long as you document 

what physical attributes and formats you are using you meet the intent of the standards. In order to 

compare information across organizations it is important that you follow the predefined meaning of 

each element, it its definition and associated codes. 

The following tables are broken down into their separate, essential elements as a guide for 

information managers. To attain consistency across regional organizations, the actual element 

(logical) names and name definitions should be adopted “as is” along with the code tables listed 

under “Element Code, Code Range, or Description”. But, the elements’ physical names (the names 

used in the database, e.g. PRJ_ID) themselves are only provided as guidance. Your own agency 

physical data naming conventions may need to be followed. 

The more consistency you use in implementing these standards, the better we’ll all be able to link 

information together. Note, as you define your naming standards you will also need to define the 

business rules for how you will represent project, site, and feature location: For example, if you wish 

to characterize a watershed with a single point you could define that point as the centroid for the 

watershed. Similarly, if you are defining a single point for a fence you could define that point as the 

mid-point of the fence. Whatever method you use must be described as a part of the metadata record. 

The tables do not require the user to provide elevation related data. This data can be generated if the 

user needs it and therefore it is not essential to report it separately. If your organization wants to 

report elevation data, the type of information can be found in Table 5. 

Table 1: Project Level Summary Table (Levels 1-3) 

This provides the user with an overview of the “multi-level” data approach, associated definitions, 

and data elements. It also provides an outline of the types of other project information that you might 

want to consider collecting. The bolded headings represent the location and time information that we 

suggest should be added to existing and new project tracking systems. 

 

Table 2: Location and Time Data Elements Associated with Projects (Level 1) 

This provides detailed information about the types of location and time information that should be 

associated with all general projects. It also provides information on the following data elements – 

the name, its definition, an example of a database name, the associated codes to track the information 

properly, along with examples. The bolded headings represent the location and time information that 

we suggest should be added to existing and new project tracking systems. 

 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 

 14 

Table 3: Location and Time Data Elements Associated with Project Sites (Level 2) 

This provides the user with an overview of how you would implement the location and time 

information in a more complex project, such as projects where you are tracking specific and/or 

numerous locations or where the project’s sites exist over time. Not all projects will need this level 

of detail or the data may not be available for reporting. Following this format would enable the 

reporting of more detailed information concerning actual activities that are being performed in the 

field. 

The Table also provides information regarding the project site and its associated location and time 

elements. You will also find examples of database attributes and their associated code tables. The 

bolded headings represent the minimum spatial and temporal elements that should be added to 

existing and new project tracking systems. 

 

Table 4: Location and Time Data Elements Associated with Project Site Features (Level 3) 

Provides the user with an overview of how you would implement the location and time information 

in a more complex project which requires the project manager to track specifically measured features 

in the field at a given project site. Again, not all projects may need to be tracked at this level of 

detail. The table outlines the spatial and temporal elements of site features. You will find examples 

of database attributes and their associated code tables and examples of how this would be applied in 

the field. The bolded headings represent the minimum spatial and temporal elements that should be 

added to existing and new project tracking systems. 

Table 5: Optional Elevation Data Elements Associated with Projects, Sites, or Features 

Table 5 provides the user with an option of reporting elevations for Projects, Sites, or Features. 

Table 6: Examples of 

Location and Time Data Reporting for Different Types of Data Collection Efforts 

Provides the user with examples of how features can be reported at different levels of spatial and 

temporal detail, depending on whether or not the data is from an “independent” or “corporate” data 

collector.
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Table 1: Project Level Summary Overview Table

Level Definition Minimum Location (Spatial) and Other Common Data Elements 

Project Definition:

A project is an administrative unit of work that’s defined by an organization or entity. PROJECT = one project present per grant/activity/etc 

Project Guideline Project ID (unique system identifier, Primary Key) Project Name (user defined name) Project Type Project Location Description – text field (physical place where project collection/measurement/observation occurred) Project Location (Longitude/Latitude in decimal degrees. The minimum reporting standard is a single point Datum (horizontal reference model) 

Project Location Collection Method (GPS, Digital Elevation Model, map derived, etc.) 

PPr(dEPrth20

Site Definition 

The location where project work is done.SITE = one or many sites may be contained in a project 

Site GuidelineProject ID (Secondary Key) Site ID (unique system identifier, primary key) Site Name (user defined name) Site Type Site Location Description (physical place where collection/measurement/observation 

occurred) Site Location (Longitude/Latitude in decimal degrees) The minimum reporting standard is a single point. Datum (horizontal reference model) Site Location Collection Method (GPS, DEM, map derived, etc.)

SSithmob19Sisimob20

Feature Definition: 

The location of things or activities at sites FEATURE = one or many features may be present at a site 

Feature GuidelineProject ID (Secondary Key) Site ID (Secondary Key) Feature ID (unique system identifier, primary key) Feature Type (fence, transect, planting area, etc.) Feature Location Description (physical place where collection/measurement/observation 

occurred) Feature Location (Longitude/Latitude in decimal degrees) The minimum reporting standard is 

FFe(dmobth01Fe
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

a single point. Datum (horizontal reference model) Feature Location Collection Method (GPS, DEM, map derived, etc.) 

thmobth31 Fe

(timobusloEFe(timobuslo(H17

Notes on Table 1: 

 Highlighted elements are further described in Tables 2, 3, and 4 

 Other data elements could be added if needed. For example, some users may want to include a comment 

pertinent information about a record that could not be conveyed in other fields, while other users might whydrography data.
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Table 2: General Location and Time Data Elements Associated with Projects 

Level 1 

General Project Information 

(This information should be reported unless it is not applicable) 

Logical 

Name 

Element Definition Physical Name 

(For Example Only) 

Element Code, Code Range 

Project 

Identifier 

A project is a unit of work defined by an organization or entity. A project may include one or more sites or one or more types and number of activities. Unique system identifier 

PRJ_ID Examples 

Skagit River Habitat Restoration POkanogan Water Quality Sampling Oregon North Coast Nearshore MoDeschutes River Flow Monitoring 

Project 

Location 

Description

Term that best describes the field location in relation to the surrounding environment. 

PRJ_LOC_DESC Text field 

Examples: 

Okanogan watershed ESA Region SW 1⁄4 of Section 36 of Township 2

Project 

Location 

Latitude 

Coordinate 

Distance north or south of the equator. Decimal equivalent to the degreesminutes-seconds latitude value. 

PRJ_LOC_LAT_COORD Float, 2 places, 6 decimals; (4 decimals 

 E.g. Range for WA: 45.000000- 49.999999 

Project 

Location 

Longitude 

Coordinate 

Distance east or west of the Central Meridian (Greenwich, England). Decimal equivalent to the degrees-minutesseconds longitude value 

PRJ_LOC_LONG_COORD Float, 3 places, 6 

Decimals, will accommodate signed vaminimum); E.g. Range for WA: -116.000000 – -125.999999 

Project 

Horizontal 

Datum

Model used to match the horizontal position of features on the ground to coordinates and locations on a map. NOTE - When taking GPS measurements, it is very important to record your datum! 

PRJ_HORZ_DAT 01 - N. American Datum 1927 (NAD27

quad maps or NOAA charts); 02 - N. American Datum 1983 (NAD83 Earth and satellite observations, similar to North America.); 03 - High Accuracy Reference Network NAD83, but more accurate per GPS ob
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

04 - World Geodetic System of 1984 (Wbased on Earth and satellite observation99 - unknown. 

Logical 

Name

Element Definition Physical Name 

(For Example Only)

Element Code, Code Range 

Project 

Location 

Collection 

Method

Technique used to collect the horizontal coordinates of a Location. 

PRJ_LOC_COLL_MTH 

1 - Address Matching - Block Face; 2 - Address Matching - House Number3 - Address Matching - Street Centerlin4 - Address Matching - Unknown; 5 - Aerial Photography - Rectified; 6 - Aerial Photography - Unknown; 7 - Aerial Photography - Unrectified; 8 - Cadastral Survey (conventional land 9 - Census Block 1990 Centroid; 10 - Census Block Group 1990 Centroi11 - Conversion from STR; 12 - Digital or manual raw photo extrac13 - Digitized off CTR screen/digital da14 - Digitized - paper map; 15 - GPS carrier phase (employs the satCode’s carrier signal to improve accura16 - GPS code phase (measurements bapseudo random code broadcast by satel17 - GPS kinematics (tracking location carrier phase); 18 - GPS (Unknown); 19 - Hand measured - paper map (interp20 - LORAN-C; 21 - Orthophotography - digital; 22 - Orthophotography - paper; 23 - Satellite Imagery - Landsat MSS (MScanning); 24 - Satellite Imagery - Landsat TM (Th25 - Satellite Imagery - Other; 26 - Satellite Imagery - SPOT Panchrom27 - Satellite Imagery - SPOT Multi Sp28 - Zip Code Centroid; 29 - GPS (Code/Differential); 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

30 - Estimated Value; 31 - GIS Interpretation Centroid of poly32 - GIS Interpretation Centroid of tran33 - GPS Beginning of Transect; 34 - GPS End of Transect; 35 - GPS Center of Project; 36 - Web based internet mapping system99 - unknown 

Logical 

Name

Element Definition Physical Name 

(For Example Only)

Element Code, Code Range 

Project Start 

Date 

The date that the project activity commenced. 

PRJ_STR_DT Date, YYYY-MM-DD format. (Only if 

E.g.2003-03-12 03/12/2003. Use a date indicate that the Start Date is not specif

Project End 

Date 

The date that the project activity ended. PRJ_END_DT Date, YYYY-MM-DD format. (Only if 

E.g. 2004-03-12. Use a date of 1800-0End Date is not specified or is unknown

Notes: Other data elements could be added if needed. For example, some users may want to include a comment field to pertinent information about a record that could not be conveyed in other fields, while other users might want to inhydrography data. 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Table 3: Location and Time Data Elements Associated with Tracking Project Sites 

Level 2 

The Following Site Elements Are Nested Under Projects 

(This detail may not be necessary for all reporting purposes) 

Logical Name Element Definition Physical Name 

(For Example Only) 

Element Code, Code Rang

Project Site 

Identifier 

The place where site activities that are associated with a project occur or the area where the work is done. Each site will pertain to just one project but there can be more than one site for any given project. Location of the site or activities where work is conducted - on the ground activities Unique system identifier 

PRJ_SITE_ID 

This needs to be defined based on the tythat is being done, E.g. 

Skagit River Habitat Restoration SOkanogan Water Quality Sampling 

in study 

Oregon North Coast Nearshore Mo

reaches in project 

Deschutes Flow Monitoring Sites – 

project 

Project Site Location Description

Term that best describes the site location in relation to the surrounding environment. Information that describes the place a Location exists. 

PRJ_SITE_LOC_DESC Text field E.g. 200 yards north of the ca

Laumann Road, north of the intersectio

Project Site Location Latitude Coordinate

Distance north or south of the equator. Decimal equivalent to the degrees-minutes-seconds latitude value. 

PRJ_SITE_LOC_LAT_COORD Float, 2 places, 6 decimals; (4 decimals 

 E.g. Range for WA: 45.000000-49.999

Project Site Location Longitude Coordinate 

Distance east or west of the Central Meridian (Greenwich, England). Decimal equivalent to the degreesminutes-seconds longitude value. 

PRJ_SITE_LOC_LONG_COORD Float, 3 places, 6 decimals, (4 Decimals 

accommodate signed values; E.g. Range for WA: -116.000000 – -12
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Project Site Horizontal Datum

Model used to match the horizontal Position of features on the ground to coordinates and locations on a map. NOTE - When taking GPS measurements, it is very important to record your datum! 

PRJ_SITE_HORZ_DAT 01 - N. American Datum 1927 (NAD27

quad maps or NOAA charts); 02 - N. American Datum 1983 (NAD83 Earth and satellite observations, similar to North America.); 03 - High Accuracy Reference Network NAD83, but more accurate per GPS ob04 - World Geodetic System of 1984 (Wbased on Earth and satellite observation99 - unknown. 

Logical Name Element Definition Physical Name 

(For Example Only)

Element Code, Code Rang

Project Site Location Spatial Data Collection Method 

Technique used to collect the horizontal coordinates of a site location. 

PRJ_SITE_LOC_COLL_MTH 

1 - Address Matching - Block Face; 2 - Address Matching - House Number3 - Address Matching - Street Centerlin4 - Address Matching - Unknown; 5 - Aerial Photography - Rectified; 6 - Aerial Photography - Unknown; 7 - Aerial Photography - Unrectified; 8 - Cadastral Survey (conventional land 9 - Census Block 1990 Centroid; 10 - Census Block Group 1990 Centroi11 - Conversion from STR; 12 - Digital or manual raw photo extrac13 - Digitized off CTR screen/digitial d14 - Digitized - paper map; 15 - GPS carrier phase (employs the satcode's carrier signal to improve accurac16 - GPS code phase (measurements bapseudo random code broadcast by satel17 - GPS kinematics (tracking location carrier phase); 18 - GPS (Unknown); 19 - Hand measured - paper map (interp20 - LORAN-C; 21 - Orthophotography - digital; 22 - Orthophotography - paper; 23 - Satellite Imagery - Landsat MSS (M
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Scanning); 24 - Satellite Imagery - Landsat TM (Th25 - Satellite Imagery - Other; 26 - Satellite Imagery - SPOT Panchrom27 - Satellite Imagery - SPOT Multi Sp28 - Zip Code Centroid; 29 - GPS (Code/Differential); 30 – Estimated Value; 31 - GIS Interpretation Centroid of poly32 - GIS Interpretation Centroid of tran33 - GPS Beginning of Transect; 34 - GPS End of Transect; 35 - GPS Center of Project; 36 - Web based internet mapping system99 - unknown 

Logical Name Element Definition Physical Name 

(For Example Only)

Element Code or Code Ran

Project Site Start Date 

The date that the site activity (sample collection, field measurement, field observation) commenced. If a site activity is essentially instantaneous, a Site End Date is often not specified. 

PRJ_SITE_STR_DT Date, YYYY-MM-DD format. (Only if 

E.g. 2003-03-12. Use a date of 1800-0Start Date is not specified or is unknow

Project Site End Date 

The date that the site activity (sample collection, field measurement, field observation) ended. If a field activity is essentially instantaneous, a Site End Date is often not specified. 

PRJ_SITE_END_DT Date, YYYY-MM-DD format. (Only if 

E.g. 2004-03-12. Use a date of 1800-0End Date is not specified or is unknown
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Table 4: Location and Time Data Elements Associated with a Complex Project Tracking Specific Site Fea

Level 3 

 The Following Elements are Nested under Project Sites 

(This detail may not be necessary for all reporting purposes)

Logical Name Definition Element Name 

(For Example Only) 

Element Code, Code 

Site Feature Identifier The structure, form, or appearance of 

what is being tracked, measured or observed at any given project site. Within any give project site there may be various features represented as single points, linear features or aerial extents. Unique system identifier 

SITE_FEA_ID This needs to be defined bas

scientific/field information tExample Code Tables: 

Transect measurement pFence Wells Fish hatchery raceway Reach segments 

Examples of Site Features: Water sampling well locatio

Individual gauging statLocation of addition to 

Site Feature Location Description

Term that best describes the feature location in relation to the surrounding environment. Information that describes the place a Location exists. 

SITE_FEA_LOC_DESC Text field, E.g. 200 yards no

on Laumann Road, north of Road 

Site Feature Location Latitude Coordinate

Distance north or south of the equator. Decimal equivalent to the degrees-minutes-seconds latitude value of a 

SITE_FEA_LOC_LAT_COORD Float, 2 places, 6 decimals; 

 E.g. Range for WA: 45.00049.999999 

Site Feature Location Longitude Coordinate 

Distance east or west of the Central Meridian (Greenwich, England). Decimal equivalent to the degreesminutes-seconds longitude value. 

SITE_FEA_LOC_LONG_COORD Float, 3 places, 6 decimals, (

will accommodate signed vaE.g. Range for WA: -116.00-125.999999 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Logical Name Element Definition Physical Name 

(For Example Only)

Element Code, Code 

Site Feature Horizontal Datum 

Model used to match the horizontal position of features on the ground to coordinates and locations on a map. NOTE - When taking GPS measurements, it is very important to record your datum! 

SITE_FEA_HORZ_DAT 01 - N. American Datum 19

many USGS quad maps or N02 - N. American Datum 19based on Earth and satellite WGS84 but specific to Nort03 - High Accuracy Referensimilar to NAD83, but more observations); 04 - World Geodetic System datum, based on Earth and s99 - unknown. 

Site Feature Location Collection Method 

Technique used to collect the horizontal coordinates of a feature location. 

SITE_FEA_LOC_COLL_MTH 

1 - Address Matching - Bloc2 - Address Matching - Hou3 - Address Matching - Stre4 - Address Matching - Unk5 - Aerial Photography - Re6 - Aerial Photography - Un7 - Aerial Photography - Un8 - Cadastral Survey (conve9 - Census Block 1990 Cent10 - Census Block Group 1911 - Conversion from STR; 12 - Digital or manual raw p13 - Digitized off CTR scree14 - Digitized - paper map; 15 - GPS carrier phase (empcode's carrier signal to impro16 - GPS code phase (measupseudo random code broadc17 - GPS kinematics (trackinusing carrier phase); 18 - GPS (Unknown); 19 - Hand measured - paper 20 - LORAN-C; 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

21 - Orthophotography - dig22 - Orthophotography - pap23 - Satellite Imagery - LandScanning); 24 - Satellite Imagery - LandMapper); 25 - Satellite Imagery - Othe26 - Satellite Imagery - SPO27 - Satellite Imagery - SPO28 - Zip Code Centroid; 29 - GPS (Code/Differential31 - GIS Interpretation Cent32 - GIS Interpretation Cent33 - GPS Beginning of Tran34 - GPS End of Transect; 35 - GPS Center of Project; 36 - Web based internet map99 - unknown 

Logical Name Element Definition Physical Name 

(For Example Only)

Element Code. Code 

Site Feature Activity Frequency 

The frequency of time at the location for treatments or collecting information 

SITE_FEA_FREQ Continuous, 

Hourly Daily Weekly Bi-weekly Monthly Quarterly Biannually Annually Decadal Alternating Time Frame (Ro

Site Feature Start Date 

The date that the feature activity (sample collection, field measurement, field observation) commenced. If a Feature activity is essentially instantaneous, a Feature End Date is often not specified. 

SITE_FEA_STR_DT Date, YYYY-MM-DD form

E.g. 2003-03-12. Use a date that the Start Date is not spe
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Site Feature End Date The date that the feature activity 

(sample collection, field measurement, field observation) ended. If a feature activity is essentially instantaneous, a Feature End Date is often not specified. 

SITE_FEA_END_DT Date, YYYY-MM-DD form

E.g.2004-03-12. Use a date that the End Date is not spec

Site Feature Start Time 

The time that the feature activity began, for example the time of sampling 

SITE_FEA_STR_TM Feature Start Time (time t

measurement, observation stat local time) (HH:MM:SS) 

Site Feature End time The time that the feature activity 

ended, for example the end of sampling 

SITE_FEA_END_TM Feature End Time (time th

measurement, observation eat local time) (HH:MM:SS) applicable) 
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

Table 5: Optional Elevation Data Associated with Projects, Sites or a Feature 

Logical Name Element Definition Physical Name 

(For Example Only)

Element Code, Code Range, or Ex

Elevation The measure of the 

elevation of the project site above a reference datum. 

PRJ_SITE_VERT Float, will accommodate signed values 

Elevation Units The unit of measurement 

used to describe the elevation value. 

PRJ_SITE_VERT_UNIT Text field; example 

Meters Feet 

Elevation Datum The code for the reference 

datum used to determine the vertical measure 

PRJ_SITE_VERT_DAT Navd88 

Ngvd29 Mean Sea-Level Local Tidal Datum Other 

Elevation Collection Method 

The technique used to establish the elevation or depth of the sampling site 

PRJ_SITE_VERT_COLL_MTH GPS Carrier Phase Static Relative Posit

GPS Carrier Phase Kinematic Relative GPS Code (Pseudo Range) Differential GPS Code (Pseudo Range) Precise PosiGPS Code (Pseudo Range) Standard PoGPS Code (Pseudo Range) Standard PoOther Altimetry Precise Leveling-Bench Mark Leveling-Non Bench Mark Control PoiTrigonometric Leveling Photogrammetric Topographic Map Interpolation
Best Practices for Reporting Location and Time Related Data – Version 3.2, 2006-11-14 

 Table 6: Examples of Location and Time Reporting for Different Types of Features (Data Elements describing th

are not included in this Table)

Feature Name Examples of location/time reporting detail from data 

collectors with limited data or GIS resources

Examples of location/time rep

corporate data collectors with ex

resources

Install Fish Screen Location of screen: (Lat/Long dec degree). 

Date of install: YYYY-MM-DD 

Location of screen: (Lat/Long dDate of install: YYYY-MM-DD 

Stream Bank Stabilization 

• Start and end point of stabilization: (Lat/Long dec degree) 

Date of stabilization: YYYY-MM-DD 

Polygon of stabilization area: (LDate of stabilization: YYYY-M

Riparian Area Treated 

Start and end point (Lat/Long dec degree) Date of treatment: YYYY-MM-DD 

Polygon of area treated: (Lat/LoDate of treatment: YYYY-MM-

Road Obliteration Project 

Start and end point (Lat/Long dec degree) Length of treatment (miles) Date of obliteration: YYYY-MM-DD 

Line detail of road treatment: (LDate of obliteration: YYYY-MM

Sediment Control Basin 

Centroid of basin: (Lat/Long dec degree). Date of sediment control: YYYY-MM-DD 

Polygon of basin: (Lat/Long dec Date of sediment control: YYYY

Wetland Creation Project 

Centroid of area created: (Lat/Long dec degree) Date of wetland creation: YYYY-MM-DD 

Polygon of area created: (Lat/LoDate of wetland creation: YYYY

Invasive Species Treatment 

Centroid of treatment area: (Lat/Long dec degree) Date of treatment: YYYY-MM-DD 

Polygon of treatment area (Lat/LDate of treatment: YYYY-MM-

Hatchery Fry/Smolt Release 

Location of point of release (Lat/Long dec degree) 

 Date of release: YYYY-MM-DD  Time of release HH:MM:SS 

Location of point of release: (LaDate of release: YYYY-MM-DDTime of release: HH:MM:SS 

Sampling Site Location: (Lat/Long dec degree) 

 Date of sample: YYYY-MM-DD  Time of Sample: HH:MM:SS 

Location: (Lat/Long dec degree) Date of sample: YYYY-MM-DTime of Sample: HH:MM:SS 

Livestock Exclusion Fencing 

Start and end point: (Lat/Long dec degree) Line detail: (Lat/Long dec degre