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

Organizing and storing model outputs #30

Open
pkerins opened this issue Sep 4, 2019 · 1 comment
Open

Organizing and storing model outputs #30

pkerins opened this issue Sep 4, 2019 · 1 comment
Labels
housekeeping organization, rather than execution per se

Comments

@pkerins
Copy link
Contributor

pkerins commented Sep 4, 2019

As we continue to move beyond the predefined study areas of the Atlas of Urban Expansion, we need a better way to store and organize map outputs. For example, a given area could be mapped multiple times by the same model (ie model applied to different imagery); in theory each of those multiple images could also be mapped by multiple models. Then there are composite maps to deal with, along with ancillary data like cloud masks, cloud scores, raw predictions values, etc. At the moment we don't have a good, intuitive, and above all navigable way of storing these different potential outputs.

@pkerins pkerins added the housekeeping organization, rather than execution per se label Sep 4, 2019
@pkerins
Copy link
Contributor Author

pkerins commented Sep 5, 2019

For the record, the current solution here isn't terrible: you can group and store outputs by place & model, or however you like. You just have to remember to use the map_id parameter in map_scenes / map_tile. (If you don't, there is risk of overwriting; at a minimum, the outputs will be stored by the very opaque scene_id. Maybe this should be a mandatory argument.) Those outputs will then be stored by scene within a dedicated director inside of .../maps/. Not bad, but there is probably still room for improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
housekeeping organization, rather than execution per se
Projects
None yet
Development

No branches or pull requests

1 participant