To ensure proper disposal of waste, the Swachh Bharat Mission has approved the building of deep row entrenchments for the disposal of sludge for up-to three years. With this mandate, there are approximately 10k+ deep row entrenchments that now exist, and are usually unmanned. To confirm disposal to these legal unmanned dumping sites, there is a need for automated verification of disposal at these sites.

India’s FSM ecosystem is made of highly interdependent parts, across the value chain of generation, containment, transport, treatment, and disposal/reuse. This means that there are different actors at each stage of the value chain whose behaviours and business models affect how well the next stage functions, creating a complex mesh of constraints that affect the effective functioning of the sanitation service delivery.

While the linear value chain gives a lucid frame to understand the ideal flow of faecal sludge, there are various points of friction between stakeholders that currently undermine the effectiveness of the sanitation value chain. Illegal dumping remains a challenge in regard to the waste value chain.

We want to improve the verifiability of the transport information on faecal sludge through the implementation of vehicle tracking to drive the following benefits:

1. Improved verification: The service enhances the verification process of the faecal sludge disposal. By accurately tracking the movement of vehicles carrying the sludge, it ensures that the sludge reaches its designated disposal site, providing transparency and accountability in the disposal process.

2. Removal of manual intervention to confirm disposal: The implementation of the vehicle tracking service removes the need for manual intervention to confirm the disposal of faecal sludge. Traditionally, manual methods involve physical confirmation by the treatment plant operator.

3. Identification of Illegal dumping: By closely monitoring the transportation of faecal sludge from the point of containment to disposal, the vehicle tracking service helps in minimising disposal in illegal sites. It facilitates identifying potential inefficiencies, route deviations, or incidents, allowing for prompt corrective actions.

The vehicle tracking service within DIGIT aims to capture real-time spatial data by tracking vehicles from their starting coordinates (longitude and latitude) to their destination point. This service helps in enhancing the credibility of service delivery by providing a reliable means to track and verify the transportation process. The vehicle tracking service can be seamlessly integrated with various service delivery operations, offering the flexibility to configure it for different purposes.

Here are the articles in this section:

Release Summary

This release includes a new feature called vehicle tracking, which has been developed as part of a community project. It aims to capture real-time spatial data by tracking vehicles from their starting coordinates (longitude and latitude) to their destination point. Additionally, it enables an urban local body (ULB) to designate illegal dumping spots, and monitor corresponding alerts

Functional Changes

• Vehicle Tracking

New Feature Additions

Known Issues

1. A user cannot delete the added Illegal dumping site.

2. A user cannot edit the added illegal dumping site.

3. A driver cannot cancel/reject the trip.

Related Documents and Links

Click here to view the details.

This section illustrates the steps for drivers at the urban local body (ULB) level.

Drivers can:

1. View the trips.

2. Start and end the trips.

View Trips

Log in to the application using the user Id and the password provided by the ULB along with selecting the city.

In case a user has forgotten the password, he/she can click the "Forgot Password?" hyperlink, which will display a message instructing users to get in touch with the ULB.

Driver’s home page and inbox

After successful login, the driver's inbox will show both assigned trips and completed ones.

Home: This option prominently displays the assigned trips, serving as the central hub for trip management.

Language: Drivers have the flexibility to select their preferred language for a more convenient experience.

Logout: This option allows the driver to safely exit the system.

Upon successful login, the driver can see all the trips assigned through the ULB.

• Trip search: This allows the driver to search the trip by name or phone number.

• In progress tab: This section presents trips that are pending initiation and assignment.

• Completed tab: Here, the driver can view a compiled list of completed trips.

Start and End Trips

Upon clicking the "View Details" hyperlink, the driver can see the applicant's information, including both the pickup location and the drop-off point.

The driver can click on “Start Trip” button. A pop-up will appear with a warning message “Start the trip only after reaching the pickup location. Have you reached the applicant location?”

When the driver clicks on 'Yes', a toast message will emerge, confirming the successful initiation of the trip: "Trip Started Successfully."

Upon successful completion of the desludging process in the FSTP, the driver can click on the "End Trip" button to conclude the request.

Upon selecting the "End Trip" button, the system shows a warning message: "Are you sure you want to end the trip for Locality 1...?. When the driver clicks on 'Yes', the trip reaches its completion status.

Overview

Urban Local Bodies (ULB) and other government agencies provide citizen centric services. Some of these services involve/require movement of people or assets(eg : vehicle, equipment etc). Below is a sample list of such services:

• Pickup of Fecal sludge from a citizen’s premises and offloading at a designated place

• Garbage pickup truck visits multiple collection points and deposits the load at a designated waste segregation yard

• ULB assigns a drinking water tanker to supply water to schools in a particular area. The water tanker visits the assigned schools and supplies the required amount of water.

• Fumigation to contain mosquitoes spread involves an operator moving in a 2-wheeler from one street to another.

• Medicines have to be moved from district headquarters to mandal level villages.

Key challenges in the above scenarios are :

1. Ensuring the vehicle / person took the designated route

2. Checking if all pickup/dropoff locations are visited

3. Monitoring if a restricted location is visited

4. Tracking of live location

Challenges listed above are solved with a new tracking service component. This document captures the technical design of such a tracking service. For functional use cases related to a specific citizen service (Fecal Sludge Management), please refer to .

Design guidelines

Tech design for Tracking service addresses following key design goals. These goals are derived from DIGIT’s view of how a service should evolve and also the constraints arising from the usage of client side application.

1. Client side devices may have network bandwidth constraints, hence the communication between client and Tracking service should be optimized on data.

2. Tracking service should be generic enough to handle any kind of citizen services that involve movement of assets or service delivery by an operator on move. Type of service being rendered decides the monitoring rules (alerts, notifications) that are applied to the trip.

3. Within the DIGIT platform, event based models processing should be used so that newer applications can be plugged in by consuming the event messages.

Tech design

Components

Below is the list of entities, actors and tech components involved in tracking service.

Entities

• Point of Interest (POI) - Latitude, longitude coordinates of various locations. Types of locations include citizen pickup point, intermediate points, destination location, polygons to identify larger areas and tags to identify anomalies (like illegal dump yards).

• Designated route - A sequence of POIs which indicate the route an operator should take.

• Trip - Created for each service delivery involving an operator. It is either created based on request or through an automatic scheduler. Trip is made up of operator details and designated routes. Actual route taken by the operator is also associated with the trip.

Actors

• Supervisor - Individual is responsible for making configuration level changes. These can be two separate roles or just one

• Operator - Travels from source to destination of a trip as part of service delivery.

• System - Tracking service has the intelligence to take some actions on its own.

Tech components

• Mobile App - User facing application to manage routes, trips and POIs

• Tracking service - Stores entities, applies automated rules and generates alerts.

Low level design

Tracking service

Controller classes

• ConfigController, PoiController, RouteController, TripController

Service classes

• ConfigService, POIService, RouteService, TripAlertService, TripService

Data access

• ConfigDao, PoiDao, RouteDao, TripAlertDao, TripDao, TripProgressDao

Service access

• POISao, TripSao

Model

• FsmApplication, FsmVehicleTrip, TripAlert

Trip monitoring module

Monitoring logic

Trip data store

Database schema

Rule management schema

3.4.6 Use case to API mapping (with FSM integration)

Vehicle tracking system (VTS) and FMS are the two systems that provide these APIs

Driver use cases (mobile app)

Appendix

Appendix A - REST APIs for client applications

Note -

(i) Additional attributes will be added to cater to integration with other entities within the DIGIT ecosystem. For example, Tenant Id, User Id, ULB id/name, auth token etc

(ii) All API requests will include timestamps and other information necessary for auditing.

a.1. /poi/_create (Implemented)

Request message

Response message

a.2. /poi/_update (Implemented)

Request

Response

a.3. /poi/_search

** Additional search filters will be added to restrict the results to ULB, user role and other related restrictions.

Request

Response

An array of below objects will be returned for the POIs matching with search criteria.

b.1. /designated_route/_create

Request

Response message

b.2. /designated_route/_update

Request

Response

b.3. /designated_route/_search

** Additional search filters will be added to restrict the results to ULB, user role and other related restrictions.

Request

Response

An array of below objects will be returned for the designated routes matching with search criteria.

c.1. /trip/_create (Implemented)

Request

Response

c.2. /trip/_update

Request

Response

c.3. /trip/_progress

Request

Response

c.4. /trip/_search

** Additional search filters will be added to restrict the results to ULB, user role and other related restrictions.

Request

Response

Array of trips is returned

c.5. /trip/_search/{tripId} (Implemented)

Request

Appendix B - Event data examples

Event type = LocationUpdate

Event data

{

“latitude” :

“longitude” :

“update_time” :

“trip_id” :

}

Event type = TripAnomaly

Event data

{

“anomaly_poi_id” :

“duration_at_poi” :

“update_time” :

“trip_id” :

}

Event type = TripComplete

Event data

{

“update_time” :

“completion_time” :

“trip_id” :

}

Appendix C - API to Database mapping

Mobile app

FSM portal

Here are the articles in this section

• Employee User Manual

• Driver User Manual

Tracking Service - link

Flutter App - link

Route Map - link

Pre Configurations

1.0 Enable PostGIS Extension

PostGIS is an extension to PostgreSQL for storing and managing spatial information. To learn more about PostGIS, see PostGIS.net

Tracking Service uses spacila data for tracking and storing geo coordinates and analysing the POI data. To make tracking service function properly, it requires support of the PostGIS extension on Postgres Database.

Overview

Urban Local Bodies (ULB) and other government agencies provide citizen centric services. Some of these services involve/require movement of people or assets(eg : vehicle, equipment etc). Below is a sample list of such services:

• Pickup of Fecal sludge from a citizen’s premises and offloading at a designated place

• Garbage pickup truck visits multiple collection points and deposits the load at a designated waste segregation yard

• ULB assigns a drinking water tanker to supply water to schools in a particular area. The water tanker visits the assigned schools and supplies the required amount of water.

• Fumigation to contain mosquitoes spread involves an operator moving in a 2-wheeler from one street to another.

• Medicines have to be moved from district headquarters to mandal level villages.

Key challenges in the above scenarios are :

1. Ensuring the vehicle / person took the designated route

2. Checking if all pickup/dropoff locations are visited

3. Monitoring if a restricted location is visited

4. Tracking of live location

Challenges listed above are solved with a new tracking service component. This document captures the technical design of such a tracking service. For functional use cases related to a specific citizen service (Fecal Sludge Management), please refer to this doc.

1.1 Design guidelines

Tech design for Tracking service addresses following key design goals. These goals are derived from DIGIT’s view of how a service should evolve and also the constraints arising from the usage of client side application.

1. Client side devices may have network bandwidth constraints, hence the communication between client and Tracking service should be optimized on data.

2. Tracking service should be generic enough to handle any kind of citizen services that involve movement of assets or service delivery by an operator on move. Type of service being rendered decides the monitoring rules (alerts, notifications) that are applied to the trip.

3. Within the DIGIT platform, event based models processing should be used so that newer applications can be plugged in by consuming the event messages.

Tech use cases

Key terms

Use cases

3. Tech design

3.1 Components

Below is the list of entities, actors and tech components involved in tracking service.

Entities

• Point of Interest (POI) - Latitude, longitude coordinates of various locations. Types of locations include citizen pickup point, intermediate points, destination location, polygons to identify larger areas and tags to identify anomalies (like illegal dump yards).

