Open tombh opened 7 years ago
Personally, my gut feeling right now is that we use the new format, but force a restriction on the footprint size to no more than 1kb (give or take). That is enough to give a rough indication of the imagery's shape significantly over and above that already provided by bbox
and it keeps the meta data small enough that it allows multiple payloads to be fetched in-browser on most internet connections.
- What purpose does the footprint serve? Does it serve any purposes beyond oam-browser's use? Can the purposes be served by the bounding box or a centroid? Or perhaps having a detailed footprint means that a bounding box field is superfluous?
For my work with Mapzen, I'm using the footprints (loaded into PostGIS) to determine which source files to use when rendering a given tile in a mosaic (involving thousands of source files at varying resolutions). Knowing the (approximate) shape makes it possible to skip loading sources where the bounding box overlaps but the actual footprint does not.
I think bounding box (for quick intersections) + footprint are both important.
Yeah so 24kb footprints are fine in PostGIS, but not so good in a browser. The question is, within the context of OIN, does a <2kb footprint offer anything of significance over a bounding box?
Up till now we've been using a simplified expression of
footprint
that provides little more than that already offered bybbox
. @mojodna has already implemented a more comprehensive format inoam-dynamic-tiler
's tiler-prep stage. As he describes, it is;This is clearly a better solution. However, we need to formalise both the necessity and optimal format. Therefore:
Follows on from discussion in #26.