× This Challenge was posted 3 years ago

Challenge view

Back to Project

104: Flat finder for seniors

Enabling seniors to find a place that fits their needs.

⛶  Fullscreen ↓  Download

Problem

As we grow older, our needs and requirements for living change. Finding a suitable house or apartment can be a real challenge for all of us - but especially for the older population. Seniors face numerous housing challenges, including for example affordability, physical accessibility, and access to medical and other services inside and outside the home. Conventional housing platforms rarely take into account the specific needs of the older population in their search criteria. With this challenge, we want to change this.

Goal

We want to enable senior citizens to search for an apartment or house online. The goal is to implement predefined search criteria in any programming language in order to develop a prototype platform that finds suitable apartment or houses for senior citizens. Criteria may include accessibility to services & infrastructure, lift, barrier free accessibility, public transport access, services, outdoor space, neighbourhood, etc.

Data sources

  • List of relevant search criteria (ranked according to target group's needs)
  • Housing advertisements from the city of Lucerne, collected via Immoscout24 API
  • Open Street Maps

Here the slides to the final presentation: https://docs.google.com/presentation/d/e/2PACX-1vQYHERpmwUBu3bPQUQB-Z-bLQt6c0kLKMZeJRRDRzoP6Mlw_ZjrklHSqTpY2Yc6lrBwRdffXoO0leZn/pub?start=false&loop=false&delayms=3000

You will find the link to our Tableau-visualization prototype here: https://public.tableau.com/profile/francisco.borge8567#!/vizhome/prototype_luzern_60_plus/Lucerne_60_plus_prototype

You will find further illustrations of the workflow and very simple user interface in the images below.

Detailed description: The idea is to have a very simple user interface where seniors can select the most important search criteria for a new flat. They can choose between must-have criteria and should-have criteria. The search mask then queries the database which stores the json-data we already downloaded daily (according to a schedule) from the immo websites. These data are already enriched and tagged by NLP processes with a custom built NLP model. This is a huge added value as the json-files representing a flat advertisement often contain a "False" for information that has not been entered by the flat owner, but the text description actually does contain such information. An example would be "pets allowed" or "wheelchair accessible", which often have "False" in the json file, hence one would assume that the flat does not fulfill that criterion. But when one does an analysis of the text description, one can often see that the text box indeed does contain verbal information like "pets allowed upon request" or "barrierefrei". It seems that instead of ticking all relevant boxes when publishing a flat advertisement, people rather use the text description to provide most necessary information. Further, some information like "sonnig" / "sunny" are typically based on personal interpretation and thus only represented written in the text description. Our NLP model takes this into consideration by doing text analysis and keyword tagging, by which the data is enriched and stored in our MongoDB store. From there, whenever there are search criteria activated in the user interface, the enriched and tagged data are being queried and ranked according to the best fit of the criteria. Then we have two types of result representation: a very simple one like a list with pictures, description, price and contact info as well as an interactive map -even with changeable search criteria again. The link to the interactive map prototype is in the project link below. Here is a more detailed description of the backend-processes: All data is fetched with an HTTP Client via the Immoscout24 API periodically. We first had to fetch all the elements on the overview page and for each flat the program loads the detailed information. The JSON file is then stored in a mongoDB. For the web UI we provide a RestAPI which can handle different search criterias. For the purpose of this prototype we only use the criteria accessability. This criteria is than passed to the FlatFinder module which queries the mongoDB and returns the data in JSON format. The NLP Pipeline was build as well but not integrated in this prototype.

Here is our very simple and basic user interface with the search mask:

Title

Here is the whole workflow in a very simple and basic manner, just to understand conceptually:

Title

And here is the detailed backend workflow process:

Title

Contributed 4 years ago by luca_h for Shape My City
All attendees, sponsors, partners, volunteers and staff at our hackathon are required to agree with the Hack Code of Conduct. Organisers will enforce this code throughout the event. We expect cooperation from all participants to ensure a safe environment for everybody. For more details on how the event is run, see the Guidelines on our wiki.

Creative Commons LicenceThe contents of this website, unless otherwise stated, are licensed under a Creative Commons Attribution 4.0 International License.