Downloads

Work out the size first

Fetch the set manifest before anything else. It lists every part with its byte size, so the total is known up front. On the larger sets the total runs past 80 GB, which on a 100 Mbit line is around two hours of continuous transfer and considerably longer in practice.

If you only need part of the coverage, the manifest's tile extents let you pick the tiles that overlap your area and skip the rest. For most reusers this is the difference between a multi-hour transfer and a short one.

Resuming

Parts are served with range requests enabled, so an interrupted part resumes from where it stopped rather than from the beginning. Any client that supports ranges will do this on its own when told to continue an existing file.

Sets are deliberately not bundled into one file. A single 86 GB object that has to restart from zero after a dropped connection is not a usable way to publish this material.

Verify before you use it

Check every part against the SHA-256 in the manifest once the transfer finishes. A truncated archive part usually still opens, and the damage shows up much later as missing geometry in the middle of a cloud. Verification is the only cheap way to catch it.

If a part fails verification twice, it is worth re-fetching it on its own rather than repeating the whole set.

Concurrency

Two or three parts at a time is usually faster than one; much beyond that tends to be slower overall, not quicker, and makes partial transfers harder to reason about. There is no per-client limit enforced here, so the only thing stopping an unhelpful number of parallel streams is judgement.