Awkward API for tiles

[oubiwann]

If you take a look at hxgm30.map.tests.system.tile, you'll see what I mean. Creating a tile from band info requires not only the bands info (pixel-bands in the tests) but also a complex set of options. Each tests calculates most of these options based upon:

• the row in question (current-row)
• the column in question (row-item-index)
• the system configuration

There are several issues with these:

• why doesn't the API make all these options calculations itself? why does the user have to, for each call?
• what exactly are the variables and options used? They aren't very well documented ...
• what if we're writing code against a non-configured image size, format, or map projection? The API will fail spectacularly ...

Note that the initial intent for the existing API was simply as an ingest tool: parsing and correlating file data to be saved in a backend data store. However, now that the need has arisen to use this API more interactively or for scripting the generation of map features, it has become evident that the API in its current form is too limiting and difficult to use.

Dev tasks:

• [ ] Create a set of well-documented utility functions that do everything that's currently being done manually in each tile test ... create a bunch of unit tests for these
• [ ] Either refactor existing bands->tile function(s), or create new ones with different semantics for a better developer experience (if refactoring, we'll need to make lots of updates to the system tests)
• [ ] Create general-purpose functions that don't depend upon the system, but which can easily be used by system functions ... these can get unit tests
• [ ] Refactor system-based functions to have these new general-purpose functions do most of the work

[oubiwann]

I want to pause on this until #33 is resolved.

[oubiwann]

Actually, this ticket can inform the new service's implementation of the tile functionality here:

• https://github.com/hexagram30/raster/issues/16