Clear previous selection on select features once a new selection drawing is initiated about gm3

[klassenjs]

Why would the selected/highlighted features clear before clicking Go? What if the user changes their mind and cancels? Do we want to destroy the select/highlight then?.

[theduckylittle]

I'm sorta with @klassenjs here, I know you can create this incongruous situation but these are all understandable steps that the user would've done.

[elil]

Personally I'd rather not hit go at all but have it go automatically upon completion of the selection geometry. Clearing the selection not at the start of a new selection geometry but at the completion is what makes sense to me, although it is unclear when a multipoint is complete and duck mentioned that at the start of a new selection geometry might work better in the existing phases.

…

On Wednesday, June 7, 2017, theduckylittle ***@***.***> wrote: I'm sorta with @klassenjs <https://github.com/klassenjs> here, I know you can create this incongruous situation but these are all understandable steps that the user would've done. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBPmsGFiG6tvg7dCoHpM7Zm5NZDm2Alks5sBowRgaJpZM4Nx9Oj> .

[elil]

Yes, I would say the old selection is gone as soon as they decide to make a new selection, if they want the old they can redo it. You don't get to keep both your old selection forever and make a new selection.

…

On Wednesday, June 7, 2017, Jim Klassen ***@***.***> wrote: Why would the selected/highlighted features clear before clicking Go? What if the user changes their mind and cancels? Do we want to destroy the select/highlight then?. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBPmuJzSZWNEzbYK24hgkVT10jsmP4_ks5sBouEgaJpZM4Nx9Oj> .

[klassenjs]

How do you know when it is the end of the selection geometry? In general a user might want to revise their input, but particularly with multipoint.

[theduckylittle]

One of the usability complexes here is that we now allow for more "post processing." We have the ability to slice-and-dice the results in ways that are not preserved. As those slices-and-dices are done against the results and not against the query itself.

I get not wanting to hit "Go" at all but there are some issues there:

1. The multi-point selection mentioned above.
2. Adjusting buffer radius.

I think "Go" is still a necessary evil but I think if the user begins drawing on the map we could, ostensibly, clear the last query results.

[elil]

For line and polygon, double click signals the end of the selection geometry. For box (if implemented and enabled), letting go of the mouse button is the end. How can input be revised now? My impression is only through redoing it, which would still be the same option available to them. Multipoint is of course tricky, it could continually repeat after each individual point which would make multipoint the only non-clearing option. Otherwise, require go for multipoint or require a double click on the last point of multipoint.

…

On Wednesday, June 7, 2017, Jim Klassen ***@***.***> wrote: How do you know when it is the end of the selection geometry? In general a user might want to revise their input, but particularly with multipoint. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBPmmUVfUt3xg01Iirx1c5mlSyXgDMfks5sBpHygaJpZM4Nx9Oj> .

[elil]

Adjusting radius buffers happens live on the screen for the input geometry. One approach could be to extend to the selection too.

…

On Wednesday, June 7, 2017, theduckylittle ***@***.***> wrote: One of the usability complexes here is that we now allow for more "post processing." We have the ability to slice-and-dice the results in ways that are not preserved. As those slices-and-dices are done against the results and not against the *query* itself. I get not wanting to hit "Go" at all but there are some issues there: 1. The multi-point selection mentioned above. 2. Adjusting buffer radius. I think "Go" is still a necessary evil but I think if the user begins drawing on the map we could, ostensibly, clear the last query results. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBPmnWmDl11VB321t-I7--wKZ2THL01ks5sBpIhgaJpZM4Nx9Oj> .

[klassenjs]

My general thought process is to draw what I want and then set the buffer I want. Without a Go the buffer would have to happen first.

Also, in the past I have traced over a previous select while drawing my new one (to slightly adjust a previous result I wasn't quite happy with).

[elil]

You could still set the buffer second (that is what I do too); the select (with the buffer) would happen again.

I do that too, it is also why I prefer to keep everything until the geometry is completed not just started. But started sounded like it fit better for implementation.

[theduckylittle]

i'm wondering if #273 offers a reasonable compromise for everyone?

[elil]

#273 seems to give fine grained control to users who want it. There doesn't seem to be any way to change defaults so that only users who want it need to learn it. But this seems to offer all options to users willing to user those options. So yes, this should work. I'll look at it more once it is in the demo.