A 2 Green

Boomtown Hacks
Team Name: 
Boomtown Hacks

Team Boomtown Hacks is a ad-hoc team made up of some friends from around Adelaide. The team constsis of 4 people:

Jordan King - Developer and a smooth video voice.

Sam Trezise - Graphic Designer, held the ship together.

Haydn Dyer - The UI guy, the only one who has used Angular before...

James Mackay - The data guru, actually spend hours working out the parking data!!

The Application

http://www.a2green.com.au

Profile page materials: https://www.dropbox.com/sh/8qst0mj1gvjbrc6/AAAS49nKiL7PrAJr-QdXKCI_a?dl=0

All of our source materials: http://https://www.dropbox.com/sh/p59vrvwuztssfo6/AACHujmM2l8_zvHz8hJp1ge6a?dl=0

GitHub: https://github.com/kingy68/a2green

Our application, built entirely over the 48 hours, is called A2Green.

Note: the app only works for travelling into the Adelaide CBD!

Essentially the issue which we wanted to solve was what method of transport was the best option taking into account the following factors:

  • Quickness
  • Cheapness
  • Green Friendly
  • Availability

We all agreed that every time you're about to head into the city, you generally question what the best method of transport is (we even did it during the GovHack weekend). So what if we could provide a simple app, where you enter your start location and desination (only in the Adelaide CBD) and we give you our calculated options. We didnt want to choose the option for you, as you may have specific reasons to take your mode of transport, rather, we just present the options and let you judge it for yourself.

The Transport Options page takes into account the following factors as calculations:

  • How many car parks are there at the nearest street parking location to your destinations,
  • The price of driving into the city, this takes into account car usage factors like; tyre wear, servicing, fuel costs and the average cost for a 2 hour car park stay,
  • The traffic congestion, which is calculated by the distance you have to travel and the time Google tells us it will take, to get an average meters per second calculation.

We also present the nearest metro option from Google, and also a Bike option, which gives you the estimated calorie burn for the ride.

If you then do choose to drive, we then present you with the nearest street parking and U-Parking options and show some details about them. Once you decide which one you want to use, we will then show you it's location on a map. At this point of the app, we also let the user know the current days Air Quality Index for the Adelaide CBD, which might pursuade them to take a more carbon neutral option.

How It's Built

The application is Web Application for mobile, built on the Angular framework and adapted for mobile using http://mobileangularui.com/.

The soulution involves a number of datasets from South Australia:

  • Adelaide City Council - On Street Parking Zones
  • Adelaide City Council - UPark Car Parks - Available Spaces
  • Environment Protection Authority - Recent Air Quality

We also used the following development tools:

  • Free hosting on Amazon Web Services ($100 GovHack voucher)
  • Free developers account for Google Maps API

Where to Next?

We think this application has the potential to be expanded for a range of other car parking areas around Australia. All it needs is the parking data available to plug in. It would also be cool to incooporate this application into a full mobile parking solution where you no longer need to get out of your car and buy a ticket. The idea would be to let the user pay for their park on their phone, then a parking sensor would start timing their stay. As they get closer to the end of the stay they would be reminded that they park is to expire soon. It would also have a cost saving and efficiency effect on the Council themselves, as their inspectors could also be notified of soon to expire parks with cars still over the sensor. This would allow them to better decide where to go as an inspector. However, once the sensors are in place, the majority of the ticketing could be automated all together!

What We Didn't Get To

We had hoped to bring in real-time Adelaide Metro arrivals data, however, we were too pressed for time and never got around to it.

We also would have like to provide users with multiple parking options, but we didnt get to that either.

P.S. Jordan would also like to personally apologise to EPA, I called you EMA in our video and never got time to change it!!

 

Used Datasets: 
Dataset Name: 
On Street Parking Zones
Publishing Organisation/Agency: 
Adelaide City Council
Jurisdiction of Data: 
Local Government
How did you use this data in your entry?: 
Our goal with the street parking data was to create a dataset that could be filtered by day, time of day, expected duration of parking, and whether or not a ticket is required to park, as well as contain latitude and longitude coordinates to find the nearest available spot to any location. To accomplish this, we took the following steps: We read the input CSV file and did some data cleansing to remove the three header lines as well as records with a “0” value for parking spaces, these being places where parking is not allowed. We also did some basic cleansing at this point, and removed records from North Adelaide to limit our area of interest to the CBD. This was done using a combination of string matching and coordinate checks. We then wrote scripts to generate a list of unique values for the primary condition field, along with the other condition fields. These lists were analysed to determine how to parse these values. To temporarily simplify the data, we then eliminated parking spots with primary conditions indicating they were intended for specialised purposes, such as buses, taxis, and motorcycles. Although some of these had secondary and tertiary conditions indicating they may be available to motorists at particular times, for a first run we eliminated all of them in favour of simplicity. Next, we eliminated records indicating they are residential- or permit-only parking at all times. Next, we eliminated records with banning stopping and/or parking as a primary condition that only allowed loading as a secondary/tertiary condition. For parking spots that are unrestricted at all times, we created a single output CSV line. For parking spots with time limits or ticketing requirements between certain hours, we first created a single output CSV line with the “from” and “to” times along with the conditions. We then reversed the hours and created a second record without conditions. For parking spots that do not allow parking between particular hours, we created an output record with the hours inverted, indicating that parking is allowed outside of the hours. For spots that indicated parking had restrictions from Monday to Friday but had no restrictions on weekends, we created a record exclusive to Saturday and Sunday that indicates there are no restrictions for these days. We then converted this CSV data to GeoJSON using QGIS Desktop. The client application then loads this GeoJSON into memory and iterates through the records, filtering based on attribution such as the day and time of day (as well as an assumed two-hour stay). For each record that satisfies the requirements, distance is calculated between the desired location and the record’s coordinates (although we use Cartesian distance with latitude and longitude, for a small area of interest such as the Adelaide CBD it’s accurate enough). The matching parking spot with the minimal distance is returned to the user. There are several enhancements that could be made to this data in the future, particularly: Expanding the logic to properly handle secondary and additional conditions. In most cases, these were disregarded. Handle specialised types of parking such as motorcycle parking. Using the length and distance from reference point values in the original data, along with accompanying road data, to convert the point geometries to lines or polygons. Putting the data into a GIS application server to minimise network traffic and memory footprint. If street parking sensors are incorporated in the future, indicate how many spots are available in each parking zone.
Dataset Name: 
Recent Air Quality
Publishing Organisation/Agency: 
Environment Protection Authority
Jurisdiction of Data: 
Government of South Australia
How did you use this data in your entry?: 
The Air Quality index data was used to provide the user the current Adelaide CBD AQI value. This is to provide them with another source of information when making the choice to drive, metro or ride into the city. The idea was that for those who are more green friendly, this factor may persuade them to not drive and to take public transport or ride their bike instead.
Dataset Name: 
UPark Car Parks - Available Spaces
Publishing Organisation/Agency: 
Adelaide City Council
Jurisdiction of Data: 
Local Government
How did you use this data in your entry?: 
Our goal with the UPark data was to help assist a user’s decision between street and garage parking knowing that the closest garage may be at or nearing capacity. To incorporate this data, we created a scheduled task that runs at five-minute intervals to download the XML data for each garage onto our own server, which was necessary due to CORS issues. The client application then reads the number of available parking spots from the files on our server. In addition to this, we manually captured garage locations using Google Maps and created functions to calculate whether each garage is open (most have different operating hours) as well as costs (although this is simplified).
Event Location: 
Adelaide