Provide all resolution options for POI Review

[sisskind]

Given two POI's to review, A and B, here are possible options to show a user during the POI review (need to get feedback on this):

~~Merge A and B~~ ~~1. Merge A into B~~ ~~2. Delete A~~ ~~3. All remaining A reviews are redirected to B~~

A invalid

1. Set all reviews involving A to resolved
2. Delete A

B invalid

1. Set all reviews involving B to resolved
2. Delete B

A duplicates B

1. All reviews involving A are redirected to B
2. Delete A

B duplicates A

1. All reviews involving B are redirected to A
2. Delete B

A is a duplicate of some point other than B

1. Ask user to choose the point that A duplicates (??; would slow down review process)
2. All reviews involving A are redirected to the chosen point
3. Delete A

B is a duplicate of some point other than A

1. Ask user to choose the point that B duplicates (??; would slow down review process)
2. All reviews involving B are redirected to the chosen point
3. Delete B

In both the invalid/duplicates options, the user would be responsible for copying attributes over from the POI being deleted to the one being accepted if they need them to be retained.

Possibly, these options could be collapsed into fewer than what's listed here.

[sisskind]

@bwitham @jchoi1267 is there a mechanism/current code to 'redirect' reviews to other features (in event of duplication)?

[bwitham]

not that i know of

[jchoi1267]

@sisskind do you mean jump to a arbitrary review item? In that case you can specify sequence id of -999 and jump to a random one..

[sisskind]

@bwitham @jchoi1267 Referring to description above. Was not sure if it was something that would have to be developed or if it already existed. If a user determines that B is a duplicate of A and deletes B, Hoot needs to take all reviews for B and direct to A. Was not sure if that code existed.

[bwitham]

No, I believe from the list above "merge A and B" is the only on that's implemented.

[sisskind]

@bwitham @jchoi1267 Great -- but I think I can reuse the merge (redirect to C) for the duplicates. For the invalid, is it necessary to create additional button or if user deletes within iD, wouldn't all the reviews be marked resolved regardless?

[sisskind]

@bwitham @jchoi1267 Maybe I'm overlooking, but what would be the difference between marking as a duplicate and simply merging point B into point A?

[bwitham]

merging creates a new point and deletes the two merged points; marking duplicate would only delete the duplicate point

[sisskind]

@bwitham Is there a scenario where you would want/have to mark duplicate as opposed to just merging? Rather, is there harm in merging instead of duplicating?

[bwitham]

I believe in some cases you wouldn't want to merge with a duplicate if you didn't want its tags merged into the end resulting feature (would have to verify this use case with users).

So, a merge is for bringing together two features that are "similar", and you end up with a combination of their tags. On the other hand, marking a duplicate means one feature is superior over the other in every way, so get rid of the other feature (including its tags).

I actually misspoke in my last post... A merge picks one of the two features, merges the other one into it, and then deletes the old feature (no new feature is created anymore). Forgot that this was changed by #28 awhile back.

[sisskind]

@bwitham So, in theory, 'duplicate' could be a merge without taking any tags or attributes to the other feature?

[bwitham]

No, I think choosing duplicate just picks one feature or the other.

[brianhatchl]

My question in talking with Josh is,

If the duplicate feature is inferior in every way, why would the user want to link reviews from it to the better feature, if the better feature did not trigger those reviews itself?

Seems like a delete of the inferior feature and a delete of all it's reviews is the better action in most cases. The alternative of linking all duplicate reviews to the better feature is just creating more low probability (of a match) reviews for the user to deal with.

[bwitham]

You could be right. Honestly, I don't know the answer.... Personally, I wouldn't want to drop all of those reviews the duplicate was involved in, b/c there may be reviews in that set that didn't involve the feature you ended up keeping that were valuable to evaluate, and then that information would be gone. This seems pretty business case specific to me. I think it would need to be verified by someone actually using the software....the list above came straight from an email from @jasonsurratt a long time ago (although its possible I misinterpreted parts of the message).

[sisskind]

@jasonsurratt if you get a chance to add some context, it would be greatly appreciated!

[jasonsurratt]

As I see it there are two high level considerations:

1. Do we deal with the edge conditions in a sane manner?
2. Given input test data do we make reasonable decisions to reduce the errors and unnecessary reviews?

The list of scenarios above is primarily there to address question 1. We'll never have test data to cover all cases so we should handle edge cases in a logical if not intuitive way. When we have test data then we should try to tweak the rules to give better results.

I don't know if Brian's assertion about increasing the number of low probability matches is true or not. The only way I know to test that is to run it through our test data and quantitatively evaluate the results. I've found that my intuition rarely survives the first test run.

In all our existing conflation routines (except PLACES) intradataset matches are never established so if A reviews against B which reviews against C and A/C are in the same dataset the business logic should prevent us from linking C to A. However, if C is a conflated feature it may be relevant to review it against A. I think looking at multiple reviews at one time may eliminate a lot of these problems.

I'll be in the office tomorrow morning if you guys want to white board this. Regardless, it may be worth getting this information down in a more comprehensive form after we chat. Another section in algos with some example diagrams would probably be good.

Regards,

[sisskind]

Being put on backlog pending the outcome of #264, which may prove this to be no longer necessary.

[sisskind]

Is this still relevant based on #264?

[jasonsurratt]

Does #264 provide the user with the tools to address all these situations?

[sisskind]

@jasonsurratt we had discussed at one point that having the ability to review all features it is related to may make this no longer necessary. Was just revisiting since #264 is complete.

[mikejeffe]

it's my understanding that #264 just shows you where all the reviews associated with the selected/highlighted feature are but it doesn't provide the user with any course of action to resolve. We still only support single POI merge or resolve as we have done before. I've experimented with dragging POIs ontop of each other to merge them but the reviews are still there and it makes hoot seem a little "squirrely" when a review is loaded for a POI that is now merged.

[sisskind]

@bwitham @jasonsurratt is this OBE?

[bwitham]

I doubt its OBE, unless we've covered all the use cases in the description. Probably the best thing to do would be to ask users if the scenarios listed in the description make sense and then either close this or refine its scope from that info.. Since this ticket was created, we now have more user interaction and can possibly get better feedback.

[sisskind]

Thanks for the feedback. Will float this up for stakeholder thoughts.

[jasonsurratt]

IMHO displaying all the reviews for a given point at one time (like we do now) handles all of these cases. So yes, I think you can mark this as done.