How should the SQL API manage raster tables?

[mojodna]

Breaking this out from #199 to discuss.

My gut is that they don't need to be treated all that differently (beyond potentially determining which is the "spatial" column), as it's very much possible to generate columnar output when using raster analysis functions (or conversely, generating rasters by manipulating geometry columns). It's the output that (potentially) needs to be treated differently.

[javisantana]

not sure if I follow you. The main difference for cartodb in raster tables are:

• raster tables have associated overviews: so for example if you import pop.tif using import api different tables will be generated for each zoom level (o_4_pop, o_8_pop, o_16_pop, o_32_pop, o_64_pop, o_128_pop)
• instead of having the_geom and the_geom_webmercator they only have the_raster_webmercator (In the PR I wrote the_raster, I was wrong)

My gut is that they don't need to be treated all that differently

so that's it, you have available all the postgis methods to work with raster data, for example:

http://rochoa.cartodb.com/api/v2/sql?q=select%20min(st_summarystats(the_raster_webmercator,1)),%20%20max(st_summarystats(the_raster_webmercator,1))%20from%20pop%20where%20max(st_summarystats(the_raster_webmercator,1))%20is%20not%20null%20limit%20100

I don't know if you are referrin to this