Technical Specification: Urban-Rural Convergence
Overview
Initiative to provide access to sanitation services to all gram panchayats (GPs) via urban local bodies (ULBs) located closest to them.
Objective
DIGIT Sanitation plans to provide a provision of sanitation services to rural areas to their nearby cities.
Author
Name
Role
Department
Aman Jha
Technical Lead
FSM
Document History
Date
Version
Document version and history
Document author
16-02-2023
1.0
Initial version
Kapil Gupta
17-02-2023
1.1
Updated the solution approach based on review
Aman Jha
Approvals
Date
Approver name
Remarks
15-02-2023
Ghanshyam
There is no need to use additional MDMS for Urban-Rural Convergence (URC). We can add the gram panchayat hierarchy in the existing MDMS boundary-data.json.
21-02-2023
Ghanshyam
We can go ahead with the approach in impel, but in product we can generalise this hierarchy. To do that, modification is required in location-service. We can also build the dynamic component in UI for showing a relative dropdown based on the hierarchy.
Use Case
As a ULB employee, he/she is creating applications to cater to the sanitation needs of local communities in urban areas. Similarly, he/she should also cater to the same sanitation needs of rural bodies which are close to the urban regions.
ULB employees need a provision in a system while creating a new application whereby they can either choose local municipalities or urban supported villages. Based on their choice, they will be able to select either locality/mohalla or gram panchayat (GP) areas from the respective master data dropdown list. The caveat here is if a ULB employee chooses a GP, then the trip amount field should be editable so that he/she can fill any logical amount based on the offline calculation instead of an auto-calculated amount that is already there in an application in case of urban bodies.
ULB employees or DSO operators should also be able to edit the number of trips. The final amount should be a multiple of the initial amount entered into an application with the number of trips.
Technical Components & Design
Need to update MDMS data: Boundary-data.json
- Need to add a new child hierarchy for GP under city which will be parallel to a locality. A sample is given at the end of this document.
System will use the below URL to fetch the localities or GPs and their corresponding villages.
- In the case of localities, pass boundaryType as “Locality”.
https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=Locality&tenantId=pb.amritsar
- In the case of GP/villages, pass the boundaryType as “GP”.
https://dev.digit.org/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=GP&tenantId=pb.amritsar
By default, the 'Urban' option will be pre-selected in the radio button in the above wireframe and the dropdown will have the locality/mohalla master data (existing behaviour). If an employee selects “ULB supported village”, then the locality/mohalla dropdown will be replaced by GPs and the village dropdown data on the fly.
- Also, the "Amount per Trip" field will be editable with no pre-defined calculated value. Hence, the below API will not get called for URC flow (when “ULB supported village” is selected”):
Need to add configuration (mdms: UrcConfig.json) for configuring URC feature (Enable/Disable) and facilitating the switch on/off feature for the URC. MDMS data will be as shown below:
The above MDMS have two configurations:
- URCEnable: This flag will be used to enable or disable the URC flow altogether. If this flag is false, then we will not have URC flow (no radio buttons will come) and the existing flow (urban) will happen as it is. If this flag is true, then the radio button will appear. By default, the 'Urban' option will be selected and if the user selects “ULB supported village", then the URC flow will continue as mentioned in above points.
Need to store GP and Village as part of additional details(in eg_fsm_address). Also add one more key as boundarytype in additional details to capture (Locality or GP/Village) to determine if the application created is for RURAL or not so that in the near future it will be helpful for the analytics and statistics in dashboards.
Default value for this key(boundaryType) will be Locality to support backward compatibility
Add Vehicle log would also have the option to select Urban (Default option) or Rural. If Rural gets selected the text name of an element would be replaced from “Locality” to “Gram Panchayat” for a text field.
Introduction of a boundarytype as additionalDetails in vehicle_trip table to capture if the vehicle log is created for GP or not.
Default value for this column will be Locality to support backward compatibility.
Sample MDMS (boundary-data.json)
Was this helpful?
