Project Proposal

1. [Introduction](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#introduction)
2. [Background Information](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#background-information)
3. [Objectives](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#objectives)
4. [Methods](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#methods)
5. [Conclusion](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#conclusion)

Below are rough descriptions of what should go into each section of the report. See the relevant issues in the issue tracker for more details / discussion.

Introduction

• Introducing the concept of the "Internet of Things (IoT)
• Proposed benefits / reasons for the existence of IoT
• Definition of the OGC specification for the IoT
• Reason why we're using the OGC specification
• Aims of the project
• What we hope to accomplish

See issue #2

Background Information

• What is the Internet of Things (IoT)
• What is the Open Geospatial Consortium (OGC)
• What is the OGC specification (OGC RESTful API) that we are using
• Why we want a common API

See issue #3

Objectives

• Finding a sensor setup to add to the Internet of Things (IoT) / Sensor Network (SensorWeb) that can measure information relevant to us locally
• Develop an intermediate library / interface for the sensors to the OGC RESTful API that is being hosted on Dr. Liang's servers
• Develop some user interface (UI), such as a mobile application or web page, that uses sensor data in some fashion.

Expanded further (but still rough...)

This project is presented as one general umbrella goal, which is broken down into smaller objectives and sub-objectives. Overall goal: Use the Internet of Things to tangibly assist the citizens of the city of Calgary in a practical and user-friendly way.

Objective #1: Determine a location-based application of the IoT which is relevant to the city of Calgary. Further details: Define a problem relevant to Calgarians (or a particular sub-group of citizens, such as civil servants, university students, environmentalists, etc.); specifically identifying a component which can be measured and the importance of its spatial properties.

Objective #2: Design a sensor setup which can measure data suitable for the application determined in objective #1. Sub-objective:

• Determine technical requirements necessary for data measurement (e.g. sensor(s) required, other periphery elements needed)
• Create a working prototype of a sensor which could be deployed in the city
• Test prototype in at least five different locations

Objective #3: Develop a library which links the sensor and the OGC RESTful API Sub-objective:

• Learn necessary language(s) required for writing a library which will work with the chosen sensor setup
• Collect test set of data with multiple sensors in a working/usable configuration in the city

Objective #4: Create a user interface (UI) such as a webpage or mobile application which makes use of the OGC RESTful API to display the sensor data. Sub-objective:

• Design user-friendly graphical interface which is tested and found intuitive by at least 80% of test subjects
• Represent collected data (in real time) using the created user interface

See issue #4

Methods

• Sensors used / considered
• How we plan on creating the library / interfacing with the database
• Programming languages we may consider using for the task
• Organization / management (project will be managed and tracked through github)

All sensors will be interfaced using a single board computer. These computers are well suited for DIY, educational, and prototyping projects due to their low cost and the wide variety of available sensors. The board chosen for the the project is the Raspberry Pi. This was chosen over the Arduino Uno due to the following projected constraints:

Connectivity: The computer must be connected to the internet so that sensor data can be accessed. The Raspberry Pi includes an Ethernet port by default, and an external WiFi ($10) or 3G ($27) dongle can be attached. The Arduino has WiFi ($70) & GSM "shields" ($115) .

Performance: The Arduino board is built around a micro-controller with lower specs than the Raspberry Pi. The Arduino is clocked at 8-16 MHz processing speed with 2-8 kB of RAM available. The Raspberry Pi features separate CPU & RAM and boasts a 750 MHz processor which can be overclocked up to 1GHz with 512 MB (shared with GPU) of RAM available. Depending on the application, either could be suitable.

Power consumption: The computer & sensors will need to be powered by an external power source. The Arduino has much lower hardware specs than the Raspberry Pi, and as a result consumes less power. The sensors & network connection are likely to be the dictating factor in how much power is being used.

Cost: Costs of the boards themselves are similar, the Arduino Uno costing $30 and the Raspberry Pi costing $35. External sensors for the Arduino are generally more expensive than Raspberry Pi, as they must be built to work with the Arduino specifically. Sensors for the Raspberry Pi have the benefit of being able to connect via USB and as long as they are Linux compatible, it is likely they can be used.

Sensors considered

For the location of the device, the sensor set-up will likely be one of two situations:

• If the hardware was designed to be used in an application where the sensor is moving, a GPS receiver will likely be included. //Add considerations for including a GPS sensor
• If the sensor is to be placed in a location for long periods of time, and gathers spatial data of a different kind (ie image based) than the unit will likely not require a GPS receiver.

Other sensors that could be include are: Image (webcam or camera), Sound, Meteorological, Distance, Magnetometer, //some other stuff

See issue #5

Conclusion

The Conclusion of the proposal will not be completed until all the other sections have been, so it is not entirely useful to mark down what will be inside of it now, but it is important to track that it should be done.

See issue #6