• Designated route - A sequence of POIs which indicate the route an operator should take.

• Trip - Created for each service delivery involving an operator. It is either created based on request or through an automatic scheduler. Trip is made up of operator details and designated routes. Actual route taken by the operator is also associated with the trip.

Actors

• Supervisor - Individual is responsible for making configuration level changes. These can be two separate roles or just one

• Operator - Travels from source to destination of a trip as part of service delivery.

• System - Tracking service has the intelligence to take some actions on its own.

Tech components

• Mobile App - User facing application to manage routes, trips and POIs

• Tracking service - Stores entities, applies automated rules and generates alerts.

API specs

Tracking service has APIs to manage the 3 core entities - Point of interest (POI), Designated route and Trip. Basic details of these APIs are mentioned below.

Following are the list of APIs this service will support. For details of the request and response message structure, please refer to Appendix A in this document.

• Point of interest

  • /poi/_create

  • /poi/_update

  • /poi/_search

• Designated route

  • /designated_route/_create

  • /designated_route/_update

  • /designated_route/_search

• Trip

  • /trip/_create

  • /trip/_update

  • /trip/_progress

  • /trip/_search

3.3 Event entity

Event entity has a generic format. Structure of the event is listed below.

Service design

• Tracking service [New]

  • A gateway service for client endpoints. POI, Designated routes and Trips are managed by this service

  • Location updates received from client are published as events in a standard format

• Trip monitoring module [New]

  • Consumes the location update events received from client (published by Tracking service)

  • Persists the location data, identifies anomalies, marks trips as complete based on rules

  • Events that should be notified are published by this service

• Notification module [New]

  • Consumes the notification events

  • Fetches contact information from DIGIT User Service and sends SMS in predefined format

• Tracking data store [New]

  • Data store for POIs, routes, trips, location updates and notifications

• DIGIT user service [Existing]

  • Provides contact information of the user to which notification will have to be sent

  • User can be a supervisor or operator

Background

To ensure proper disposal of waste, the Swachh Bharat Mission has approved the building of deep row entrenchments for the disposal of sludge for upto three years. With this mandate, there are approximately 10k+ deep row entrenchments that now exist, and are usually unmanned. To confirm disposal to these legal unmanned dumping sites, there is a need for automated verification of disposal at these sites.

Introduction

India’s FSM ecosystem is made of highly interdependent parts, across the value chain of generation, containment, transport, treatment, and disposal/reuse. This means that there are different actors at each stage of the value chain whose behaviours and business models affect how well the next stage functions, creating a complex mesh of constraints that affect the effective functioning of the sanitation service delivery.

While the linear value chain gives a lucid frame to understand the ideal flow of faecal sludge, there are various points of friction between stakeholders that currently undermine the effectiveness of the sanitation value chain. Illegal dumping remains a challenge in regard to the waste value chain.

We want to improve the verifiability of the transport information on faecal sludge through the implementation of vehicle tracking to drive the following benefits:

1. Improved verification: The service enhances the verification process of the faecal sludge disposal. By accurately tracking the movement of vehicles carrying the sludge, it ensures that the sludge reaches its designated disposal site, providing transparency and accountability in the disposal process.

2. Removal of manual intervention to confirm disposal: The implementation of the vehicle tracking service removes the need for manual intervention to confirm the disposal of faecal sludge. Traditionally, manual methods involve physical confirmation by the treatment plant operator.

3. Identification of Illegal dumping: By closely monitoring the transportation of faecal sludge from the point of containment to disposal, the vehicle tracking service helps in minimising disposal in illegal sites. It facilitates identifying potential inefficiencies, route deviations, or incidents, allowing for prompt corrective actions.

