-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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 |
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.
The text was updated successfully, but these errors were encountered: