Snap4City Hackathon 2019 Finalist: THE UNLOCKER (HELSINKI)

Description of the Application:

HELSINKEY - Opening the doors of Helsinki to people

1. What is HelsinKEY?

How often we find ourselves walking on a street, struggling to find a “place” close to us that could satisfy the need we have in that specific moment? We may just need a drugstore, a supermarket, a restaurant, a Bus Stop or a public Toilette – whatever.

The mission of HelsinKEY is to find that place and show it to you.

HelsinKEY has been built using the Tools and the Data (from Helsinki) available on Snap4City, and it is currently almost a Proof Of Concept.

It has indeed a simple and intuitive User Interface (a Snap4City Dashboard) optimized for mobiles, so that you can always bring it with you.

It currently supports “just” the search of Restaurants and Hotels, nevertheless, as shown in Section 3, its implementation (in NodeRED) has already the potential to integrate the support for the retrieval of any Service or Point of Interest (POI) around the user’s position.

It opens the doors of Helsinki, but it is not a key: it is HelsinKEY!

 

2. Using HelsinKEY
   1. What does the HelsinKEY Dashboard allow me to do?

The HelsinKEY Dashboard allows you to:

• Locate your position on a map along with your address
• Locate the 3 Restaurants and/or Hotels which are closest to you, and show them on a map.

The Dashboard layout has been optimized for the screen of a mobile phone.

2. What are the Widgets on the Dashboard?

The dashboard exposes the following widgets, see Figure 1 on page 4:

1. A map which shows your location and the location of the 3 closest Restaurants/Hotel (depending on the option you selected)
2. A Wizard which tells you how to use the App, and returns your position address and the name of the closest Restaurants/Hotels
3. The “Reset App” button to reset the Dashboard when it is opened (to clean up the dashboard from results coming from the previous session) and setup things to start a new search
4. The buttons “Restaurants”, “Hotels” and “Restaurants and Hotels” to instruct the App what it should look for
5. The Button “My Position” to retrieve your current position

 

3. How to use the App
   
   1. Open the Dashboard
   2. Press the “Reset the App” button to initialize the App and display a map – see Figure 1
   3. The Wizard will tell you what Search Options are available
   4. Select one option among “Restaurants”, “Hotels” or “Restaurants and Hotels” – for example “Restaurants”, see Figure 2
   5. Click on the “My Position” button --> the map will show your position along with the position of the Hotel/Restaurant closest to you;
   6. You can also navigate/zoom the map and tap on the Marker of the located Services to have some info about them – see Figure 3
   7. To start a new Search/Localization you must press “Reset the App” first (see the section Known Limitations and Area of Improvement) and then go back to point 3)

We suggest to use HelsinKEY on a mobile rather than a PC, so that your position can be detected with enough accuracy. In case the position is not accurate enough an Error message is displayed.

Figure 1 - Screenshot of the Dashboard waiting of the User to perform a new Search

 

Figure 2 - Screenshot of the Dashboard once the User has selected Restaurants (as confirmed by the Wizard)

Figure 3 - Screenshot of the Dashboard with the outcome of the Search (in this case Restaurants have been considered)

3. Node-RED implementation

HelsinKEY is meant to find and show on a map 2 kind of Services/POI close to the Users’s position and show their position on the map.

The current implementation focuses on Restaurants and Hotels, but as mentioned in section 1, it is potentially capable to retrieve any Services/POI just putting in place few changes.

• The first step is to retrieve the position of the User via the “My Position” Widget. “My Position” Node is a Snap4City Ad-hoc node (real name Geolocator) and its output is the position (Latitude, Longitude and Accuracy) of the device where the dashboard is displayed. When triggered, Geolocator sends multiple location messages (sometimes even duplicates) with different accuracies, pointing to different locations, in random order.
  To properly manage the above scenario, I implemented a logic which (see Figure 4):
  • Accepts messages from the “My Position” node only if the variable which stores the User Selections (User Position only VS Restaurants VS Hotel VS Hotel and Restaurants) has a value allowed by the system, please see the code in Safety Check Node for more details– this constraint ensures the rest of the flow is not broken by “unexpected” messages originated by My Position Node
  • Removes duplicated messages (RBE Node)
  • Joins all the messages coming from the previous node (Join)
  • Extracts the message with the highest accuracy and checks whether it is within a threshold accuracy (which I set to 30). If the message breaches this threshold, then an error message is displayed in the wizard, otherwise it is propagated. See User Position 2 Node.

Figure 4 - Nodes which filter out the "dirty" position messages coming from the “My Position” button

• Once the User’s Latitude and Longitude are retrieved, they are used to:
  • Retrieve the name and position of the Restaurants/Hotels closest to the User.
    Note: currently these nodes manage only categories such as Restaurants and Hotels – Nevertheless the flows from the Nodes “Filter Restaurant” and “Filter Hotel” are processed by the same nodes (Position of Interest 1,2,3) è this demonstrates that with few adjustments these nodes can retrieve the position of any Service/POI.

Figure 5 - Nodes which manages location of Hotels and Restaurants

 

• Retrieve the address where the User is located (See location address 2 node).

Figure 6 - Nodes which retrieves the current User's address location

 

• Messages coming from the above 2 flows are then merged before being displayed on the Wizard, see Figure 7.

Figure 7 - Creation of the final message to be displayed on the Wizard merging the messages coming from the 2 flows (User Address + Closest Hotels/Restaurants)

 

• The Search Option (Restaurants Vs Hotel Vs Both) selected by the user is saved in a global variable named "final_choice" - See the nodes named “Take the choice”.
  The whole workflow depends on "final_choice", so that operations for the search of a Restaurant or Hotel can be performed properly.

Figure 8 - Nodes which store the option selected by the user

• The map does not appear when opening the Dashboard, so I created the “Reset App” button that the user must click as soon as he opens the Dashboard – this will trigger the appearance of the map  (Node Map URL).
  “Reset the App” is also used to clean up the map from old results to start a new Search (see Reset the choice).

Figure 9 - Nodes which force the Map to be displayed

 

4. Areas Of Improvement

HelsinKEY can be enhanced to:

• Show Hotels and Restaurant Addresses and other info relative to them (if available)
• Support more services than “just” Hotels and Restaurants, to fully exploit all the Data available in the Snap4City Ecosystem

Currently the App does not manage properly the scenario wherein the search of Restaurants/Hotels returns no results.

Note: Since I could not go in person to Helsinki, I tested HelsinKEY using a GPS simulator on my mobile which sent to the App the position of a user located in Helsinki.

 

Dashboard(s) URL and/or name(s), if any:

• Name: HelsinKEY
• https://www.snap4city.org/dashboardSmartCity/view/index.php?iddasboard=MTY1MA==

IOT Application(s) name(s), if any:

• Name: HelsinKEY