FindData as recently been docked but also lost the “query” mode that let user specify exactly how they want to select the data. Bringing back this mode would be already nice but maybe we should take thius further.
eg: How to select the points containing the max or the min values of a data array ?
This is not doable currently, but I have a few ideas how to make that doable:
Special Keyworks
One could use value is one of actualMinValue, actualMaxValue but would need to know these values.
A solution could be to implement support for dedicated keywords, like min, max, med, mean. The usage would then be: value is one of min, max`
I’m not a big fan of this solution as that would be yet another “language” the user should learn and also the user would not to know about it trough documentation and tooltip only.
Query with buttons
Bring back query, but add buttons similar to the calculator so that the creation of the query would be much more easy to the user. is that case the syntax of the actual python query would be: value == min(value) or value == max(value)) but could be generated by clicking on buttons.
Indentation and OR
There is already a mechanism to combine multiple selection lines with an AND.
We could let user specify if AND or OR should be used, but then, how would user specify the order or operations ? Adding two small buttons that would let the user “indent” each lines would fix that. It would look like this:
SelectionExpression1
AND
- SelectionExpression2
OR
- - SelectionExpression3
OR
- - SelectionExpression4
AND
SelectionExpression5
Would correspond to: ( SelectionExpression1 AND (SelectionExpression2 OR (SelectionExpression3 OR SelectionExpression4)) AND SelectionExpression5)
There is no solution that looks like the good solution to me, so let me know if one does or even better, If you have another idea !
Another option is to add gear or something to switch to advanced mode. I this mode, all the combo boxes simply get replaced by the input widget to ensure the complete query string manually. This is similar to option 2, but without the buttons.
Having the gear icon swap out the interface instead of adding to it isn’t consistent with other uses of the gear icon, so for that reason I’m not too excited about doing that. How about bring back the Query option under the unlabeled combobox with ID, arrays, and Cell option like it was previously? Then remove the buttons ask Utkarsh suggest and just have the query field.
Regarding complex ands and ors. Indented UI is one way, but I think it would be a little awkward to use. How about assigning labels to each expression and then providing a text field to combine them?
One thing to keep in mind with defining compound searches - someday we should enable combinations of multiple unique screen-space selections and query selections. Ideally, screen-based selections would be listed in the same place as the query selections and logical combinations of them could be defined. Logical combinations of vtkSelections are already possible, by the way. See vtkSelection::Evaluate().
@mwestphal That’s great idea to enhance it! I know that’s hard but how about to connect SQLite engine to allow SQL queries on data? For the example see SQL SQLite dialect — GDAL documentation and this feature is very useful to do the same queries on any kind of input data.
@mwestphal It’d be provided as advanced query feature plus some options to auto-construction of simple queries. Otherwise, you need to do and support custom query parser yourself.
Ah, I see the confusion. Query strings have been numpy-like logical expressions. I think we should continue to use that mechanism, not develop a custom query language or use SQL-like syntax.
One thing to keep in mind is that make sure the UI shows up correctly when loading state/undo redo etc. The current UI parses expressions of the expected form and populates the collection of combo-boxes. Now that the expressions can be arbitrary, you’ll need to correctly show the query line edit, if that’s the case.