Currently this is just a “WIP” as we explore and gather requirements of the project. The idea of an eAtlas is one by Sir Alan Wilson (Turing Institute):
A key message from the Foresight Future of Cities Project is the importance of interdependence: between urban subsystems and between associated planning and policy challenges. ~ Sir Alan Wilson.
There are some notes to read. These are thoughts and background reading material as we take steps towards understanding what an “interdependent” eAtlas might be. Would it be “Turing Geovisualization Engine”?
The front end is an npm package, so if you do not need the backend, having cloned the repo:
npm i # or yarn # and run npm start
The frontend is a
(CRA) so all the standard commands of CRA appliees.
The whole application is a geopumber app. That means it is an R powered backend API (think Flask in Python) and a ReactJS front end.
To build the frontend, from an R console:
Before you run the app:
you will need some preprocessed data, an RDS called “ac_joined_wy_2009-2017.Rds”.
you will need a Mapbox API key (will see if we can remove this) in
.env.localfile using variable name:
REACT_APP_MAPBOX_ACCESS_TOKEN = 'API_KEY'
in production its better to change the
Then you can run
or just run the front using (without any data loaded from local server):
npm i & npm start
Docker for production
Repo contains Dockerfile for production. This is again WIP.
# Dockerfile manages your npm/React build steps # REACT_APP_MAPBOX_ACCESS_TOKEN is required but app should run docker build -t eatlas . # then bind plumber's default 8000 port to any of your choice docker run -d -p 8000:8001 --name eatlas eatlas
Use your favourite document server (nginx for example) to proxy requets (more later hopefully).