From slack conversation with @arvind, interval selection of geographically a projected plot is quite tricky. Here is my interpretation of the problem:

Plots without Projection

For plots with normal x/y scales (without projection), we apply predicate in data space so it's easier to reapply predicate to other subplots.

From user's visual selection like

5 <= x <= 10 && 0 <= y <= 5

we can apply scale inversion to perform the predicate in the data space instead.

invert_x_scale(5) <= invert_x_scale(x) <= invert_x_scale(10) && invert_y_scale(5) <= invert_y_scale(y) <= invert_y_scale(10)

which is simply:

invert_x_scale(5) <=x_field <= invert_x_scale(10) && invert_y_scale(0) <=y_field <= invert_y_scale(5)

This is possible because our quantitative scales are all monotonic* so applying inversion on both side of inequalities will preserve the inequalities.

Note: * For the derivation above, it actually has to be monotonically increasing, but if the scale is monotonically decreasing, then we just need to flip the inequality so it still works.

Plots with Geographic Projection

For geographic projection, from user's visual selection like

5 <= x <= 10 && 0 <= y <= 5

where x = project_x(projection_name, lat, long) and y = project_y(projection_name, lat, long).

However, we can't just apply inversion and preserve the inequality since projection inversion is not always monotonic (and is mostly not). Doing so means the selection won't match the rectangle boundary like in this screenshot:

(It could be even worse for more complicated projections.)

There are probably two solutions:

a) For projection, apply the predicate in visual space. For example, we can still do

5 <= project_x(projection_name, lat, long) <= 10 && 0 <= project_y(projection_name, lat, long) <= 5

but this will require a lot of refactor as our existing code always perform selection in the data space.

b) Invent a way to convert the whole inequality statement in visual space to statements in data space.
(This is probably result in a complex path inclusion checking rather than two simple statements.)

cc: @jheer @domoritz

@arvind -- please feel free to add / correct if there are parts that are unclear or if you don't agree :)