Create a Check My Footprints Against Confirmed Cases Feature

[marleymarl]

This is related to issue #50 - within that new view, a user can toggle to / select 'Check My Footprints Against Dataset'. This would clear the map of any markers and they would have the same process as a confirmed case (i.e. they would now enter footprints on the map by clicking points and adding date and times and saving footprints to create a footprint geotimeline).

A function needs to be created for onClick of 'Check My Footprints' button that user would click after completing their timeline. It should:

a. Calculate the 'bounding box' of all of the footprints in the timeline to be checked (i.e. lat/lon of footprint that is furthest to the top-left and the one that is the furthest to the bottom right)
b. Calculate the earliestDateTime and the latestDateTime of the footprints in the timeline to be checked.
c. Pass these values to an API (URL to be provided) that will return an array of confirmed case footprints that match this geotimeline bounding box (time and space).
d. Compare the two arrays (user footprint timeline array and array of confirmed case footrpints inside bounding box) and Identify any matches in datetime proximity using same methods described in #50
e. Push any matches to a matchedArray that would be used to populate a separate match table and fire some alerts in UI

By doing the comparison on the client, the users footprint data is never even passed to the API much less saved anywhere.

[BaNazari]

a. plus adding the radius mentioned in #50
It is likely the bounding box covers a lot of cases because of many users who want to check their own paths in map's "hot zones" of pollution. In addition, they may have traveled between cities. Can we use the idea of radius in #50 here as well?
This flow needs to be triggered somewhere. I suggest we place 3 buttons on website:
Start a timeline - Let me test (Demo) - Check my footprints
Each of them can use their own keys when calling backend.

[rtf-const]

I just created PR #63. It contains very raw implementation of this feature. It is not ready for merge, I just want to make sure if I work in right direction. Do you have any implementation details describing how it should look like.

[marleymarl]

@rtf-const Looks like a good direction. I was starting to work on this a bit too so I have some small modifications but I think you can add them in directly. Assume MapContainer will take in a prop called 'inputOrCheck'. Someone will reach the map having clicked a button that sets 'check'. Now the footprints array represents the users timeline and when button is clicked it would fire your match request to api. I was going to put button text in a function like:

showWhatButtonText () {
    return this.props.inputOrCheck === 'check' ? 'Check Footprints' : 'Save and Exit'
              
  }

then

<button className="save-button" onClick={this.postData}> // need to do conditional on onClick
                {this.showWhatButtonText()}
              </button>

[marleymarl]

I will add the backend logic to take in your inputs here:

const url = `${global.API_URL}/getfootprints?lng=${boundaries.lng[0]}~${boundaries.lng[1]}`
            + `&lat=${boundaries.lat[0]}~${boundaries.lat[1]}`
            + `&timestamp=${boundaries.timestamp[0].toISOString()}~${boundaries.timestamp[1].toISOString()}`;

I think I will add a different API url /checkfootprints for that that will take in the event object expecting the geotime boundaries you are passing in above.

[marleymarl]

@heldersepu is of the opinion I think that we don't want to run this match on the client so I think we want to test both approaches. I guess we can make room to take in the user's footprints array as well on the API and run match on back-end. It could be a flag in the API call, e.g. checkOnBackend = true/false and how the response handled obviously then different.

[marleymarl]

@rtf-const Do you have any more update on this? I'd like to pick up where you left off if you're not working on it at the moment.

[rtf-const]

I wonder should we group contacted geopoints by case id like "you contacted with the case #xxx starting from 01/10/2020 12:00 tp 12:30, proximity 10-150 meters". Or we should asume that contact with a confirmed case is a rare event and we should display each contact point separately.

[rtf-const]

Also we have a distance of contact and time diff, we can use it as a threshold to check the contact, but for many people it doesn't have many sense. What if we can have some kind of a "proximity score", ranging from "light contact, low propability of infection", to "close contact, hight propability". Propably it slould depend not only on geographycal distance, but some factors like being inside the same building, duration of contact

[marleymarl]

I think that most confirmed cases will record their location/times by max 1 per hour+ so the grouping should not be necessary. But yes, I think we need to have a proximity range for time since the virus can live for a while at point X, maybe we do if for up to 24 hours after case was there. And proximity range of 10-100 meters sounds right since the confirmed case won't have it exact since they are pointing and clicking on a map.

[marleymarl]

I think it's a bit early to make the assumptions as to what a score can mean. I think we can just present the data (i.e. you were within a time and geo proximity of a confirmed case on day X and let the user interpret the data for themselves -> like small cafe is probably worse than train station but who knows?) I think it's probably enough either way to tell them that they may want to get tested now if it's possible. And maybe our tool helps them to get that test since they can show the data that they were potentially in contact.