Add demo for basic image warping via gdal.js + loam

[CloudNiner]

Overview

This PR adds a relatively simple demo for image warping via gdal.js + loam.

The basic algorithm used to warp the image is:

1. Calculate a grid of GCPs across the image
2. Use gdal_translate to add the GCPs to the image metadata and convert from source image type to tiff
3. Use gdalwarp to warp the image via the GCPs using thin plate splines via the -tps argument

Demo

Notes

A discussion with @designmatty resulted in this super basic, no minification, no scss project structure. We figured that we can clean this up and add any appropriate build tooling once this is a workable demo.

Thanks to @ddohler for assistance in some debugging of gdal.js, including instruction on how to do custom builds, navigating the emscripten build options and some debugging help with loam+gdal.js.

There are quite a few directions we could go with this from here:

• Clean up JS build and style the app, plus implement an interesting UI/UX workflow around this basic operation
• Clean up the GCP+TPS implementation, by adding more control points or attempting to optimize placement of the existing ones
• Investigate and fix any issues running this on Safari/Edge to get good cross platform support
• Improve pre-load of the gdal.js files, so that the operations are faster. After running one warp operation, subsequent ones are almost instantaneous.

Testing

See the "Developing" section of the new README for instructions on running locally. Ensure you're able to upload an image file and have it display on the map. Then ensure that after clicking the "engage" button, that it is disabled while the warping operation takes place, and a usable warped tiff is downloaded. Some debugging info will be printed to the console as the operation commences.

The app is testing to work on Chrome/FF. Theoretically, it should also work on Edge. I had trouble running on Safari, where I got an error in the webworker while performing the warping operations. I didn't investigate this any further ATM:

[ddohler]

This looks good; I found one typo and made a couple usage suggestions that may make the experience a bit smoother for users.

[ddohler]

You can use loam.initialize() to start pulling down the WebAssembly asynchronously right after the initial page load. That should address the long latency for the initial warp. All the other loam operations (are supposed to) rely on the loam.initialize() promise before they do their thing, so you don't (shouldn't) have to pay attention to the return value of that function.

Another possibility is to initialize() once someone clicks the file-picker so that we don't use that bandwidth until we know they're serious, but in this case that's basically the only thing they can do, so I think it makes more sense to start loading the wasm immediately.

[CloudNiner]

Second part of your comment is a great optimization and it wouldn't hurt to just put it there right away. I'll make the change.

[ddohler]

I think this needs to be removed.

[CloudNiner]

whoa. oops.

[ddohler]

This and the warp call are going to leak memory unless you keep track of the intermediate datasets and close them. It's not great, but the best approach is probably something like this:

var imgDataset, gcpDataset;
loam.open(file).then(function (ds) {
    imgDataset = ds;    
    ...
}).then(function (ds) {
    gcpDataset = ds;
    ...
}).then(...).then(...)
.finally(function () {
    if (imgDataset) {
        imgDataset.close();
    }
    if (gcpDataset) {
        gcpDataset.close();
    }
});

I've got some ideas for refactoring Loam so that this isn't necessary because it's super annoying; I'd be interested in talking those over at some point now that you've used it a bit.

[CloudNiner]

Right, not ideal but I'll make this change. It's reasonable, even with the demo, to expect someone to attempt to warp multiple images.

[CloudNiner]

I'd be happy to talk about ways to improve loam in this regard, feel free to toss something on the schedule, or we can chat over lunch sometime.