Scholarly HTML

Authors
Chile Liviu & Tiplea Alexandru

Begining

Hi, we are Liviu and Alex, and we are trying to do an website that would help the backpackers that would travel around the globe!

Introduction

This site comes from the needed to document the main website 'World-GO!' that would come to help the backpackers that travel the world. This site will come with solution for the traveler (like hospitals/ hostels/ hotels/ houses/ restaurants and so on) and would have places to 'what to visit' around the location of the traveler.

Also, we hope that our website will help more people, to go visit the Earth, because there are so many beautiful places to visit! But, let's hope that you will find our website interactive, because we put our love and lot of coffee.

Structure

The structure of our website will be prety basic. We will have a login/register page that would help the user to have all the information about him on that page.

Also, there will a page dedicat for the map, that would show the sorter route until the next destination of the traveler.

Another thing, will be the 'checklist' that would be found on the 'Places' tab. You can add the places that you want to visit, and your map would update once you put a new location there. Once you visit one location, you can cross that location from places.

The site and the pages

The site will be coded in HTML, CSS, JS with a databases in postgreSQL and with a responsive template. The site can be checked HERE

The mockup of the website

Bellow you can find few images/mockup of our website.

Front_page.jpg Front_page.jpg Front_page.jpg

API used for this app

We thought about using multiple api's for our application. Bellow you can find the name and the description of this api's.

  1. Amadeus Points of Interest
  2. Sygic Routing API
  3. Housing Anywhere API

Extending the Amadeus for Developers travel lifecycle

One of the questions we hear more often from developers and innovators building travel applications is: “okay, once my customers have landed in their destinations, what else can I offer to them?”. I still remember a cool use case that a team suggested in one of the first Hackathons we organized. They wanted to offer a full end-to-end travel experience to their customers based on destination insights, such as the best restaurants or beaches in an area. Unfortunately, back then, we did not offer that type of data as part of our catalog… But that has just changed.

We are excited to introduce a new API to our Self-Service catalog: Points of Interest API. This new API release is a result of our partnership with AVUXI. It provides information about the most popular places at any destination, such as restaurants, monuments, beaches, historical sites, nightlife spots or shopping facilities. The Points of Interest API relies on AVUXI’s GeoPopularity algorithm, which analyses and ranks geolocated data from more than 60 sources, including comments, photos, and reviews from millions of users

What’s new?

We have built two new endpoints following the same design guidelines followed by the rest of the existing APIs from the Self-Service catalog: Points of interest by radius and by square

Points of interest

Points of Interest by radius

The first endpoint supports only GET method and returns a list of points of interest for a given location - latitude and longitude - and a radius (1 km by default). The following sample returns a list of POIs for someone geolocated in Barcelona downtown: GET https://test.api.amadeus.com/v1/reference-data/locations/pois?latitude=41.397158&longitude=2.160873 In case we want to expand the area of search, we could use the radius parameter. In the following example, we increase the radius up to 3 kilometers: GET https://test.api.amadeus.com/v1/reference-data/locations/pois?latitude-41.397158&longitude=2.160873&radius=3

Points of Interest by a square

The second endpoint works in a similar way to the radius-based endpoint: It supports also GET operations but it defines the area of search with a box: north, west, south, and east. The following example returns a list of points of interest for an area around Barcelona: GET https://test.api.amadeus.com/v1/reference-data/locations/pois/by-square?north=41.397158&west=2.160873&south= 41.394582&east=2.177181 Response For both endpoints you can expect the same response format: a list of locations with the following JSON structure: { "type": "location", "subType": "POINT_OF_INTEREST", "geoCode": { "latitude": 41.39165, "longitude": 2.164772 }, "name": "Casa Batlló", "category": "SIGHTS", "tags": [ "sightseeing", "museum", "sights", "landmark" ] }

Your Travel route API

Sygic Routing API is a cloud-based service that calculates routes from one location to another. Sygic Maps comes with fast and reliable route planning algorithm based on everyday experience of more than 150 million drivers worldwide and with truck routing trusted by more than 750 000 truckers.

Easy to implement API suits all your vehicles and use cases – local delivery zones, emission zones, heavy truck attributes, hazardous material restrictions, and many more but always with focus on road safety. The simplest calculation can be done just by specifying both origin and destination defined by GPS coordinates and including a valid API key. Route calculation can be enhanced by using any of the parameters below:

  1. Waypoints with time windows;
  2. Avoid specific road types;
  3. Avoid specific block of map defined by map selection;
  4. Type of routing - request route alternatives (fastest, shortest, and the most economical);
  5. There are different routing parameters taken into account for each different vehicle type. Supported types are car routing, truck routing, van, and bus routing;
  6. Support for both imperial and metric units;
  7. Limit the max speed of the vehicle and set departure time to make ETA more accurate;
  8. Speed profiles represent usual traffic on roads at any given time of the day;
  9. Set right or left turn preference.

Routing calculations can be currently done on TomTom, HERE and OSM data. Sygic Routing API uses the same routing algorithm including truck routing as the well known Sygic Professional navigation used by 150 millions drivers worldwide. The only difference is that all computing is done on the cloud which makes the calculation much faster. Routing API will produce the same route as Sygic Professional Navigation app.

HousingAnywhere API

The HousingAnywhere API allows you to easily publish your listings on the largest rental accommodation platform globally. The API strongly advances data interoperability between HousingAnywhere and its partners. As property managers you can use the API to connect your inventory to the HousingAnywhere platform, enabling you to reach a far bigger target audience. Bookings take place on the HousingAnywhere platform and the API will ensure that partner systems are updated in real-time whenever one of your properties gets booked on the HousingAnywhere platform.

