OpenPark – solving the Parking issue in the city

Recently, I was the studying the Beacon technology, and more precisely the Eddystone format.

Beacons are cheap devices that could be deployed anywhere that has a meaning for your business, for the city but even more importantly, for the user. (If you want to know more about beacons, I gave a talk at DroidconParis in november 2015, so check out the video).

I also participated at a hackathon on Intelligent Mobility early October 2015 in Bordeaux, France. There, I exposed two solutions for solving a global problem that lots of cities are facing (regarding the Public Parking Places).


I made the local news 🙂


I live in a big city, and if you are a car driver living in that kind of big city, you should probably know that it’s a nightmare to find a public parking place available. We often waste a huge amount of time looking for a place, we get stressed, we pollute, we generate congestion. That should end, and for good.

Solution #1

Of one the solution could be to deploy and glue Beacons on the field and thus, equiped each public parking place with a beacon. The beacon would have an extra proximity sensor that could detect whether a car is parked above it or not. Thus, we could have, in real time, a network of availability places in the city.
Based on this real time data, a simple mobile application could then drive you to the nearest public parking place in the city.
It is a cheap investment for the city (glue-ing a beacon on each place) but could dramatically de-congestion the traffic.

Cons of solution #1

The solution #1 is cost effective but has some limitation. Firstly, an enhanced beacon has to be designed. This enhancement requires R&D to include a power efficient proximity sensor on top of the beacon.
Also, the beacon has to be rugged so is won’t break out on the car’s weight. Also, it has to be protected from weather (snow, rain…). So this enhanced beacon requires some technical challenges.

Solution #2

The solution #1 is a good candidate for solving our issue, but requires more engineering. The idea is to find a solution that is simple and easily deployable. That’s solution #2.

Instead of deploying and glue-ing beacons on each public parking place, what about having a beacon inside each car, in the glove compartment ? This beacon would stay is the driver’s car and paired with driver’s smartphone. So, whenever the driver is parked and is leaving his car, his smartphone is able to detect that he is moving away from his car (because beacon is all about range, so you can easily detect that you are in or out of the range of your beacon).

Having this information, your smartphone knows that your car is parked now and that in this precise location, the parking place is no more available.
Similarly, when you are getting back to your car, your smartphone will detect the beacon and then consider that you will leave the parking place. This information could then be broadcasted and anyone who is looking for a parking place in the area could be notified of that availability.

What’s next ?

I highly think that this will solve for good the issue of parking your car in any big city.
In term of investment, the city could give away a beacon for each driver, for free. The investment is really low compared to the issue it is solving (less pollution, less congestion, less stress, more happyness).

If you want to be part of that adventure and make the world a better living place, please contact me, I would be more than happy to have your collaboration.




OAuth2 and Google OAuth Playground

If you are a developer, chances are that you are using APIs that requires authorization to be used. That is especially the case with most of the Google APIs. So, you should at least be familiar with OAuth2.

The aim of this article is not to describe what OAuth2 is (there are dozens of literature on it), but simply a reminder of the standard, and pointers on how to use Google OAuth2 Playground which is a super easy interactive demonstration tool using Google APIs.

OAuth 2, reminder :


OAuth2 is not an authorization protocol, it’s a secure delegated access protocol. In this manner, you have to consider 4 distincts roles within this process : 

  • the ressource owner (typically you, or me or anyone…)
  • the ressource server where the owner stores his data (for instance entries in Google Calendar)
  • the client application (webpage, android app…) that will need to access the ressource of the owner (to display the Calendar entries for instance)
  • the authorization Server that grants access to the application (based on the owner approval).


Whenever the client application needs to access a ressource, it first asks to the authorization server a Token (access or refresh token). This token is then used to access to the ressource located on the ressource server (the token could be passed in various way, but the most common is through the header of the request).


Token are used in a defined scope, which is a spectrum of ressources accessible with that token.

Google OAuth Playground

Google OAuth Playground is a sandbox where you can play with OAuth2 and the APIs that support it. For our use case, we will test the Proximity Beacon API which requires OAuth2.

There is already a description of the process for authorizing and Authenticating Proximity Beacon API requestsbut we’ll cover that with some screenshots.


As described on the documentation, the first thing you need to do is to go to the Google Developers Console, create a project, activate the Google Beacon API, then go to the Credentials Section in order to get a client ID for a web applications (that we’ll use for the Playground)



Be carefull to set as a redirect URI


Go to the the OAuth 2.0 Playground and configure the OAuth Credentials (generated previously from developer console. Copy paste it there, as shown below)


On the left side menu of the Playground, you have to set the scope for the Proximity Beacon API into the field labeled Input your own scopes

4. Scope

As a result, the token will be generated and automatically used for next steps.


Now, all the magic comes, you can request your API that request authorization (for instance


As you can see, you can add headers, add request body and so… In a word, you can easily test the API you are interested in and see the full result (header & body) 🙂

You’ll get the response of your request which requires authorization 🙂


Do not hesitate to over use this playground, it should definitely be used as part of API exploration (more than reading static documentation 🙂