The cache needs some kind of smart indexing. Ideally we have a data structure that supports fast nearest nieghbor search and inserts. For now, since we only have a single dimension I will use a sorted array.

We can optimize the queries we sent to postgres by only downloading the delta to something we already have. To support this, we need to be able to do lookups for close index values similar to what we do in the client.

Since data can come from different nodes, the error should be per cell/bar.

• update API
  • batching
  • ranges
  • zooming/ resolution
  • 2D
  • Init
  • Preload
  • Caching
• zoom tree
  • Insert
  • Lookup
• index structure
  • R-tree/ KD-tree
  • 2D data
• Update visualizations
• Preloader
  • send queries
• batching
• compression using JPG
• GC

• Show as fraction

• put total flights at the top or the bottom, not in a random place.
• Need info to provide context for titles. Add units.
• Clean up labels and axes.
• figure out whether it makes sense to have 2D views for the specific tasks. Could bias participants to answer in certain ways, makes certain attributes look more important.
• add more padding between plots.
• 2 titles are redundant in 1D views.
• having continuous axes with discrete bars is a little confusing.
• brush handle disappears when brush intersects view boundaries. add padding to the plot so they don’t disappear.
• make count/total bar chart horizontal?

Add a mapd database

• Move logger out of this repo

Take velocity, acceleration and roundtrip time into account.

the random backend breaks our assumption about the data, namely if we are querying for [0, a] and [0, b] with a < b, we expect the elements of the results of b to be greater than the corresponding elements of the results of a. the random backend doesn't guarantee this and leads to some issues trying to draw negative values

Brush start and mousein for charts do not have brush start and end so we should support partial logs.

I am curious if I could use this library to create an interactive visualization based on the Vega Lite spec built up by the user in Altair. Do you think it would be wise/possible to generate the App views based on a vega lite schema?

Obviously, if we wanted to output directly from Altair, we would also need to create a db, but we could do this pretty easily based on a MapD database URL.

• Use summed "area" table to precompute histograms on active chart
  • Be smart about the order of computation based on mouse movement
• Compress data sent over socket
• Use prepared statements

I think that brush ranges are not inclusive because in the weather data a brush over 0 does not show many items.

From #41

• You won't see any data until a adding a brush. The results from init currently have an explicit index value, but these need to be special cased for having an "infinite" index
• The brush and zoom aren't playing nicely right now, the brush should be resized when the user zooms in/out. There should also be a keyboard toggle so you can pan without triggering the brush.
• There are still some issues with the two dimensional brush, I've disabled that hitting the api until that is fixed

When we clear the brush, we should have the full range somewhere.

I simply try to use a second brush.

The server shows this error

QueryResultError {
    code: queryResultErrorCode.noData
    message: "No data returned from the query."
    received: 0
    query: {"name":"DEP_DELAY-9","text":"\n      SELECT width_bucket(\"DEP_DELAY\", $1, $2, $3) as bucket, count(*)\n      FROM flights\n      WHERE $4 < \"DEP_DELAY\" and \"DEP_DELAY\" < $5 and \"DISTANCE\" < $6 and $7 < \"ARR_DELAY\" and \"ARR_DELAY\" < $8\n      GROUP BY bucket order by bucket asc;\n    ","values":[0,100,25,0,100,1016.1363636363637,39.09090909090909,59.77272727272728]}
}

But the query seems to be correct and returns data if I run it in psql. Any ideas?

It would only be a fair comparison to our fancy version of we fetch on every brush move.

Want to track which view is active.
Can switch from pull to push for recording mouse positions.

We somehow need to tell the server that we want to preload both sides of the brush. I'd say we should change the interface of preload to take two values. The server logic becomes a bit more complicated.

• Add axes
• Fix domain and range
• Add color overlay to show current vs all data
• Fix bug where brush range isn't being cleared correctly

It looks like there are some issues with is cached. Look into it.

We need to be able to demonstrate the unoptimized baseline without any caching and round trips for every request.