The vehicle tracking service within DIGIT aims to capture real-time spatial data by tracking vehicles from their starting coordinates (longitude and latitude) to their destination point. This service helps in enhancing the credibility of service delivery by providing a reliable means to track and verify the transportation process. The vehicle tracking service can be seamlessly integrated with various service delivery operations, offering the flexibility to configure it for different purposes.

Future Use Cases Apart from the benefits mentioned above, the vehicle tracking functionality can be used to implement the following use cases in the future:

1. Proximity-based discovery: By helping service providers or customers identify the nearest available vehicles for transportation or disposal purposes.

2. Distance-based pricing: Leveraging the tracking data, the vehicle tracking service can support distance-based pricing models.

3. Understanding capacity and capacity utilisation of vehicles: By analysing the metrics around transportation such as average trip time, average distance traveled, number of trips completed per day, idle time, etc., one can arrive at the utilised and available capacity for transportation. Further, these can be used to arrive at the profitability of vendors in transportation.

Features

1. Assigning drivers to the trips: The ULB personnel can assign a driver when assigning the vehicle for a particular trip.

2. Employee form has been enhanced to add geo-location.

3. A standalone mobile application for the drivers: Drivers will be able to see the trips assigned to them with start and end trips provided. With this functionality, the driver can start the trip after reaching the citizen’s location, provide service, and end the trip after reaching the FSTP.

4. Enhancement to the application by introducing end trip: The vehicle tracking service can be leveraged to automate certain aspects of the disposal process.

   1. System Verified: The trip is closed automatically if the vehicle is near the geo-fenced area of the FSTP. In this case, the end type is updated as system verified.

   2. FSTP Verified: If the driver concludes the trip at a location that is not necessarily close to the FSTP, the FSTP staff will need to manually finalise the trip. In this case, the end type is updated as FSTP verified.

5. Defining illegal dumping spots: The vehicle tracking service can help the ULB personnel to identify and input these locations into the system. If a driver stops at one of these spots for an extended period , the system triggers an alert to notify the ULB of potential illegal dumping activity.

6. Alerts: On events where local authorities should be informed:

- Longer waiting of vehicles near farm lands, water sources, etc., could be a possible indication of illegal disposal.

- The popular open disposal spots as generally defined as prohibited zones and any desludging vehicles around those areas are also an indication of open disposal.

How Vehicle Tracking Will Be Integrated With DIGIT FSM:

Actors

Current Actors

Proposed Actors

As per the understanding on the field, collection and transportation services are provided by the sanitation workers (usually a driver plus helper). Given that the driver is operating the vehicle, it makes sense for us to add an additional actor in the workflow:

Workflows:

Current workflow (Without vehicle tracking) :

Proposed workflow (With vehicle tracking) :

Actions by User Persona

Assign Driver

The driver will be assigned to a request.

See flow diagram here

Start and End Trip

Trips will be started and ended by the driver using a mobile app.

See flow diagram here View Trip Details ULBs can currently view the applications. This needs to be enhanced with the following:

• Trip details need to be viewable along with status and route of the trip.

• Alerts need to be viewable if there has been an illegal stoppage on the trip.

• The ULB can deep-dive and view the route taken and the number of stops by the vehicle.

See flow diagram here

Mark Illegal Dumping Zones

See flow diagram here

Edit Illegal Dumping Zones

See flow diagram here

Users and Value bundles

Assumptions and Validations:

1 . Driver Login

2. Driver Home & Inbox

3. View Applications: ULB

4. Add Illegal Dumping Sites : ULB

Noun Verb Mapping

Detailed Scope

Use Case 1: Enhancing Verifiability of Information & Identifying Illegal Dumping Spots

Features

1. Capturing the geo-locations with timestamps of the driver at configurable frequency thresholds.

2. Creating geo-boundaries at particular spots earmarked as illegal dumping spots.

3. Defining anomalies based on rules, and sending alerts to the ULB employee when an anomaly is detected.

Users

ULB employee: To track the locations and cross-verify the alerts received.

