jonsowman / cusf-standalone-predictor Goto Github PK

Plot the coords in the scenario.ini file as the launch point rather than the first entry in flight_path.csv

Put the lockfile system back in place so only one user can run the predictor at a time

put the form back in for running a new prediction

Client should die gracefully, increase the lat/lon deltas, and automatically begin another prediction

Launch, burst and landing markers should show Lat/Long/Time/Range

Display the error, reset the GUI to onload state, ready for another try.

allow user to choose between a fast prediction with GRIB data or a potentially slow one with GFS/NOMAD data

Another copy of the parameters is appended. Check existence before writing.

Probably also in the Scenario Information box

Server should automatically purge predictions with dates older than a given number of days, maybe 7 or 10.

specifically, chrome's "waiting for" dialogue covers the debug window

and generally testing on browsers other than FF would be a wise plan

make one to stop adam crying all the time.

Installed required python and linux packages, builds the predictor, sets up config files.

Generally does everything required so that the user can just run it and then hit index.php in their browser.

If requests keep timing out for progress.json, increase the timeout and the polling delay.

This script can be part of this repo so deploying this predictor need only involve cloning this repo.

It is a modified version of the get_wind_data.py script from the CUSF hourly predictor.

ie. when prediction running

With a web interface to add a new launch location, preferably.

For simplicity.

Show (UTC) after all displayed times including flight time and launch card fields.

make landing and launch and burst points clickable for info

make info box show distance from launch & landing sites of mouse cursor position, and mouse cursor coords

User can download their scenario.ini file for a given prediction, and then use it to populate the input form later.

somehow work out and write to a file which GFS data file the predictor used for a run, for the $grib* variables

Instead of displaying nothing and looking like its broken

make a nicer web interface, perhaps based on the hourly predictor one

Therefore when the form has been submitted and the prediction is running, the launch card contains the details the user just submitted.

If 2000ms is still too low, we need to increase the polling delay (eg. every 5-10 seconds) instead of just cancelling the poller.

Needs testing to see if GPRS connections etc really will require >2secs for the AJAX request to return.

generate KML files and add download link to both filetypes

Rationale:

1. Roads aren't a consideration in planning a balloon launch through the predictor, i.e. they are clutter and make it harder to focus on the trajectories
2. Terrain view nicely highlights urban areas which we can then seek to avoid

The user can click the map to say "launch from here".

After clicking "Run Prediction", the data request should be sent to the server and the client polls for status.json, which contains:

1. Progress on getting GFS data & when complete
2. Prediction started
3. Prediction complete (client then grabs CSV and displays it)

Client must verify "prediction_complete == true" before trying to get a CSV and display it (even for index.php?uuid= predictions)

This can be done entirly server side by PHP. Instead of pre-populating the form with the default values, it should check if it was given a UUID in the querystring and if so, populate the form with data from that UUID's scenario.ini.

Loads of old stuff from the GRIB predictor and unused files lying around, needs a good clean up.