Course:CPSC312-2019/CityRanker
City Ranker
Authors:
Kavya, Paul, Petal
What is the problem?
We created a tool that allows users to compare different cities around the world based on certain quality of life indices. This could be useful for anyone looking to immigrate to a new city based on certain criteria, or simply to learn more about a city.
Users are able to create queries involving over 250 cities, using any of the following quality of life indices: housing, cost, startups, travel, commute, business, safety, healthcare, education, environment, economy, tolerance, taxation, internet, culture, outdoors. They are not only able to find information about a single city, but also compare different cities based on different features.
What is the something extra?
The primary “something extra” in our project is querying data from APIs rather than creating a dataset ourselves. The data our program uses comes from two APIs which users can query in real time.
Additionally, we bolstered our program by facilitating the ease of comparing two cities, to improve user experience. If a user wants to compare feature X across two different cities, rather than making the user query two different cities one after another, we have given the user the option to state that they would like to directly compare two cities (simultaneously), when starting the program. Once the user inputs the city names and the selected quality of life index, our program will explicitly state which of the two cities ranks higher.
On top of this, we have created a 2D visualizer to make the output results more concrete, whether the user is querying one city, or comparing two. This 2D visualizer also assists in improving user experience, by helping users better visualize the differences between the two cities.
What did we learn from doing this?
We confirmed that for our purposes, Prolog is very powerful in terms of querying a rather large dataset. For example, when checking if a user’s input city is valid (i.e. it exists in the database), it is very easy to use member/2 in order to get an answer. For the most part, we feel comfortable saying that logic programming is suitable for the task. Prolog also contains a built-in JSON library, making it easy to read data from large datasets.
That being said, it was at times difficult to use Prolog to manipulate the API calls’ responses. For instance, when starting this project, we had attempted to use a different API involving flight routes, but we ultimately chose to discard that option because there was more JSON manipulation needed than we believed Prolog could reasonably handle. Prolog was no match for traversing JSON compared to, for example, what we’ve been able to do with JavaScript in other projects.
Another drawback of Prolog was printing the output. We found Prolog to be unnecessarily complex when it came to printing special characters, or when we wanted to output our text with a certain format (e.g., we output the list of 250+ cities in a three column list). Also, when using special symbols in Prolog, there seems to be different outputs when using Windows and Mac OS, which can possibly be attributed to environmental differences in SWI-Prolog for Windows and Mac.
Bottom-line, we do believe that Prolog is suitable for this type of project. The main goal of our project was to make calls to the APIs, parse the JSON data, query said JSON, and output the results in a sufficiently user-friendly manner, which was all feasible with Prolog.