Driver: Responsible for pickup and completing disposal, and ensuring proper sludge disposal.

Detailed process diagram for anomaly detection

Description

Driver

After the driver is assigned, they proceed to the pickup location. Before providing any services, the driver must initiate the trip by selecting the 'Start' option. After the service is complete, and the disposal is done, the driver can choose to 'End' the trip. If the end trip is within the geo-fenced area of an FSTP, then the trip automatically gets closed. However, if the driver tries to end the trip outside the FSTP geo-fence area, the FSTPO has to confirm that the disposal is successful. Simultaneously, the DSO gets a notification that the respective trip has ended.

In cases where the actions are performed offline, the system records the timestamps of both the 'Start' and 'End' trips, and the transportation to ensure accurate tracking and documentation.

Tracking Transportation

By utilising the tracking feature, assigned vehicles can be monitored for respective applications. If a vehicle halts near any marked illegal dumping sites on the map or for a duration exceeding the configurable threshold, an alert is promptly sent to the DSO, ensuring timely awareness of potential unauthorised dumping activities.

• Notifications and alerts: The tracking system is configured to generate alerts within the application.

• A new "Trip Details" table is introduced which displays the number of alerts generated during the trip, the trips start and end times, the end type, and offers a link to view the route taken by the driver.

1. Upon initiating the trip, the driver's geo-locations are continuously recorded at a configurable threshold, enabling the DSO or a ULB employee to track each vehicle's movements. If the driver halts at spots apart from the disposal site for a duration exceeding a configurable threshold, the DSO receives an alert. The system records alerts in real-time when the driver is online, while geo-locations are updated once the driver reconnects, generating corresponding alerts for offline periods.

2. The ULB has a centralised inbox to effectively monitor and track the drivers' trips. The inbox shows the alerts raised per trip respective to the application.

3. The application details page needs to be enhanced for the following:

   1. Geo-location to be added on the employee form.

   2. Display driver details.

   3. View route details: This shows the ULB employee a map showing route taken by driver and points of stoppages along with time of stoppage.

      1. Display a map view showing the stops (exceeding a certain time) made during the trip.

      2. Vehicle route: Utilise the tracked geo-location coordinates to generate and display the vehicle's route on the map with respect to each trip.

4. Illegal dumping zones:

   1. ULB defined: ULB personnel/admin can define illegal dumping zones.

Clicking on illegal dumping sites on menu options will allow users to see the illegal dumping sites in the ULB. If no sites are present, then user will only see the option to “Add new site”.

1. Clicking on “Add new site” will allow users to create a new illegal dumping site as an anomaly object.

2. User will need to add following details to create an anomaly object:

   1. Site name - Name of the site (For example, Dhenkanal Lake).

   2. Location category - The type of geographical body (For example, Lake/Road/Highway/Bridge/Old building/Open field/Rainwater pipe, etc.).

   3. Buffer area (in metres) (Distance from these coordinates which can considered an anomaly).

   4. Map UI

      1. For Polygon - (For example, a pond):

         1. Upto 20 points are allowed on the screen.

         2. Each point will have a cross icon.

         3. If two points are already added. User has to remove one point to add a new point.

         4. If a buffer is added. Show a corresponding figure of ‘X’ metres buffer perpendicular to line in all directions, with highlighted colour (even before saving), so that the user is clearly aware of the boundaries he/she is making.

         5. Polygon should be a closed figure.

3. Once saved, the coordinates are saved in the anomaly object.

4. To edit or make changes to an illegal dumping site click on an anomaly object from the list of objects in the menu.

   1. In the next screen, click on actions. Actions will open edit and delete.

   2. Clicking on edit will make the menu editable (until then it will be non-editable).

   3. Users are allowed to edit all options. There is no restriction.

   4. Buttons will be shown as “Save Changes” and 'Cancel'.

   5. Clicking on save changes will save all the changes made to the anomaly object.

   6. Clicking on cancel will take the user to the previous screen.

5. Alerts on Illegal dumping:

   1. If any vehicle is found stopping in these locations, including buffer areas, for more than 'X' minutes, should send an alert immediately. Who to send:

      1. ULB employee - He/she will receive the alerts raised against the trip ID.

Acceptance Criteria

• Alerts should be generated for a ULB employee when vehicles are stationary near the marked illegal dumping spots for a configurable duration.

• The system should provide the ability for the DSO to add illegal dumping zones, allowing flexibility in response to changing circumstances.

Out of Scope

1. There is no other activity tracking of disposal vehicles other than the duration between the start and end trips.

2. No verification of which vehicle is being tracked. For example, if the mobile of the disposal truck driver is given to a two-wheeler driver, then the geo-location of the two-wheeler driver is recorded.

3. No verification of the disposal truck driver for example the registered driver and the actual disposal driver might be different.

Use Case 2: Automation of Disposal and Completion of Requests:

Features

1. Capturing the location of the vehicle at the disposal site.

2. Verification of whether the vehicle location is within the geo-fenced boundary of the disposal site.

3. Automated confirmation of the disposal based on positive verification.

Users

Admin portal: Geo-fencing data need to be added at the backend in the MDMS of disposal spots.

Driver: Responsible for completing disposal requests and ensuring proper sludge disposal.

Workflow

Description

1. The vehicle tracking service in FSM helps to automate the disposal process requests in legal dumping sites. By utilising geo-tagging and proximity data, the system can verify if the driver has disposed off waste at the designated disposal spot.

2. Admin functionality (no UI required):

   1. Allows administrators to view, add, delete, and modify the MDMS at the backend.

   2. Define the proximity radius for verification (for example, 50 meters) at the backend.

3. Driver:

   1. When a driver is completing a disposal request, the system captures their geo-tags (longitude and latitude) at the time of disposal. The system compares the driver's geo-tags with the predefined disposal spots set by the admin. There are two possibilities:

      1. If the driver's geo-tags are within the specified proximity radius (for example, 50 metres) of the disposal spot, the disposal is considered system verified, then the system automatically closes the disposal request, marking it as system verified.

Acceptance Criteria

1. The driver should be able to start the trip, and the system should capture and record the geo-location coordinates (longitude and latitude) at the start of the trip.

2. At a specific configurable frequency (for example, every 2 minutes; this is configurable), the driver's geo-location coordinates should be recorded and stored by the system.

3. The system compares driver geo-tags with the predefined disposal spots.

4. Upon reaching the plant, the driver should be able to end the disposal request from his/her mobile phone and the system should capture the geo-location coordinates at the time of closure.

5. Automated closure at the disposal location:

   1. If the driver's geo-location coordinates indicate that they are within the geo-fenced area of an FSTP, the disposal request should be automatically closed and marked as system verified.

   2. The closure should trigger an automated notification or confirmation to the driver and the admin.

Out of Scope

1. If the driver ends the trip outside a geo-fenced area, the driver uploads a picture and the FSTPO is required to verify the end of trip from their end.

2. Alert for non-closure at the legal disposal site:

   1. If the distance between the driver's coordinates at closure and the designated disposal location is greater than the defined threshold (for example, 50 meters), an alert should be generated.

3. There is no other activity tracking of disposal vehicles other than the duration between the start and the end trips.

4. If the driver goes offline during the trip, the driver application should continue recording the geo-location coordinates at the predefined frequency. The recorded coordinates should be stored locally on the device until an internet connection is available. Once the driver's device regains internet connectivity, the recorded geo-location coordinates should be synced with the server or the backend system.

Design

Find the mock-ups below:

Success Metrics

Future Roadmap

1. Users to be able to delete and edit the added illegal dumping.

2. Include the process of adding point locations for a polyline, creating a line through the user interface.

