CartoCosmos

Project Description

“Space Exploration is important research for economic and national defense, and America’s space program is a symbol of our success as a scientifically and technologically advanced nation” - Randy Forbes

A big part of space exploration is sending spacecrafts into space to orbit planets, collect large amounts of data, and take images. Scientists then create maps of these planets by using the images and data collected. These maps play a crucial role in learning more about a planet and its surface. In order for researchers to use planetary mapping and collect data NASA told USGS to create a way to view maps of other planets virtually. Trent Hare, a research developer and data processor for USGS, is in charge of promoting planetary mapping by attending expos and finding others to get involved in creating a way to view maps of planets virtually.

Current Issues

The USGS team created a planetary mapping application by modifying version 2 OpenLayers, an open-source mapping application. The mapping application has been very useful to many researchers for displaying USGS’s planetary data but it has many drawbacks.

USGS Moon Map

There are two main drawbacks when it comes to their current implementation. The first being that OpenLayers does not support planetary mapping. All the different maps USGS created for the different planets and moons think that they are still Earth. They are currently “faking” the data (modifying the data based on conversions from one planet or body to Earth) to map all of these different bodies. This causes the data to be represented inaccurately. The second major drawback with their current implementation is that the current codebase for OpenLayers is not modular. The Openlayers codebase has updated its code to an entirely new codebase that no longer supports the code written years ago by USGS. Since their code is not modular, the USGS development team is having to rewrite the OpenLayers code to make the planetary maps work with the updated version of OpenLayers. Without the code being modular they will always have a development team because there is no long term solution when working with just OpenLayers. Their code needs to be modular so that even if one open-source mapping application fails or does not support the code anymore, they will still have a program that works.

USGS Current Solution

Envisioned Solution

Our envisioned solution is to create a JavaScript node package containing the required mapping translations that can be used across multiple mapping applications. We will also build a Leaflet mapping application that will use this package to display maps created by USGS.

The application will allow users to zoom, move the location of the view, select an area on the map, see gazetteer names and symbols on the map, use variable radii, convert between 0:360 and -180:180 longitude ranges, convert between ographic and ocentric latitudes, and load data layers. The Leaflet application will connect to the USGS database containing data on their maps and have an autocomplete search to find maps from the database. Two end goals of this project are to have our node package incorporated into the Leaflet API and to allow the USGS team to use our package in their OpenLayers implementation.

Project Proposal

The initial concept for this project was provided by our sponspor USGS, in the form of a Capstone project proposal.

Download Here

Photos by NASA/USGS | Design by TEMPLATED and Scott Ames