Description

Geolocation information is crucial to the Journey North program, which relies on citizen scientists across North America to report when and where they observe migratory species. These precise location details allow us to track migration patterns accurately, understand species behavior, and contribute to broader ecological research. Because the success of our program hinges on the accuracy of these geolocated observations, it's important to provide detailed information about our geocoding system. This ensures transparency and helps researchers and the public understand how we capture, process, and utilize this vital data.

Geocoding metadata refers to the information that describes the processes, accuracy, and sources used in geocoding—translating addresses or place names into geographic coordinates (latitude and longitude). This metadata documentation includes the timeline of geocoding and the accuracy of the geocoding as well as the geocoding methodology. 

Timeline of Geocoding and Accuracy

1995 – 2012

The latitude/longitude was based on zipcode. The default location was the user's registered location.

When Journey North’s sightings and mapping systems were set up in the 1990s, most users did not know their latitude/longitude. If they did, they would provide latitude/longitude in minutes and seconds, not decimal degrees. To overcome this challenge, Journey North set up a system that would associate latitudes and longitudes to the user’s registration records as well as the observation reports records. During this period, researchers should assume that the latitude/longitude for the majority of observational reports would have been derived from the latitude/longitude of the user’s registration records.

During the user registration process on Journey North, records were created for each user. If a zipcode was not provided during registration, the system would then proceed to assign latitude and longitude coordinates to the user's record. This assignment was facilitated by Journey North's system, which utilized zip codes or city/state information to determine the coordinates. If a zipcode was available, the system retrieved the corresponding coordinates from the "jnorth/zipcodes" table. Otherwise, it determined the coordinates based on the provided city and state information. This assignment process occurred automatically each night and could also be manually initiated via the admin page for the sightings database. This procedure greatly depended on users providing a zipcode and/or city/state when registering. Researchers should not assume that the accuracy of early Journey North sightings records extends beyond the geocoded city level.

2012 – 2016

Journey North launched an online registration and reporting App. Observational reports submitted via the app had precise latitude/longitude based on phone’s location services. However, observational reports submitted over the website continued to have latitude/longitude from the registered zipcode. (see above noted process)

2016 – 2018

The Journey North system utilized the Google Maps Latitude/Longitude Picker to determine precise latitude/longitude coordinates for observational reports contributed by website users. This process assumed that users pinpointed the exact location on the map while submitting their observational reports.

Caveat: If the user did not move the picker when submitting an observational report, the latitude/longitude for that observational report would have been coded according to where the Picker was located by default which, in most cases, was the latitude/longitude of the user’s town, based on zipcode.

2018

Google began to charge for the GPS Location Services. Journey North shifted to ESRI’s API.

Caveat: Because Google was charging each time the user moved the red marker to pinpoint location, Journey North made the following change to minimize costs: the specific latitude/longitude from each users’ latest observational report was used as the default location.

Geocoding Methodology

The legacy JN codebase, which supports reporting and viewing sightings, has long depended on Google Maps and the Google Maps API for the map widgets and location identification (geocoding) tools used when sightings are reported or viewed. These are separate and distinct from the legacy maps application, which displayed image-based maps, and which we replaced with Leaflet.js code and Esri map tiles. This document will outline how JN is currently using (free) services from Google Maps, Google Maps API and Esri.

1995 – 2018

The observational reports maps—those that historically displayed all reports—were previously generated by the Journey North maintained Map Server application. These were not “live” maps.

2018-present

Journey North switched to using Google API. Journey North made significant updates to its mapping system by incorporating Google and Esri services. They now utilize the Google Maps Geocoding API and Maps JavaScript API. The Geocoding API converts city + state data into precise latitude and longitude coordinates, facilitating accurate mapping. Users can adjust locations on the map before submission, ensuring accuracy. The Maps JavaScript API powers the map widgets, allowing users to interact with draggable pins. Additionally, Journey North employs Esri's free map tiles and geocoding services to enhance mapping capabilities, providing an alternative to Google Maps. These advancements ensure precise location data and improved mapping experiences for users, enhancing the platform's functionality and usability over time.

Privacy Protected

User Interface: Maps

The Zoom level is restricted rather than using a system that relies on the geocoding that changes the latitude/longitude coordinates. Maps display rounded values, with only 2 decimal places of precision to plot location pins on maps. Current Zoom Level: Limited and Offset.  (1) Current Zoom Level = 13 (2) Scale 1: 288895.277144 or to City / Town Level Scale

User Interface: Query Result

Data tables display latitude/longitude coordinates to 2 decimals. Data in observational report bubbles display the latitude/longitude coordinates to 2 decimals.

Database: System for Storing

The data is stored to the original precision the user selects with the red marker, address, or directly when entering to the coordinates. Data is stored to the sixth decimals. Store latitude/longitude coordinates of each observational report on a secure UW Shared Host Server.

Database: Policy For Sharing

Publish data packages (EDI) latitude/longitude coordinates of each observational report to the third decimal.