3. Incorporate additional alerts for prolonged stops at regular sites when sludge is collected for a duration exceeding 'X' minutes.

4. System generated illegal dumping spots: These are identified based on multiple drivers being stationary at the same location for a predetermined period. The DSO or ULB employee has the authority to designate or remove such zones, enhancing the system's ability to pinpoint areas prone to unauthorised waste disposal.

5. Bringing in the safety measures screen, and making it mandatory in the driver application.

6. Explore on advanced analytics for vehicle tracking, including metrics such as the number of trip requests, average distance covered, and the number of closed applications, with a focus on distinguishing between FSTP verified and system verified cases.

See the following video to understand how vehicle tracking works:

Build and Deployment of vehicle-tracker

Jenkins Job Builder Configuration:

Configure a Jenkins job builder to automate the build and deployment process.

Configuration File: build-config.yaml

DockerFile And Jenkins Configuration:

Create a docker file for your application

File: Dockerfile

File: Jenkinsfile

Nginx Configuration:

Configure the Nginx to serve the application

File: nginx.conf

Helm Chart Configuration:

Create a helm chart for deployment

Files in the helm chart directory:

Chart.yaml

values.yaml

templates/Deployment.yaml

templates/Service.yaml

templates/Ingress.yaml

templates/subfilter-injection-configmap.yaml

Add the custom js injection config in the environment directory

Push these changes to the DevOps repository in the desired environment.

Run Jenkins Job:

Trigger the Jenkins job manually or set it up to run automatically on every push to the repository.

Build and Deploy:

Jenkins will build the application using the Dockerfile, and then deploy it using the Helm chart to the desired environment.

For any more information check this repository:

Repo changes- https://github.com/egovernments/SANITATION/blob/HLM-5602-vehicle-tracking-web/frontend/vehicle-tracker/map_web_app/docker/Dockerfile

DevOps changes-

https://github.com/egovernments/DIGIT-DevOps/tree/unified-env/deploy-as-code/helm/charts/sanitation/vehicle-tracker

Technology Stack:

Frontend: flutter : version: 3.10.5

Backend: java, spring boot

This section illustrates the steps for employee roles at the urban local body (ULB) level.

A ULB employee can:

1. Assign vehicle and driver

2. View Trip Details and the Route Taken

3. View Alerts

4. Add Illegal Dumping Spots

Assign Vehicle and Driver

The ULB employee can assign the vehicle and driver in a single go by clicking on "Assign Vehicle".

View Trip Details and Route Taken

A new section called "Trip Details" is added within the application, displaying the number of trips scheduled for the respective application along with the ability to view the route taken by the driver by clicking on "View Route" hyperlink. This table also shows the number of alerts raised for the particular trip along with the start and end time of the trip.

The ULB employee can access trip details and review any raised alerts. Upon selecting the "View Route" option, the path taken by the driver is showcased for observation.

Routes can be chosen in alignment with specific trips. The system is equipped with pre-identified illegal dumping sites, and if the driver remains stationary near any of these sites for a duration surpassing a configurable threshold, an alert is automatically triggered, notifying the ULB employee.

The ULB employee can view these alerts and take appropriate actions based on the situation.

The ULB employee can also view alerts by clicking on the newly added card “Vehicle Tracking”.

Two cards: 'Alerts' and “Illegal Dumping Spots” are displayed.

The ULB employee can see the alerts in the form of inbox. This inbox features the alert type such as stoppage, verified closure, unverified closure, etc.

Add Illegal Dumping Site

The ULB employee can add illegal dumping spots by clicking on “Illegal Dumping Spots”.

Add Point Location

By clicking on the "Add Point Location" function, the ULB employee can add a new dumping site. They can then proceed to furnish all the essential particulars, including the Site Name, Site Type, and the distance threshold for triggering an alert when within proximity.

Once the site is added, a success message will be displayed. If one fails to add a site, a failure message will be displayed.