Improve handling of multilayer formats

[springmeyer]

I'm trying to add FileGDB support and noticing a design limitation: mapnik-omnivore assumes a file has only one projection.

In the case of FileGDB each table is a layer with a potentially unique projection and extent. This means that inside processOgrDatasource the getCenterAndExtent and getMinMaxZoom functions need to operate per layer and not per file.

[rclark]

@springmeyer I think we may try and bite off #68 soon, but this introduces a new wrinkle that makes me think we may not be able to accomplish this kind of refactor without significant breaking changes.

Currently we're outputting a JSON object that more or less assumes that your file has one projection, one extent, one center, etc. We could adjust the output such that its more like:

{
  "filepath": "/somewhere/some.file",
  "layers": [ "array of objects describing proj, extent, etc" ]
}

Or, alternately, we could treat each layer in a filegeodatabase as a distinct datasource, and adjust the inputs to allow for designation of the layer-of-interest:

omnivore.digest('/path/to/raster.tif', callback(err, result) {
  // result is valid for the only "layer" that exists
});

omnivore.digest('/path/to/geodatabase.fgdb', 'some-layer', callback(err, result) {
  // result is valid for the designated layer
});

omnivore.digest('/path/to/geodatabase.fgdb', callback(err, result) {
  // result is valid for the first layer??
});

[springmeyer]

I'm okay pausing on this until after more critical refactoring passes are in place. As far as how to re-design, I like your second idea of digest staying basically the same but being told to operate on a specific layer. It makes me wonder if mapnik-om could then gain a higher level function that could operate on an "connection string" and detect if a given resource has multiple layers or not. Something that would work on either file://path/to/some.ext or postgres://dbname=world or file://path/to/gdb and be used before digest?