Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Footprint format #28

Open
tombh opened this issue Apr 27, 2017 · 3 comments
Open

Footprint format #28

tombh opened this issue Apr 27, 2017 · 3 comments

Comments

@tombh
Copy link
Member

tombh commented Apr 27, 2017

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
Copy link
Member Author

tombh commented Apr 27, 2017

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
Copy link
Contributor

mojodna commented Apr 27, 2017

  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
Copy link
Member Author

tombh commented Apr 28, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants