========================================================================
   2E3 CONSOLE APPLICATION : Road condition data sourcing
========================================================================

Compile information:
	Program was compiled in Windows 10 using the VS2015 toolset (v140).
	Compatibility was also checked using the VS2012 toolset (v110) to ensure functionality
	accross different versions.
	An executable compiled with the v110 toolset is also included in the event that the new
	toolset is not installed on the target computer

General usage
	When running, you are requested to enter a time step and threshold value.
	After this, the data begins to be collected and printed to the screen.
	After the EOF has been reached, a new list of the values over the threshold
	are printed in descending order, as well as the average acceleration.
	At any time during the collection process (i.e. after the paramter requests)
	you can stop gathering data and print out the descending list and average
	by pressing the 's' key (as in stop), or you can quit by pressing the
	'x' key (as in x-it)

Raw data acquisition
	The data acquisition is simulated in the GPS and Sensor classes. Both have a
	instance of the FileReader class in order to obtain the actual data.
	When the sensor classes are created, they open a filestream to the supplied
	path of the data, which is kept open until the EOF is reached. When the
	getLocation() or readAcceleration() functions are called, they return the
	next set of data in the respective files (Rather than reading all data
	into a list at once at the start of the program).
	Every time data is requested from the FileReader class, it checks itself
	for an EOF condition, and if true, closes the filestream.
	The classes were made with the intention of being indiscernable to the
	wider program of not being an actual GPS coordinate. As such, in order
	to advance the program into using an actual GPS or accelerometer device,
	only these classes would have to be modified, leaving the main code intact.

Timed data requests
	At the start of the program, the user is requested to enter a time step, after
	which data is retrieved and printed to the screen continously with the
	required pause between. This is done by spawning a data retrieval thread which
	runs concurrently with the main program thread and loops continously while data
	is to be retrieved. At the start of the loop, the "starting time" is recorded. Data
	is then acquired, added to a holding object, added to a list etc. At the end of the
	loop, the "ending time" is recorded, and the time spent during that iteration is
	calculated. The thread then sleeps for the required time (timestep - time doing)
	before repeating for the next set of data.

Use of data
	The GPS data is stored as an instance of the Coordinate class which contains two
	floats as the latitude and longitude values. The acceleration data is stored as
	a Vector3 from the Vector class whcih contains 3 floats for (x, y, z), as well as
	some operator overloads. The Coordinate and Acceleration data at a particular point
	in time is stored as a collectiveData instance, which contains a Coordinate instance,
	a Vector3 instance and the time the data was acquired (relative to the start of the program)
	The collectiveData class also contains a pointer to an object of the same class as it is
	to be used in a linked list.

Lists
	2 singly linked lists are used in this program. One contains all data in the order
	it was acquired, while the other contains only the data over the requested threshold
	in descending order. Both contain individual copies of the collectiveData instances
	as there would be an issue with sharing "next" pointers should the same instances
	be used. The lists are instantiated with the CustomList class, which contains
	add() and add_in_place() functions to add in retrieved order and descending order.
	A binary search tree was considered for the ordered list, however I found that when
	attempting to print the tree I was created a linked list from the tree to simplify
	the process, so forgoing the tree altogether was the most efficient choice.

Main program flow
	Timestep and threshold requested -> New data printed to screen when available -> Loops checking for key presses	-> When gather is finished, print the average and descending lists -> Wait for user request to exit.
									 -> Data gathering thread begins executing	-> Lists are populated -> Thread ends at EOF or 's' key pressed
									 -> Key listening thread begins executing	-> When a key is pressed, give its value to global variable	-> Thread ends with end of main thread

Additional features
	-Console formatting
		Console formatting is supplied through the ConsoleControl class which was written
		for the tic tac toe lab of week 2. With this class, you can safely and easily:
			-Change the text and background colour
			-Clear the console window
			-Change the title of the console window
			-Change the size of the window
			-Get and set the cursor position to draw tables/text with precision
	-Threading
		The data gathering and key listening happens in seperate threads to reduce
		interference between the main functions as well as to allow concurrent
		listening, printing and data gathering
	-Key listening
		The key listening is handled in a thread seperate to the main thread.
		As such, the thread can sit waiting for user input while the main
		thread executes as normal, checking once per loop to see if a key
		has been pressed.
	-Adjustable timing
		Using the clock() and sleep() functions, the program runs only when required
		and sleeps for the rest, cutting out uneccesary computations and improving
		efficiency (slightly).
		For example, the main loop need not run more than 60 times per second, and
		is therefore capped at this loop frequency.