The following JS tweaks are required on the geo-search page:

• Markers are being refreshed each time as the map is moved. It should not refresh markers already added.
• InfoWindow objects are created for each marker. Should only be 1.

Steps:

1. Create a user that would have a DISPLAY var pointing to a xserver
2. Create a script that would run XSERV on system boot
3. Set a cron to run the download script as the newly created user

The code below is not optimised and can cause long delays and broad results.

 parkings = Parking.objects.filter(lat__gte=min_lat, lat__lte=max_lat, long__gte=min_long, long__lte=max_long).all()
    rtype = RateType.objects.filter(parkingID__in=parkings).all()
    rprice = RatePrice.objects.filter(rateID__in=rtype).all()

    # To cache whole querysets
    # FIXME: We need workaround where no extra work done
    bool(parkings)
    bool(rtype)
    bool(rprice)

    parkings = list(geosearch['parkings'])     # Here we have list of dicts
    rtype = geosearch['ratetype']
    rprice = geosearch['rateprice']

        for p_item in parkings:
            sub_ratetype = rtype.filter(parkingID=p_item.parkingID)
            for rt_item in sub_ratetype:
                rt_item.rateprice = list(rprice.filter(rateID=rt_item.rateID))
            p_item.ratetype = sub_ratetype

In general, we need to limit the maximum number of rows returned (e.g. to not return carparks for the entire world) by either:

a) Limiting the difference between min and max lat/long
b) Limiting max count of rows returned

Now that docker is integrated, we should use phantom.js to reduce the overhead of running a browser and rather use a 3rd party library to compile and parse HTML code

Background:
Generating hardcoded set of expected results is not a long-term solution. Instead, we should have a generic validation logic.

Requirements:
Refactor existing unit tests code to validate each field / attribute of the parking rates object generically based on the data type expected (e.g. string, integer, double) and/or mandatory vs optional value assigned to a field..

Background
The parking rates page is usually a free form and administrators are regularly place information that is not recognisable by a parser. In some cases it can be a short, seasonal notice (e.g. public holidays surcharge).

Requirements:
All notices that parses can not recognise must be stored as notes for each of the carparks.

Examples:

• Early bird parking only available if you book online via Secure a Spot (Secure Parking)
• Have ticket validated by Attendant in the morning (Wilson)

Background:
Need to build a website UI which users are going to use to run searches

Pre-requisites:

• Graphic designs
• Approved user workflows (i.e. user stories)

Requirements:

• User friendliness
• Intuitiveness
• UX should be straight - forward, so that a user can get information required in up to 3 clicks.

Use http://requirejs.org/ to improve the speed and quality of the code.

Background:
Machine learning approach may become useful if the platform grows big and need to support multiple different cities / countries. We need to practice it ASAP and compare ML driven rates retriever vs traditional OOP driven one (Wilson Parkings).

Requirements:

• Research into Machine Learning realm and find an algorithm that would suit our needs
• Document the approach
• Build POC by prototyping Secure Parking rates retriever

Background:
Some parkings are not working during public holidays, others only work for a few hours during the weekend.

Requirements:

• Need to parse working hours section of each of the carparks
• Store the information received in the DB
• Account for the working hours when running a user search

Background:
Current approach when a person needs to manually hardcode a URL for a carpark to process is very tedious and is not working well. We need to start from a higher level and first write a script to pull down list of all carparks available per carpark website (i.e. a single interpreter for wilson and a single for secure parking at first).

This would allow to have access to a much larger pool of data and enable to apply ML techniques.

Task:

• Create a script that downloads HTML with all carparks available
• Download & update details of each of the carparks and populate data such as opening hours, potentially geo data, etc.

Background:
To enable us to troubleshoot issues historically for a certain carpark, rates processing script need to report its' actions to a temporary audit logs for all carparks in the system.

Requirements:

• Log storage should be scalable
• Log entries should expire after 30 days, to maintain disk space usage
• Storage system must be robust, highly accessible and ideally open-source.

Potential candidates:

• Redis
• Splunk
• Kibana

This is an R&D task.