Weather Station Analyzer

Weather Station Analyzer is an application used to analyze weather station information and determine which stations can predict the data of others. The software will take in 5 input parameters: start year, sample period, temperature and precipitation tolerance, and accuracy range. Using theses inputs the program will search, sort and graph the requested stations, then identify which weather stations are redundant and may be removed while keeping weather readings accurate.

The application makes predictions by first placing all stations in a un-directed edge weighted graph, After this the graph is converted into a minimum spanning tree while only keeping edges between stations whom's weather data is accurate to one another's within the user's specified tolerances. At this point the nodes with the greatest number of edges is removed, which leaves one of three node types. The first are stations which cannot be used to predict other stations, the seconds stations used to predict stations, and the third stations predicted. At this point the program then checks if the new layout is still accurate within user tolerances and to do this the program checks the layout over two additional years. At this point all data processing has been completed where it is put into a Json file and is displayed for the user.

On the technical side, the program uses a Model View Controller design. The Model being the backend which is built in ruby and harnesses an SQLite3 database for the data storage and manipulation. The Controller is the server which uses the Sinatra API to effectively connect the Front-end to the Back-end. The View is written in HTML/CSS/Java-Script, and uses an electron wrapper to allow it to act as a standalone application.

Project Reflection

Results of this project where less than ideal. More stations were expected to be predictable. If there are future attempts to implement this project there are a few things we would do differently.

  • We would implement the database using MySQL instead of SQLite3 for the extra speed gained for large data sets. This would also allow for more scalability as it could be used on a external server rather than a local server
  • We would implement a Streaming API instead of a REST API, so that the large data set would not be transmitted all at once.
  • We would further decouple the frontend from the backend and decouple the frontend from the electron wrapper itself.

Project Details

Date: April 13, 2016

Authors: Pedro Oliveira, Pavithran Pathmarajah,
Pareek Ravi, Kunal Shah

Course: SFWRENG 2XB3 - Software Engineering Practice and Experience: Binding Theory to Practice


Meet the Team

Pedro Oliveira

Pavithran Pathmarajah

Pareek Ravi

Kunal Shah