Add feature to filter types of refill spot

[lawriecate]

Depends on #9
Display filtering options so that users can narrow down selection

How to achieve with API:

• Use the /tags endpoint to list out all available tags
• Display interface to let users toggle tags on/off
• If any tags are toggled on, include their ID in the request to get refill spots /taps/search endpoint (tag_ids parameter), and this will mean results only include spots with those tags

[be-anna]

Please check notion link for more details:
https://mymizu.notion.site/Filtering-the-map-b30ce6adce1b4e4b83abee146d5047ca

[lawriecate]

[In the design there are some example tags next to the filter icons](https://www.figma.com/file/HfT3GwZlpR6q9RScMNdF5D/mymizu-Web-App?node-id=0%3A1) Then if you click the filter icon there is a modal with the full range of sorting/filtering options displayed

- Please do not implement the sort filter yet, or how to refill

• Type of refill spot refers to the category, which can be controlled using categories param
• The list of categories is

Refill Partner ID: 4
Public: 2, 3
Natural Spring: 1

• Then for other filters, please call tags endpoint which will respond like

[
    {
        "id": 1,
        "name": "Facilities",
        "tags": [
            {
                "id": 4,
                "name": "Wifi"
            },
            {
                "id": 5,
                "name": "Wheelchair-Accessible"
            }
        ]
    },
    {
        "id": 2,
        "name": "Water",
        "tags": [
            {
                "id": 1,
                "name": "Filtered"
            },
            {
                "id": 2,
                "name": "Hot"
            },
            {
                "id": 3,
                "name": "Cold/Chilled"
            },
            {
                "id": 6,
                "name": "Tap"
            }
        ]
    },
    {
        "id": 3,
        "name": "Business Type",
        "tags": [
            {
                "id": 7,
                "name": "Health/Beauty"
            },
            {
                "id": 8,
                "name": "Cafe/Restaurant etc"
            },
            {
                "id": 9,
                "name": "Hotel/Accommodation etc"
            },
            {
                "id": 10,
                "name": "Store/Shop"
            }
        ]
    }
]

• Each block is a group of tags, so please display e.g.
• "Water" then with filter options for Filtered, Hot, Cold etc
• Tags can be controlled via the tags parameter, which should be the comma separted list of tag IDs, e.g. to filter Hotels with Cold water tags=9,3

[be-anna]

Design: https://www.figma.com/file/HfT3GwZlpR6q9RScMNdF5D/mymizu-Web-App?node-id=728%3A12175

[sjfricke]

Hackathon 2023 Design Idea Dump:

The search should be done in the Database (Eloquent ORM)

• DB are efficient at searching
• The front end might not have all the known locations being shown

The search result is a logcial expression

From the above mock-up design

The boolean expression becomes

( ("cold" or "filtered") and ("help yourself") and ("wi-fi" or "Rest space") )

Using the id above this becomes

[[3, 1], [9], [4, 10]]

a query would need to look like

$users = DB::table('tags')->where([
    ['3','1'],   // cold
    ['1','1'],   // filtered
])->orWhere([
    ['9', '1'],  // help yourself
])->orWhere([
    ['4', '1'],  // wi-fi
    ['10', '1'], // Rest space
])->get();

The backend could generate this dynamically with something like the following

app.get("/tags/search2", async (req, res) => {
    const filters = req.filters; // [[3, 1], [9], [4, 10]]
    query = DB::table('tags');
    
    for (filter : filters) {
        search_query = [];
        for (f : filter) {
            search_query.append([f, "1"]);
        }
        if (filter == filters.start()) {
            query->where(search_query);
        } else {
            query->orWhere(search_query);
        }
    }
    res.send(query->get());
});

Problems with current API

The above proposal has 2 issues with the current /taps/search API

1. tags is "Comma seperated tag IDs", this doesn't allow a way to express the needed expression above
2. categories (type of location), could be another filter category. In theory, categories and tags both serve the same purpose, but the fact they are different fields is something to consider with a design

This means a potential new /tags/search2 API endpoint might be needed

How buttons are added to filter list

When the /tags API is called and gives a list of both id and names (adjusted for language), it can then generate the buttons.

{
    "id": 1,
    "name": "Facilities",
    "tags": [
        {
            "id": 4,
            "name": "Wifi"
        },
        {
            "id": 5,
            "name": "Wheelchair-Accessible"
        }
    ]
},

becomes a row of buttons where when clicked, the id is known dynamically

Finding if the place is open

The biggest issue of finding if a place is open is the fact time zones are different where you look.

If 2 locations in Japan and Austrilla are open at 10:00am, but it is 9:00am in Japan but 11:00am in Austrilla at some moment, then only the Austrilla location is open, regardless where the client is searching from (confirmed this is what Google Maps does as well)

This can be resolved into a boolean expression as

(day == current_day_of_week) and (current_time > opening_time) and (current_time < closing_time)