Currently, we expect storage to be managed by parties interested in publishing imagery to OpenAerialMap. For processed imagery, it is expected that providers publish appropriately optimized imagery before indexing it in the OpenAerialMap imagery index.
In order to make OAM images easy to access for remote clients, the OAM project is looking to have processed images fulfill a certain set of requirements to limit the network traffic needed by OAM tools / intelligent clients to fetch the data they need where possible.
Generally, what this means is that the image is:
Archive images will be read by the OpenAerialMap server to gather additional metadata – the metadata of the file is presumed to override the metadata passed in by a user, where available.
OpenAerialMap imagery will be accessed over the network – either directly, or via client tools. As a result, one of the important aspects of processed OpenAerialMap imagery is to minimize the amount of network bandwidth consumed. As a result, we have attempted to identify the best option for saving space for storage as well as minimizing potential network bandwidth while not compromising image quality.
For more information on creating OAM-friendly imagery, visit Creating OpenAerialMap Imagery.
One of the consistent problems of distributed storage without replication is that any point of failure becomes a single point of failure. As a result, OpenAerialMap will begin life in a position where failure of a single imagery host may create a situation where some imagery becomes unavailable for a time.
However, overall this effect is less of a problem early on than it might otherwise be for a couple reasons:
However, as the project grows, it is expected that this solution will grow untenable; as such, investigating fault-tolerant distributed storage options to help prevent this kind of failure will likely be a goal of the project.