Update to maintain scroll position
Update the controlled and configure job code so that we can use a drop-down in lieu of state changing button.  Add a new column to contain the type (needs review from JR) and a text field indicating the current state (with a drop-down for those that are changeable.)  Ticket #31
Update the file info display to not use form fields for non-editable fields.  Suppress those fields that shouldn't be shown and use a grid with a 0 height header to display non-modifiable values.  Also compact the display a bit more by putting help text alongside the label.  Addresses issue #28
Change the code from round() ing values (which could result in the low value not being represented on the ramp) to instead using the floor() of the lowest value and ceil() of the highest, which ensures that the ramp doesn't leave off values at either end in the display of the legend.

Also correct an (unrelated) issue that caused the highest value values in a result from being omitted in certain cases.

This addresses ticket #27
Update the server code so that when we process the response we round to a specified number of significant digits, issue #22
Add in a new style/class to handle features that don't fit within our bounds of results - this is specifically to handle +/- Inf and NaN type values in our list of results when styling results that come back from a tool.  Issue #26
Start updating the data loaders so that we can properly convey the data type of fields back to the loader components.  This will allow us to determine the appropraite types when converting into spatialite/geoJson, etc. so that we can ensure that sorting works properly.  Ticket #33 .  Sorting works properly with the NMTK_id because that's the only thing we actually retain the type of.  In theory, this will also give us the ability to generate alternate color ramps (or style by field.), but doing so will require additional post-processing to determine max/min values for ranges.

Also upgrade to a newer version of the csvkit and some other libraries.
Update loaders and tasks to handle preserving data types for fields that are inbound.  See ticket #33 for more details.

This change uses type detection for CSV files (where columns are "typeless") and type detection for OGR data (where types are available/preserved.)  The CSV detection is a bit
tricky for a few reasons, which means we have some caveats in place.

1.  While an imported shapefile might have a text field like 123123234234123123, the csv loader will identify that field as an integer field.  As an integer field
    it would attempt to create an integer field in the databse - but that value is too large.  Besides the obvious downside to treating a string like a number
    (which, for example causes numeric sorting to be used for strings!), we overflow the field type.  For this reason, integerfields are not used when we
    load data into the database - rather we use the postgres numeric type with a maximum number of digits =32. That means we can support this, but
    only for values <= 32 digits.  Note that this isn't an issue with shapefile data, since the shapefile (dbf) would simply use the type provided.  This
    is mostly visible if you load the ALX data, then dump it to CSV, and then reload it.  The fips field gets converted to a number (and sorts as a number.)

2.  CSV loading is made slower by this process.  Previously we treated everything as a string, which was lickety-split fast.  However, now we need to read
    the entire CSV (each field) using a single pass, then iterate over each value in each field to figure out what type the data "fits" into.  In this
    way we can auto-recognize, date, datetime, time, string, float, and integer types (which is cool - esp when you want to sort a date field ascending.)
    However, it can be slower (depending on the size of the data being loaded.)

3.  Iterating over the data coming out of the loader is now a bit slower also, since for each row we get we make a pass over all the fields and coerce
    the data into the expected type.  This is generally a simple cast, but needs to be done for every column of every row; however in some cases
    (when we recognize a datetime string) we need to parse it (to identify the value) then do a conversion if needed - whihc is more expensive.

OGR loading in this fix is a bit more complex (since we now convert OGR types to Python types, but don't coerce the data, since we rely on OGR to provide us
with pre-coerced data.)
Add in the proper date/time/datetime coercion
Fix issue #35
Add in a slider for range-type filters, add in support for the API to allow filtering using standard django-style keyword/ORM filters.  Update to newer version of Ng-grid with some local fixes.  Update the controller for viewing data to start working on handling the advanced filters
Add in the work on adding new filters per issue #33
Finish up on the advanced filters stuff
Fix the UI so that is correctly indicates when filters are used
Fix several issues to the custom filters found in testing
Fix a bug where a change in filters wouldn't update the results
Fix for ticket #31
Update code so that when a user highlights a feature in the selected features list it also selects that feature on the map using a light gray color.
Update so we use a rolling window for session timeout - issue #44
Add in some basic stuff for the help button, which is a work in progress