fhircore
fhircore copied to clipboard
opensrp
Decouple Locations display on the Geo-Widget module from the Households.
Describe the feature request.
- The current Geo-Widget module supports the display of locations linked to households on a map.
- While this is one of the use cases of the Geo-Widget module we would like to add the ability to show all locations with valid coordinates and GeoJSONs on the map.
- This display should not require the availability of the household or any other resource for the location to be shown on the map
Acceptance criteria
- [x] Valid locations should be able to be shown on a map using the Geo-Widget module whether they are tied to a household or not.
Implementation plan (For Engineers) @FikriMilano and @aurangzaibumer will update it.
Related to https://github.com/opensrp/fhircore/issues/2936
Will you be able to interact with the points on the map? If so, how do you lookup (or know) what those Locations are linked to, or what links to those Locations?
@pld yeah, we can interact w those locations, let's say onClick or even onLongPress.
Each will require an API so we can provide a callback from quest module, then invoke that inside the point's onClick listener e.g. opening a Family/Patient profile.
The Geo-Widget module also requires a model that's going to represent a Location, and has the data we need when we use that model in the callback.
Let me know if that makes sense.
I envision the new module be purely a Geo-Widget feature, that works fine even for a completely different project than ours.
I'll make an engineering decision based on that, so let me know if we're aligned about it. @pld @dubdabasoduba
On interacting with the locations, can you refer to the geowidget code or the integration points between the quest and geowidget code to describe how you are planning to implement this? What's unclear to me is, if we search through the db to get all the Locations, then for each Location we're also going need to search through the db to get the entities that connect to this Location, I want to make sure we are able to do this efficiently.
On the architecture, as much as possible let's keep it as a distinct feature/code module, but if we tightly couple it to fhir-core in place that's ok, as long as we keep note of that, we want to keep the LOE minimal on completing this.
@pld
- Can you clarify on what you mean by "geowidget code" and "the integration points between the quest and geowidget code"?
- Instead of getting all Locations and it's connected entities when we first initialize the Geo-Widget map (as I've seen it in the code). Why don't we just get all the Locations only? then only get the connected entity if the user tap a Location within the map.
- okay, for your 2nd paragraph.
For future enhancement, we might want to limit the Locations, by only getting the Locations within let's say 30km from the device current coordinate, then get more Locations if the the user scroll/move the map past the initial 30km area.
- Correct me if I've got the structure incorrect, it has been a while, but last time I looked there is code in
geowidget/, that's what I'm calling the "geowidget code", and there's code inquest/that launches into the geowidget and code in the geowidget that links back to quest, I'm calling that the "integration points" - That sounds entirely fine as long as the query get the connected entity is fast. A future thing (let's keep it out of scope for now), is that we may want to vary the map icons based on what is being linked to, e.g. show the icon for household location as different from a health clinic location -- I'll check w/the project teams to confirm we can keep this out of scope
@pld @FikriMilano We can do the location fetching in 2 ways
- Load the map based on the user's location then fetch locations in the DB and filter them based on the distance from the user's location. This means we have to add some processing before displaying the locations. This might not be very performant depending on how long it takes to get the user's GPS coordinates
- Give the user an option to select an area they are visiting. Then filter the locations to display based on the selected location.
What happens on OpenSRP 1.0
- OpenSRP one fetches all the Locations available on the device.
- The service points have different Icons and can have different color coding depending on the status of the resources tied to the Location. A list of Icons can be found here
- Correct me if I've got the structure incorrect, it has been a while, but last time I looked there is code in
geowidget/, that's what I'm calling the "geowidget code", and there's code inquest/that launches into the geowidget and code in the geowidget that links back to quest, I'm calling that the "integration points"
@pld Oh I see what you mean, yeah that's true, it's a live data events, similar to callback, and it exists in the geowidget side.
When there's an interaction, the code save that event into the live data events, the saved event contains what type of event the code is going to do and the location related data. Then on quest side, we observe that event, if there's a new event saved, we run the function on what that event will do (open a questionnaire / profile).
But the type of events are defined in the geowidget side with the context of quest, meaning, tightly coupled w quest. For example: One such event is OpenProfile, that is going to be invoked by tapping one of the location points on the map. Instead of that, I'll change it to, let's say, onClickLocationPoint. Then we will define what this event does in quest, that is, opening a profile.
Additional info after meeting w @AnnieMungai: Different types of service points have different icons. For example - a school will have a different icon from a hospital or a water point. The status colour cuts across the SPs with gray - a service point not visited, yellow - visit in progress and green - visit completed, white dot to show a cluster of SPs that become individual icons when you zoom in. And also blue - when the user taps the SP
For that reason, This is why we will need to fetch data from the resource related to the Location resource before we render the resources. In-short it's because we need the information of related resource data, whether it's in-progress or completed.
