openimagerynetwork / oin-meta-generator

A metadata generator for OIN
5 stars 8 forks source link

Footprint format #28

Open tombh opened 7 years ago

tombh commented 7 years ago

Up till now we've been using a simplified expression of footprint that provides little more than that already offered by bbox. @mojodna has already implemented a more comprehensive format in oam-dynamic-tiler's tiler-prep stage. As he describes, it is;

non-rectangular and shows the image's footprint after it's been masked out, with nodata and otherwise [...] this samples at 1% (?) to keep the GeoJSON size down, since the end result is stair-stepped no matter what (because it's polygonizing pixels)

This is clearly a better solution. However, we need to formalise both the necessity and optimal format. Therefore:

  1. 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?
  2. Currently the footprint payload is non-trivially large, for example, for a 325MB image, this footprint is 24kb. Of course, this can be simplified by down-sampling, simplifying polygons and using topojson. However, we need to define certain expectations. Can a single OIN meta data payload function reasonably as intended if it is, say, over 5kb? If not then can the footprint be useful with a limit of, say 3kb? If not then should the footprint be kept separately?

Follows on from discussion in #26.

tombh commented 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.

mojodna commented 7 years ago
  1. 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.

tombh commented 7 years ago

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?