NASA Space Apps Task Roadmap

[zubearc]

NASA Space Apps 2023

The full prompt for the 2023 NASA Space Apps Challenge can be found here.

Planned Goals

The (specifically-defined) wanted changes to the VISIONS applications in the prompt are as follows:

• [x] 1. Incorporate ECOSTRESS into the VISIONS application
• [ ] 2. Incorporate GEDI into the VISIONS application
• [ ] 3. Add area-and point-based subsetting
• [ ] 4. Add production of a heat map indicating the number of images available at a given location
• [ ] 5. Add the ability to alert users when new data has been delivered or forecasted at a location of interest

Other Important Changes

• [x] Improve the performance of the application
• [x] Host a static version of the application on GitHub Pages
  • This may require a refactor of some of the code, to remove the dependency on a database and instead expect the data to be in a static format hosted on a web-server. This will also keep deployment costs basically free, with a server only necessary to occasionally update the data when new upstream data is available.

Aspirational Goals

The aspirational goals for this project (if time permits) are as follows:

• Add a language based interface utilizing OpenAI's GPT-3.5
• Explore how to enable arbitrary data sources to be added to the application without requiring a code change

Progress

This area will define what progress has been made on the project, and what is left to do.

[zubearc]

After a lot of trial and error trying to expand the current codebase, I think it's going to be much easier to extend MMGIS if it were to be refactored with a modern web stack. Namely, splitting up the frontend and backend code will enable hosting the frontend statically, and even get some cool demos without needing to host anything. The old code architecture's deep backend/frontend integration made this not possible.

Based on the current refactor with React so far, this seems much easier than initially anticipated, albeit it's going to be time consuming as there's lots of functionality to migrate over. Having substantially less code should will also make maintainability much easier.

[zubearc]

I think that's a wrap for the hackathon stuff...

The frontend has been rewritten with React, split from the backend code and the backend code has (mostly) been linted to improve code consistency and even fix some errors lying around in the backend. For rapid work on the frontend during my dev, npm start runs webpack on just the frontend (backend optional, can poll layers from a local .json file) ; node scripts/server2.js will boot up the backend server with the frontend code integrated like the old npm start (this is just for fast dev). Since the frontend is a complete rewrite, many features are missing (side panels/globe view, layer configuration, some overlays, layer rearrange is kind of broken, etc.), however these are mostly trivial things to re-add, I just had to skip them as spending time fixing bug after bug with feature porting isn't a great way to spend time at a hackathon. Some of the code needs to be cleaned by up removing comments and splitting up the frontend code from one .jsx file to a few other .jsx files. Also, the backend code can also be simplified a bunch, but no time for that obv. :)

Anyway, to doc my work as far as ECOSTRESS data: the code to grab this data is in https://github.com/zubearc/MMGIS/tree/react/tool/download-ecostress -- I commit that to a GitHub repo at https://github.com/zubearc/nasa-ecostress/. This repo contains .h5 and .xml metadata without an authwall, so I can easily host and reference the data. The .h5 data link is stored in the GeoJSON, so I can put up an