Excluded numbers from the autocomplete source list.

This works because CouchDB's sort order of JSON types places numbers before
strings, and strings before arrays.
Numbers are most likely individual for every document, so there's no need to
make a suggestion out of every floating point that exists.
Equipped start_key and end_key to _list/tabulate/type-year.

It doesn't do anything if all types are selected, but it greatly restricts the
amount type-year keys if nearby types are selected.
Sketching criterion for pre-filter to _view/fields-values.

I've included _keyword as well as field/value because even _keyword might run
faster in some cases if I crafted this in an awesome way:
- Document counts of less than 100 won't be pre-filtered.
- _expressions are no use to pre-filter in any case.
- Single fields over multiple types might not be good to pre-filter; I suspect
  _view/fields-values to run over too many unused rows. On the other hand if
  you have a bunch of very similar documents, who knows?
- If the mere existence of a field has to be known, group_level expands over
  [<type>, <field>] to improve _list response time.
Regardless of these precautions, it is still essential ensuring the number of
rows processed by _list/tabulate to not exceed the number of documents.
However, because I don't see a safe and easy way to count the number of unique
keys, I placed a limit of 1 and skipped over the number of rows I set as a
threshold.
Dropped variant group_level in pre-filter query params.

Simply because _list/tabulate doesn't yield the keys that have to be forwarded
to _view/fields-values. They have to match exactly and they don't when the last
element is missing.
Single-quoted cut.field if it isn't _keyword.

Unfortunately row.value.doc still has flat-hierarchy fields and I cannot
inflate them because in the reduce function I am unable to
require('view/lib/path').
This spoils my beautiful code symmetry and another day is ruined.
Truncated last coordinate digit in utils/simplify().
Removed empty cuts array from options.

The empty cuts array caused an exception when filter_documents was looking for
cuts[0].remove_me.
Rearranged new_filter.redo to the left.
Factored in distorted latitudes in utils/size().
Removed _spatial/bbox query temporarily.

In case of 5000+ geometries it might be faster to use _list/bbox-filter/bbox
instead of _spatial/bbox, because the latter yields a 1.2MB JSON object for low
zoom levels.
This just puts the viewport stuff together.
Recoded traversing the viewport stack.

This does exactly the same thing but I need the index later.
Changed update_items to extend the last viewport.

The last viewport can only be extended if only one vp was removed from the
stack and if the list("bbox-filter/bbox") returned the same items.
I still could construct a scenario where these conditions would result in a bad
viewport, perhaps if limit=1 and we have a large item and a larger item in the
middle of the first one. The larget item would have to cover lots of vertical
space but almost no horizontal one. Then the user has to move the map really
fast from one side to the other. Etc.
Added pad to the viewport stack.

pad is a bit tricky: it touches the most outer border of all the displayed
geometries' bboxes borders directing to the center. So, as soon as pad lies
outside of the viewport, we can assume the same for one or more of the
displayed geometries.
Inversely, we can skip the geometry update as long as it's inside.
Calculated viewport.pad.

Gaah it looks messed up but it must be this way:
- viewport.pad is a bounding box and therefore pad[0]<=pad[2] and
  pad[1]<=pad[3].
- The bottom-left edge of pad is assigned to the top-right edge of the bounding
  boxes that lies most bottom-left.
Simplified _list/bbox-filter query using viewport pad.

The list is constructed in a way that I can remove bbox from options without
causing it to crash.
Added new vieport unconditionally.
Directed extend_vp to the right viewport.
Installed limited query to _spatial/bbox.

As it says, response is limited to 50kb, and as soon as there seems to be an
overflow of the amount of geometries, I reverted to _list/bbox-filter/bbox.
After all it isn't that bad.
Avoided array concatenation if it isn't really needed.

Unfortunately I haven't figured out what to do with the spatial response if an
overflow occured. Right now it is just ignored.