This is the technical handbook for Wazimap NG

This is intended for

• Profile administrators - how to configure profiles

• Developers - how we work on this project.

Profile administrators should see the .

1. Do no change existing class names (unless strictly necessary to implement a request)

2. If a class name is change, ensure that change is discussed with a developer and documented in the Gitbook.

3. When making sweeping changes to an already existing component, be sure to duplicate the original component and mark the new component with a versioned name so that any changes do not break the production site. eg. ".map-options" -> ".map-options--v2".

4. Ensure that any change is documented in the Gitbook.

2022-10-03

Fix to map zoom positioned items

• Changed the position of the download button

• Changed the position of the geo select panel

• Changed the position of the map options panel

2022-10-02

Move custom stylesheet code from body to head tag

Removed hardcoded script in index.html

• On request from Emre, I have removed the second script in the screenshot above.

• UPDATE: Reuploaded a version with both the scripts in the screenshot removed.

Admin users are responsible for loading data and managing profiles. Be careful when giving someone admin access. Wazimap does not currently have an UNDO feature which means that any accidental deletion may require a database restore in order to recover.

Create a new admin account as follows:

1. Navigate to the user creation page: https://api.wazimap.com/admin/auth/user/add/

2. Select a username and secure password (important for the production site)

3. Press Save and continue editing (don't only press save)

4. Add details under Personal info (optional)

5. Under Permissions, select Staff status

6. Don't provide superuser access unless you know what you're doing.

7. Under groups, select Data Admin and Profile Admin

8. In the Available groups selector, also select all of the profiles that that administrator should have access to.

9. Push Save

On the server

• Install dokku

• Install the .

• Install the

• Install the

• Create a postgis database

• Create a redis database

• Create a dokku app

• Link the postgres and redis databases to the app

• Change the database url to use postgis instead of postgres

• Setup some environment variables

• Setup the domain and SSL certificates

• Setup the appropriate proxy ports:

Make sure that large uploads are allowed:

On your local machine

• Add a git remote for deployment git remote add dokku:wazimap

• Deploy git push dokku staging:master (if deploying the staging branch)

Configuration of the theme points can be set using the Configuration field of profile collections e.g.

Filterable Fields

For a point attribute to be filterable, it needs to be included in filterable_fields array of the configuration. In default none of the fields are filterable

The Django apps and database models are divided into roughly two groups: models that store data, and models that are used to present information to the end-user.

Datasets App

Dataset and DatasetData

Data models can be found in the datasets app. The central model is Dataset. It represents a dataset that was uploaded by the . Each dataset is associated with a . Data files uploaded to the system are expected to have the following structure:

Only the Geography, Count, and at least one additional column are required. An example table might look as follows:

When this file is uploaded, a new Dataset object is created. Each row is stored in a DatasetData object. A typical DatasetData object might look as follows:

All groups and the Count column are stored in a JSONField.

Indicators and IndicatorData

Another key concept is an Indicator. Indicators represent saved aggregations and filters on a dataset. For example, the above Dataset can be used to create an Indicator containing population per geography disaggregated by gender. The equivalent query in SQL would look something like this:

Similarly, another indicator can be created to return population disaggregated by age.

When a new indicator is created, data from DatasetData is processed to create an IndicatorData object, one per geography. A simplified version of and IndicatorData would like something like this:

The actual structure of IndicatorData objects is a little more complicated. More detail can be found here: .

Universe

Universes represent saved filters on queries and enable the Data Administrator to run a query on a subset of the database. The default Universe is the total of all the distinct observations in a geography (e.g. the total population of the geography). It is possible to create a custom Universe and apply it to an Indicator.

A Universe which creates a filter on gender can enable queries on Female exclusively. PseudoSQL to represent this operation

The Universe filters field contains a dictionary that will be used in a Django ORM filter method. Below is an example filter to extract adults 60 and older.

This filter is then passed to the Django ORM as follows:

Other noteworthy models are Geography and GeographyHierarchy. These are discussed in more detail here: .

Profile App

Whereas models in the Datasets app focus on data, Profile App models are for presentation to end-users. The key model is Profile. A profile is a view of the data curated by the . Each profile can be considered to be a complete Wazimap instance. A profile organises tabular data in Categories (IndicatorCategory) and Subcategories (IndicatorSubcategory). This data can be presented using three different models:

ProfileIndicator, ProfileKeyMetrics, and ProfileHighlight. ProfileIndicator is the most commonly used of the three.

ProfileIndicators present Indicators. They provide explanatory text, a custom label, and other attributes that control presentation. They are used in the Rich Data Panel in the form of graphs and the Data Mapper Panel in the form of .

ProfileKeyMetrics display only a single value from an Indicator. For instance, the number of youth between 15-24 living in the area.

ProfileHighlights are similar to ProfileKeyMetrics in that they display a single value from an Indicator, but are displayed in the Map View rather than the Rich Data View.

Points App

The central unit of analysis in NG is a geography. These represent spatial boundaries which can be associated with data that describes it. For example, a typical geography may represent a Province. Associated data may include demographics in the area, the crime rate, economic activity, education, or any other arbitrary data.

Geographies are related to each other in a tree-like structure (strictly a directed acyclic graph) where each geography in a level is either a root node or has exactly one parent.

The most common hierarchy that we use for the South African context starts with Country at the top. This is followed by Provinces, all of which are non-overlapping and completely contained with Country. Below Province we find District, Municipality, Mainplace and Subplace. Another path may be Municipality -> Ward.

The assumption about the geographical hierarchy is as follows:

1. It is a directed acyclic graph (DAG)

2. Child geographies are completely contained by their parent.

3. Sibling geographies do not overlap.

Forks can occur at any part of the hierarchy and are dependent on the current geographical hierarchy in use. For the purpose of illustration, here is a more extensive hierarchy:

Each Geography in a hierarchy should have the follow four fields:

Code - An identifier (not necessarily unique). Where possible, this code should follow an existing standard such as the for countries.

Boundaries - A spatial boundary definition.

Parent Geography - A reference to its parent, or null if it is a root geography. This reference should use the parent’s code.

Version - For a number of reasons, boundaries may change while codes remain the same. For instance, municipal boundaries in South Africa change every 5 years based on population growth and migration patterns. In some cases, old municipalities may disappear and new ones are created. In other cases minor boundary changes are made to existing geographies. In these cases, it is important to record an identifier that reflects this ‘version’ change, even when the code remains the same.

The approach in NG is to define a geographical hierarchy which then associates the various levels. When a request is received for a particular geography, it sends a list of its children to enable drilling downwards into the hierarchy.

Hierarchical Structure

Not linear

Hierarchies are not linear but are usually considered to be tree-like although strictly directed acyclic graphs. This means that one parent can have many types of levels - e.g. Municipality may have Wards and Mainplaces. These levels overlap. Less common is for a child to have multiple parent levels, e.g. A Ward can be a child of either Metro or a Municipality.

No universal levels

There is no assumption that every parent level will have the same child levels. For example, when exploring a world geography, each country may have different levels specific to it.

No wall-to-wall coverage

Boundaries do not need to cover the entire area of their parent, holes are possible.

Multiple simultaneously display levels

Many levels are not compatible with each other as they overlap, Wards and Mainplaces are one such example. There are however instances where they do not overlap such as Districts and Metros. In each case, it is up to the client to decide how these should be rendered.

Technical Details

Backend

is used to manage the model. Then enables fast querying of hierarchies which is usually hard to do in naive SQL table structures. Spatial data is stored in objects. Geographies are to GeoJSON before being served to the client.

Compression

Overly detailed geographies can result in large downloads. The GeographyBoundary models uses a to automatically compress boundaries everytime the model is . Downloads are still often large and can be reduced further by converting to TopoJSON. A custom serializer needs to be written to do this. Leaflet will also need a plugin to be able to convert TopoJSON to GeoJSON.

Frontend

Geographies are displayed on a Leaflet map drawn using Canvas. The client receives a preferred_children configuration key which provides guidance for which level to display when there are multiple options. For example:

every key represents a level, following by an ordered list of children that it can display. A municipality has two types of children mainplace and ward. According to this configuration, mainplaces should be preferred to wards and will be displayed as default. A toggle exists on the user interface to switch between geographies. If data for a particular level is not available then that should not be shown to the user.

See also

Below is an example of an Indicator Data object

Frontend code merge

1. Developer creates a draft PR

2. Developer completes code and removes the draft label from the PR.

3. The Trello ticket is moved from In progress to Code Review.

4. The lead dev merges the latest staging into the PR and reviews. Once the code is ready, the PR is updated with the merged code.

5. The Trello ticket is then moved into Review (Product Owner)

6. The Product Owner reviews the Netlify deploy preview. Once the implementation is approved, the Trello ticket moves to To be deployed

7. The Lead Developer merges the PR into staging

8. The Product Owner reviews the staging server (on a scheduled, or ad hoc basis)

9. Once approved, staging is merged into master which is then pushed to the production server.

This process allows to PO to review a feature before it is merged into the staging branch thereby removing the need to rollback a PR that isn't approved by the PO. One gap in this process if a bug enters the codebase during merging into staging. This can occur in the following cases:

1. PR 1 is approved, PR 2 is approved, PR 1 is merged in staging, PR 2 is merged into staging. The PO has not had the opportunity to review PR 1 and PR 2 at the same time.

2. Resolution of conflicts.

This page is a stub

The Wazimap-NG frontend uses a custom component architecture. Over time, this will likely evolve to use a more standard framework such as web components.

Observable Abstract Class

All components extend the Component abstract class which itself extends the Observable abstract class. Observableimplements the . Extending it gives a class the ability to register listeners and trigger events [Note, we may move to use native CustomEvents if we adopt the web component architecture]. Events are arbitrary string identifiers although they are often namespaced to the component itself.

For instance, when a dropdown element is selected, a dropdown component might fire the dropdown.selected event.

Here's an example:

The payload is any arbitrary object and datatype that the class seeks to send to any listeners on that event.

Calling code might look something like this:

whenever the onElementSelected method is called, every listener will receive the payload.

Component Abstract Class

Component extends Observable and adds a parent-child relationship enabling components built from other components.

Instead of our Dropdown extending Observable, it now extends Component.

The calling code would look like this:

Doing this simply stores the parent and child components. In future this may be used to bubble events or in someway communicate across the entire component hierarchy. [Note, the Component class is still being developed].

Building Components

Apart from extending Component Wazimap-NG components use a design. The view comprises an HTML fragment, usually created by the web designer. [These are currently embeded in index.html but may in future be separated into individual component html files.]

The model stores the state and associated logic of the component and the controller acts as the glue between model and view, as well as handling events and interactions.

Controller

Here is a basic implementation of the DropDown component.

A few points worth noting:

All components receive their parent component as the first argument. In many cases the second argument is the DOM element that contains the view HTML.

By convention, the constructor calls prepareDomElements which prepares various DOM elements used in the component. Note how each of the lines in prepareDomElements ends in [0]. This is due to the fact that JQuery's find method returns a JQuery object. By convention, DOM objects are used in models, these can easily be converted into JQuery objects using the $ function, e.g. $(this._textArea).

A prepareEvents method is often also used to wire up events from the constructor.

It's is important to note that only the web designer edits the HTML directly. If addition DOM elements are needed, the component will clone existing elements:

Model

While it is tempting to create the Component using a single class, separating the model from the view often results in cleaner, more robust, and easier-to-test code. The model only stores the state of the component and does not interact with either the view or the controller directly.

It is important that the model is agnostic of the controller. In other words, the model should not hold a reference to the controller and should not call its methods. Communication takes place using either events or callbacks. While not mandatory, events are preferred as callbacks can result in slightly less-readable code.

In the case of a DropDown component, the state that needs to be stored includes:

• Current options available in the dropdown

• The currently selected item

• Default text to display if no item is selected.

most of the model class looks like boilerplate, the most interesting method is the setter for currentIndex

Here we check if the index of the selected item has changed, if so, it is update and a DropDownModel.EVENTS.changeValue is fired. Recall from the DropDownComponent class above, we add a listener to this event:

which then gets the appropriate value from the model:

The current index value on the model is updated when the li element is clicked:

MVC Architecture

The benefit of using a decoupled MVC framework is that the resulting code is uncomplicated and reusable. Using this structure, it would be possible to have two controllers working with a single model. When a user interacts with the first component, the second one will automatically update.

To ensure that the Model is decoupled from the Controller, it is usually best to separate events into two types, user interaction events and state change events. A user clicking on a box is an example of a user interaction event. They are typically primitive events. The controller notifies the model of the event by calling a method on the model object. This method will likely modify the internal state of the model. Once the state changes, a state change event is fired from the model. An example is the changeValue event. These events usually operate at a higher semantic level. The controller receives the state change event and updates the view accordingly. In this case, the text shown.

A few points on style

Prefer using the _ prefix as a signifier of a private attribute, e.g.

Use getters and setters

Where possible provide the simplest possible arguments to methods, e.g.

Methods should receive only information that they need. Large application-wide state objects should be avoided.

Wazimap-NG is multi-tenanted. A single backend can host multiple profiles, e.g. https://beta.youthexplorer.org.za and http://sifar.openup.org.za both use the same server and database.

In order to determine which profile to use, the client sends a wm-hostnameheader with this api call: /api/v1/profile_by_url/?format=jsonthis is received by the server which then matches the hostname with available profiles. You can determine which profiles are currently served by a particular backend using the following url: /api/v1/profiles/. It will return a list of profiles with their configurations, e.g.

{
    ...
    "results": [
        {
            "id": 2,
            "name": "Vulekamali",
            ...
            "configuration": {
                "urls": [
                    "geo.vulekamali.gov.za"
                ],
                ...
            }
        },
        {
            "id": 3,
            "name": "Cape Town Against Covid-19",
            ...
            "configuration": {
                "urls": [
                    "capetownagainstcovid19.openup.org.za"
                ],
                ...
            }
        },
        ...
}

In this case, when the server receives wm-hostname set to geo.vulekamali.gov.za, it returns profile 2. A single profile may match multiple urls.

Your code will be reviewed. And you can can take steps to make it easier for the reviewer and yourself.

What is the job of the Review?

The review is there to improve the code quality and to ensure architectural direction and correctness.

The big benefit of a review is to help you get better. You will learn from Code Reviews.

1. Obtain the latest Webflow export from

2. Run path-to-webflow-export.zip

We work in an agile environment. We use scrum.

There is a task board per sprint.

Look for the highest priority available task in the current sprint.

If you can't find any available tasks in the current sprint

1. ask the rest of the team if you can help with anything,

2. let the PO and PM know that you can't find anything to work on

3. groom the backlog of upcoming sprints

4. Start working on tasks in the upcoming sprint

The priority of what to work on is as follows:

1. Deploy something that is Ready to Deploy unless we're waiting for a particular deploy time (unless it will take more than a few minutes to deploy)

2. data mis-representation bugs and bugs seriously affecting production (these should be moved to the top of the sprint)

3. The story highest up in the sprint that is not finished

As a Developer

Developers should only work on one task at a time.

Once you decide to start working on a task, this is your process:

• Assign the task to yourself

• Post in the Slack channel on which issue you‘re starting to work on

• Create a Draft PR (use the --allow-empty git command to create an empty commit and push the branch to the repository).

Once you‘re done working on the issue follow this process

• Run all tests locally

  • Check off the item ran tests locally & are passing in the checklist

• Run the build (FE npm run build & BE docker-compose up

Common broken assumptions

These are things we've seen cause bugs when we didn't consider them. We should try and have them in mind when implementing and writing tests for anything on this project.

• Data can exist for some geographies in a set of siblings but not all

• An admin can configure a default filter value which doesn't exist in the data for a given geography

2022-11-22 - Powered by Wazimap

• Added "Powered by Wazimap" watermarks to map, point mapper, data mapper and rich data.

2023/06/26 - Removal of tutorial button in nav

Description

Related Issue

How to test it locally

Screenshots

Changelog

Added

Updated

Removed

Checklist

• 🚀 is the code ready to be merged and go live?

• 🛠 does it work (build) locally

Pull Request

• 📰 good title

• 📝good description

• 🔖 issue linked

Commits

• commits are clean

• commit messages are clean

Code Quality

• 🚧 no commented out code

• 🖨 no unnecessary logging

• 🎱 no magic numbers

Testing

• ✅ added (appropriate) unit tests

• 💢 edge cases in tests were considered

• ✅ ran tests locally & are passing

General

Rationale for recent structure update: The latest version of wazimap has been reworked to ensure we can include the following features:

1. In-page anchor linking and page navigation

2. A component based approach to populating pages

3. An improved mobile experience

4. Filtering of sub-indicator

Styles section

The functional styles div resides on the main mapping page (hidden using .hidden). A copy of it can be found here (). This copy needs to be updated as elements are added to the main section or visa versa. Elements can be called as needed into different areas. This approach was aimed at improving loading times and initial states that would have incorrect information.

Rich Data Panel

Every other element is arranged in relation to this panel (using position fixed). This is so that we can maintain in page anchor linking and page navigation.

1. Rich data nav items

These items sit on the left hand side of the rich data panel and act as anchors to jump to different content. They also allow users to know which section they are currently in.

How to implement this component:

Call .rich-data-nav__item into .rich-data-nav__list

Once you're strong enough, save the world:

10/11/2021 - Filter truncation

Changes:

• Added truncation to long filters

• Removed generic-modal

10/06/2021 - Cluster scroll fix

Changed:

Added a element .facility-tooltip__scroll inside .facility-tooltip is--cluster which has overflow: auto to accommodate a long scrolling list.

10/06/2021 - Point mapper truncation fix

Ensured that point mapper labels are correctly truncated.

10/01/2021 - Map data version support

Generic Modal:

09/23/2021 - Facilities loading state

Fixed:

• Fixed a small bug where the facilities facet number was being pushed too far left if there was not a download button visible. Now, if the download button is hidden, the facet will align correctly with the right side of the panel. This fix was imlemented by changing the display of the parent from display: grid to display: flex

Changed:

• Added loading state (hidden) for the location facilities title (.location__facilities_title--loading)

• Added loading state (hidden) for hide/show facilities button (.location-facilities__trigger--loading)

• Added loading state (hidden) for location facility block items (.location-facility__item--loading)

09/16/2021 - Point mapper dropdown icon colour fix

Changed:

• Fixed what colour is automatically inherited for the point mapper dropdown headers so that it is not overridden with grey when using a theme colour.

09/16/2021 - Cluster tooltip

Added:

• .facility-tooltip is--cluster to the styles panel for use when clustering nearby points on the map.

09/15/2021 - Point mapper dropdown and filters

Point mapper dropdown with toggle:

Point filters:

Changes:

• Added .point-mapper__h1_checkbox that is hidden by default

• Added .point-filters panel in .map-bottom-items (hidden by default)

08/31/2021 - Fix for tutorial modal height

Changes:

• Restricted max height to 90vh on the tutorial modal

08/25/2021 - Rich Data Nav Fix

Changed:

• Made the section nav scroll when height is restricted

08/12/2021 - Print CSS test

Changed:

• add the following code to the print css:

07/19/2021- Point-legend, table margin, z-depth bottom-items

Changed:

• Added margin-bottom to .profile-indicator__table_inner to fix spacing issues in the rich-data panel

• z-depth: 999 added to items within the .map-bottoms-items panel

• Added .point-legend__remove

07/13/2021- Fixed rich data filter buttons to resemble map-options

Changed:

• Reverted to old implementation of .map-options__filters

• Changed .profile-indicator__new-filter to be a wide button to replicate the map-options button

07/12/2021- Remove map options tooltip and change filter buttons

Changed:

• Removed the indicator context tooltip from the bottom right of the map-options panel

• Changed the way we implement filter buttons in the map-options panel to bring it in line with the rich-data panel

• Added .mapping-options__filter-buttons with the following buttons:

07/05/2021- Disabled state for map download button

• Added .disabled state to .map-download button by default.

• Remove this class to set state to enabled.

07/05/2021- Removed filter disabled

• Removed the .disabled class from .dropdown-menu__trigger

• The disabled class is now only on .mapping-options__filter

07/02/2021 - Map options filters

Changed:

• Added .map-options__filters_content back into .map-options__filters in the .map-options panel.

• .map-options__filters_content is hidden by default using the .hidden class

06/28/2021 - Table content truncation

Changed:

• Added code to force truncation on the table cells

06/28/2021 - Location tag width

Changed:

• Set text within .map-tooltip__geography-chip to breaking: no-wrap;

06/22/2021 - SVG console error fix

Changed:

• Adjusted the svg height value for .location-facility__icon to 24px to avoid console errors.

• Removed wazimap-ng.css script call

06/21/2021 - .is--disabled to .disabled

Changed:

• renamed the disabled class on the rich-text dropdowns to .disabled from .is--disabled

06/11/2021 - Map options truncation fix

Fixed:

Fixed the short truncation on map options title. It now extends the full width of the panel.

Changed:

Removed capitalization on the map options title.

05/25/2021 - Changes to map options filters

Changed:

• The backend will need to clone the .map-options__filters_content in the styles panel for the map-options panel as needed. The hope is that this will prevent the dropdowns from breaking.

05/21/2021 - Additive filtering

Added:

These two implementation of this feature work in a similar ways

• .profile-indicator__filter-labels now contains the column labels for each filter column

• Each filter row is now within .profile-indicator__filter-row and .mapping-options__filter-row

Changed:

• Added border-bottom: 1px; and padding-bottom: 12px; to .profile-indicator__header

04/29/2021 - Data attributes and classes for Point Mapper and locations

Changed:

• Added class="i18n" to all instances of "Point Mapper" and "locations"

  • Point mapper panel and toggle tooltips

  • Locations section in the rich data view (includes the Locations count and the buttons)

Fixed:

• Changed the wording of "Download all facilities" to "Download all locations" in the rich data view.

04/22/2021 - Download all facilities

Changes:

• Added .location__facilities_download.location__facilities_download-all--header button to .location__facilities_header. This button is only visible on desktop. On mobile it hides and the button moves down to below the location cards. This is because downloading takes less priority on mobile devices.

• Added .location__facilities_download.location__facilities_download-all--footer. This button shows on smaller screen sizes.

04/22/2021 - Chart menu data attributes

Changes:

• Added data attributes to the buttons in the chart dropdown menu

• The following "data-id" attributes have been added:

  • data-id="Percentage"

04/09/2021 - Rich data tables

Changes:

• Added .profile-indicator__table to the .styles section

Documentation:

• .profile-indicator__table_row.profile-indicator__table_row--header is the header row for the table and styles the row accordingly.

• At the moment, only 3 column tables are supported

• .profile-indicator__table_row's contain

03/09/2021 - Print and google maps button for location

Added:

• Added print button to .facility-info

  • .facility-info__print is now a child of .facility-info__header

03/01/2021 - Explicit print button in rich data

Changed

• Added .rich-data__print to the rich data panel

03/01/2021 - Rich data location buttons

Changed

• Info text changed from "This location has 0000 locations in 0000 categories." to "This area has 0000 locations in 0000 categories."

• Button colour changed to green

• Button wording changed from "facilities" to "locations"

02/18/2021 - Map legend always showing

Changed

1. Map legend always showing:

• Made .map-options and .map-point-legend children of .map-bottom-items (new div)

• .map-options and .map-point-legend have a .hidden applied by default while waiting for the user to add a point layer or choropleth to the map.

2. Version of the point-legend without a remove button for print

02/18/2021 - Map legend

Changed

1. Map print legend:

• Added .map-print to the .map div

• Added .map-print__point-legend to .map-print

2. Point legend:

• .point-legend contains .point-legend__color and .point-legend__text

  • .point-legend__text has a default state of loading...

3. Choropleth legend:

• This item has been added to map-print to accommodate functionality that was being hacked together previously.

• The functionality for this item is the same as the default choropleth legend.

• Please contact Matthew if you have any questions about the intention of this component.

02/17/2021 - Added data attributes to hover menu items

Changed

Added data attributes to hover menu components:

• Added data-element="chart-value-select" to the hover menu chart value type selector

• Added data-element="chart-download-data" to hover menu download data options

Fixed

• Removed .webflow from .hover-menu__content that was not removed before previous export

• This class is used to show items when working on them in webflow. This will mean that the hover menu will start off open. With this fix it should return to a default of closed.

02/16/2021 - Hiding and styling content in chart hover menus

Changed

1. Hover menu groups for chart-value and download-data

• Added a div for .hover-menu__chart-value and .hover-menu__download-data

• Add .hidden to remove this group from the menu

2. Changed css for active state on hover menu list items

• Changed the way the .last class is applied to .hover-menu__content_list-item to make the active class behave as intended.

  • Old method was a single class .hover-menu__content_list-item--last

02/12/2021 - Tab notice and map title

Changed

Map title:

• Changed default state for .map-title to display: block

• Added .hidden class to .block-title to hide by default.

Tab notice:

• Added .tab-notice as a child of .main

• Added .hidden class to .tab-notice to hide by default.

2023/03/17 - Unnecessary code removal

2023/03/16 - Location tag scroll bar fix

• Adjusted the alignment of the "map-location__tags" to fix the scrolling issue on mobile

• Adjusted the width of "location-highlight" to not be a fixed width and cause wrapping issues

2023/03/15 - Various mobile changes

• Made map location chips panel overflow with items aligned right so that the current filter shows first

• Made the .map-bottom-items and map-bottoms-items have a the correct width and padding to make sure its contents does not overlap with other items on small screens. The only thing i couldnt test was whether the zoom buttons are working fine after this change. This seemed like a better way of handling the “map-options” change suggested as this would ensure no items in that parent div overlap rather than just 1.

• Positioning of the left side panel toggles is fixed on may side, they are lower and dont hit the map location chips

Explanations

Good Title:

Use the Issue Number and the issue title for the title of your PR.

Description

Add a good description here. Use the issue description to inform your own understanding of this issue. See

Related Issue

Create a link to the related Trello Card here. So that it can be easily referenced.

How to test it locally

Explain how you tested the changes locally and made sure that the PR does what you intend to. For example if you working on Frontend Code describe which page you should open and what steps to take to see the changes you made. For the backend, which endpoint to hit with which params, best to provide an example like a curl command.

Screenshots

If on FE, upload the desired outcome (design) and create a Screenshot, once you complete your work. Even better create a gif which shows how it works.

Changelog

Create a detailed changelog, if possible. This changelog can be informed by the commits you create (reference the commit part in the git handbook). They should contain parts that you changed. This can be a bullet list, no need to create full sentences. Should be functions, classes, API Endpoints, etc.

Added What has been added.

Updated What has been updated.

Removed What has been removed.

Checklists

This part should be checked off accordingly, when you're ready.

Social sharing

Added social sharing content to the export including:

• Social sharing image

• Favicon

• Social sharing description

• Renamed the site title (Wazimap NG)