Publish Quality Listings

The HousingAnywhere API offers a range of possibilities. The API supplies a managed solution for storing and accessing property data such as media and listing details on HousingAnywhere.

Integrate with Property Management Systems

Connected property managers can store and access information regarding the pricing and availability of all their rental units. This information is updated based on a predetermined frequency as updates are pulled by the HA platform.

Bookings made easy

Webhooks enable two-way integrations to ensure that information is kept synchronized between HousingAnywhere and systems that are already being used by property managers. By using these webhooks, bookings and cancellations can automatically be confirmed as they happen, and availability calendars are updated on the fly.

Architecture

In this chapter we will speak a little bit about the infrastracture of this website ( main modules, UML diagrams, input/output data formats, data/task flows.). Starting with Main Modules.

Main Modules

From what we brain storm, we come up with 3 main modules (and after that, there may be some other auxiliar modules).

'To Do places'

The first modules it's the one of 'To do places'. A page where you can add a new travel, a new journey, with the exact objectives that you want to visit in that country. You will have a search module where you can search of the objective/city you want to visit, and you can add that objective. As submodules of this main modules, we can have here a script that will show the weather for that day a script that will recomend some places around that city, also the grad of pericol of that country/city and the numbers in case of urgencys.

Direction Map

As you travel a lot, you probabily will have no ideea how to get from point A in point B and then in point C and so one, until you will have only Mars to visit (hopefully will be reacheble). But for that, you will have to complete the 'to do places' (or separatly go on the direction map tab, and do it in the hard way) and have to press 'generate' of the map. - here, as a submodule we can create some turistic atraction near you and create a special direction map in order with what you want to use for transport (bike,walking,cars,public transportation).

A health journal

Didn't give a lot of thought on this one, but mostly it should by like a to do list that you will put different health parameters in order to see (like BPM/weight etc) and if something isn't right, to alarm you or maybe to recomend to visit a medic soon. Also, maybe this should be connected with a fitbit app or something similar throug an API.

UML Diagram

Next, we have the UML diagram (the main one):

UmlDiagram

Task an data flows

in the next images, we will have the task and the data flows of the applications.

Task flows:

UmlDiagram UmlDiagram.

Data flows:

UmlDiagram UmlDiagram

Input/Output diagram:

UmlDiagram

What did we use?

Ok, for this project, we use, as languages as it follows:

  • HTML
  • CSS
  • Javascript
  • And a lot of coffee ;)
  • For the part of the functionalities, and API's we use as it follows:

    For the part of weather and location, we use 2 api's from AccuWeather and the exact api's used are:

  • Autocomplete search -> from where we got the name of the location and the location id
  • 1 Day of Daily Forecasts -> return a short text of the weater for the current day
  • Unfortunately, most of the API's were with pay, and the AccuWeather has a 50request limit per day. So that can make some problems on the load of the page if there was to many request on a single day. The solution is simple, just create a new webapp from the profile in the accuweather, but that will take time.

    For the part of the map, we try to introduce a google map functionality, where the api's from google direction will calculate the distance and the route. Bad news were when we found out that the that API is with pas as you go, and we didn't want to use it so much.

    User Guide

    Our website it's straight to the point.
    What do I mean from that? Well our website has 4 big modules (Maps, ToDo Places, Check the weather and Health Data). For each of them we will present bellow the functionality and 'how to' (event if it's prety straight forward):

    The first module 'MAP':


    This module should get the location from 'ToDo' and create a personalized map with direction with the fastest route for you to get to your locations. Or to get to many tourist attraction from the city you wish to visit.
    Unfortunately, this functionality of the website is still under progress, and hope to be here soon...

    The second module 'ToDo Places'

    In this module, you are allowed to add in a to do list the dates and the places you want to visit. For example bellow snap:

    Here, we have a javascript that will get all the names from the world that will have the name as 'Ias'. As we dont have much request's/day, I put a condition when only 'Enter' is pressed, then to show the store data. Also, we didn't use any database (unfortunelly :( ). If we use a database, the fetch of the data would be much more easier. Same as the Maps, this module is prety easy, you have 2 text fields, and when press 'add date' or 'add location' will add the location to a 'to do list'. Like in the image bellow:
    .

    Also, within this module, you should check the weater to that location by pressing the 'see weather for this location' (not working yet. under development). Also, you can remove the items by pressing the 'x' from the right side.

    The third module 'Check the weather':

    This module is easy, just check the location as in the 'to do list' and it will create 'cards' in the root of the page. It's prety easy. Just write the location in the text field, and press 'see weather', and the product will be like in the next image:

    The last module 'Health data':

    right now is just a to do list in where you can add different data about your health data. It's not much, didn't put much efort in this module, but in the future, this module can be developed with api's from different fitness app (as fitbit, or garmin ). The website is stright forward a textbox and a add button where you will see the data. The image:

    the video can be seen below:

    Last but not the last - the demo/prototype

    And for the last section we left what is best, the demo of the prototype! We know is not much, but a lot of work was put in this much up, and god forbid if we still know how to process a nested JSON. Hope to understand at some point :) . But, for not much words anymore (i think we put a lot of words above), the live application can be found at cliviu.ro and the github link of the project can be found here: github.

    Hope we will pass the course and we really enjoy making this website!! Was interesting and difficult at the same time.
    Thank you! Liviu Chile & Alex Tiplea