Select for duplicate capture matching check

[sebastiangaertner]

In order to be able to find duplicates with the verify tool it would be amazing if we could select 2 or 3 or 4 images and run a simple distance check. Practically a verifier sees trees that are similiar but can maybe not judge if they are duplicates or not. If we had a simple pop up showing the distance between the points that would be a great start.

[nmcharlton]

This sounds like a cool feature. It would be great to get some UX design effort on this.

[nmcharlton]

A small map with selected captures plotted would be very simple to add to help visualise this feature.

[nmcharlton]

For anyone looking to pick this up, we have a lat/lon for every capture, so calculation should be very straightforward using getDistance() from geolib (see /src/components/CaptureMatching/CandidateImages.js).

[amesk3]

@nmcharlton and @sebastiangaertner, I can pick this up.

Before I get started, I just wanted to make sure on the ask:
We want a distance check between the 2-4 selected images and possibly visualize that on a map to catch possible duplicates.

My questions are:

1. Would we want to check the distances between each image against the others (so if there were 4 selected, there would be 6 different distances to check), or would be comparing the distance of the image that was selected first image versus the others (if there were 4 selected, there would be 3 distances to check)? I think the first way might crowd the UI a bit to list all the distances, and the second way is a bit convoluted since we have to choose things in order.

I think to keep things simple and intuitive, it might be good to keep the distance calc between only two selections and perhaps list that in the SidePanel, if we are displaying distance numerically. If we're displaying things on a small map visually like Nick suggested (which we only need the lat/log for, and not necessarily the numeric distances listed), I think 2-4 makes sense. Please advise!

2. Since there is no wireframe for this, I want to be careful in where this small map/distance calc numbers will be situated - would this be a popup, or live in the SidePanel, or something else? I'm still new to the app, so still trying to figure out design norms.

Thanks!

[sebastiangaertner]

@Kpoke meet @amesk3 . I have given Amy a dataset from the legacy DB and as discussed it would make more sense to get this tool developed off the treetracker schema rather. @amesk3 reach out to Daniel to coordinate the data structure to be sure that it reflects the upcoming Domain model migration. We can add this data into dev if we change planter_id and the coordinates by a small value (always the same value)

[nmcharlton]

Hi @amesk3. Sorry for the delay.

What do you think of a simple label with beneath the Select All and Select None buttons?

Distance between selected captures: x.x m

It could state the greatest pairwise distance of up to four captures (or some reasonable limit given O(N!) computation time), then grey out when too many are selected.

Perhaps when one capture is selected, we could also include the distance to that capture in the quick-look tooltip when the user hovers over each of the other captures.

[amesk3]

Hi @nmcharlton , no worries- I was just plugging away!
I thought of doing it that way with the pairwise distance before, but after speaking to @sebastiangaertner on the UX side of things, and we both agreed that just giving the distance (without any context) might not be super intuitive, and thought doing it visually (way you suggested before) might work better. I'm adding a screen capture of my prototype and some rough wireframe to go with it.

In the example. we are given three lat/long points, NY, Chicago and Johannesburg (the coordinates are real). These three points have been transposed from lat/long to x,y on a html canvas, and the viewport has been focused to show the three points, you can think of these as the checkboxed 'chosen images' in the app. We assume a threshold, and say, according to the threshold, NY and Chicago are too close to each other to be 'different images', however, Johannesburg is far enough in distance that it a different image from the other two. We can color code Chicago and NY as RED to indicate that these two are 'too close' and GREEN for Johannesburg that it is a far enough image from the other two, and thus user does not have to be as worried about it being the image from the same source.

Of course, in reality, we will have coords for images of trees, and not cities, and a completely different threshold/viewports to indicate whether the images are 'too close' or 'far enough from each other' to be considered different.

Here's the original 'wireframe' that I'm using to guide me in terms of placement of components.

Another note: there's not much backend interaction other than fetching the lat/long (which is already being done) and doing the calculations on the frontend to display. If we keep it <5 selected items, I don't think it will take to long to calc the distances and to display them.

I'm doing the prototyping in a codesandbox to make it work and then I'll integrate it into the main code.

Please let me know if you have any concerns of doing it the above way-- thanks!

[amesk3]

Thinking more about this, @nmcharlton I think it would actually be beneficial to add 'Distance between selected captures: x.x m' like you said, when only two images are selected. For 3 or 4 images I still think the visualizer will be easier to deal with. To me they seem like two different use cases.

I can almost see these two being v1 and v2 of this feature-- v1 being the distance display for just two images (simple), and v2 being the visualizer for 1<x<5 (more advanced).

Either way, I can do either one or both. Let me know please!

[sebastiangaertner]

Sounds great from my side. I think making a v1 version and then testing it for a while and adding specific functionality to it and changing UX is totally legitimate since this is really about intuitive quick comprehension of the information that is conveyed.

[nmcharlton]

@amesk3 This is fantastic! I love the visualiser as a v2 implementation as you suggest. We may even be able to use a very simple version of the web map for a consistent user experience (assuming it doesn't become to cluttered with a satellite image underneath). I can see users wanting to quickly plot a batch of captures on a map like this to check the trees are distributed as expected.

Let's go with the v1 option to address the simple case quickly, then iterate on the visualiser.

Great work!

[amesk3]

Thank you! Please see my the PR for the v1 changes! @nmcharlton