A suggestion was made to provide a system to sort the images alphabetically. While this is possible, I think it would make more sense to just always sort them alphabetically. People will generally not add images in a specified order, so that seems like a safe thing to do.

If we do want to go in the direction of more functions, it would be possible to sort the images in several ways that I can think of straight away:

• By date added
• By name
• By distance from current position
• By size (big to small, small to big)

But all that probably requires several changes to the UI, partially also to surface some data that isn't shown at the moment.

vendor-93d30041d65a17892c34.js:1 Uncaught TypeError: this.setLayerZIndex is not a function
    at t.setLayerIndex (vendor-93d30041d65a17892c34.js:1)
    at HTMLImageElement.eval (userscript.html?id=919394a0-b527-4027-844c-2ad4bb8addeb:781)

And the "formatted" code from vendor.js:

        setLayerIndex: function(e, t) {
            var n = this.getLayerIndex(e);
            if (t < 0 ? t = 0 : t > this.layers.length && (t = this.layers.length),
            n != t) {
                this.layers.splice(n, 1),
                this.layers.splice(t, 0, e);
                for (var r = 0, i = this.layers.length; r < i; r++)
                    this.setLayerZIndex(this.layers[r], r); << Broken
                this.events.triggerEvent("changelayer", {
                    layer: e,
                    property: "order"
                }),
                this.allOverlays && (0 === t ? this.setBaseLayer(e) : this.baseLayer !== this.layers[0] && this.setBaseLayer(this.layers[0]))
            }
        },

Due to the way IndexedDB tries to prevent websites from filling one's hard disk with binary data, it may sometimes occur that images get removed without any user interaction.

For this reason it would be better to store the image location and metadata in Local Storage instead and have a reference to the image blob in IndexedDB. This allows the user to restore the image again later on should IndexedDB decide to remove an image.

An investigation should be made to see whether it is possible to receive a notification or some indication on when and why an image gets removed as usually this should require an IndexedDB instance that takes up a decent percentage of the disk storage space (based on the documentation, at least).

Images stored in the formats ECW and TIFF can store their geographical data. It would be nice if we could extract such information from those image formats and display them as well. Sadly enough these image formats are not supported by browsers, so displaying these would be very complicated.

While working with the opacity during the addition of an image can get you very far, some users also want to be able to temporarily hide the image. It is probably best to add a button to the controls that allows you to quickly toggle this.

It sometimes happens that other userscripts add map layers that are positioned above the image. This can be solved by adjusting the parent layer of that image, but this is not always as easy to see for the user.

An event listener could be added to the "layeradded" event of the map which will check whether any such layers are located above the currently active image. If so, it could show a small warning message in the tab indicating this potential issue and how to solve this.

By allowing an export, it becomes possible to share overlays and allows people to make a backup of their configuration (which apparently isn't a bad idea as the IndexedDB doesn't seem to be too stable in some browsers).

Whenever a user switches between the metric and the imperial system, all tabs are purged and the script needs to recover from this.

It is not needed to move and zoom the map if the image overlay is already visible in the viewport whenever the overlay is activated.

Consider adding a crosshairs button as well that only shows up whenever people hover over the image entry. Perhaps just hide all action buttons until that happens. Might be a bit impractical on mobile devices though (also listen to :activeevent?)

It should be possible to allow users to remove certain colours so those areas become transparent. By using a canvas element instead of a regular img tag, this might indeed be possible. See https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_canvas

Things to consider: this can currently already be done with external image editing software. Implementing this is not trivial, especially from a UX standpoint. This would also certainly require a way to undo changes while editing and the odds are high that once this gets added, other features will be requested that are already available within image editing software.

Currently all modifications you make to the image overlay are calculated from the centre of the image. It would be practical if you could adjust this so you would lock one corner so all edits happen from that corner. I'll have to whip out the goniometric calculations again to also support rotated images, as the rotation is currently applied as the last step and not actually accounted for in the extent.

Maybe release in two phases: one without support for rotated images (but with a message saying so if rotation mod 90 != 0) and a second phase with the full support.

Currently a big chunk of the screen is used to show the steps needed to import an image. This could be lessened quite a bit. See proposal from SeveriorumPatrem on the forum: https://www.waze.com/forum/viewtopic.php?p=1874091#p1874091

As an alternative to storing images in the IndexedDB, it would also be possible to accept an URL to the image and use that to display the image. This requires less storage, but might result in problems later should the image get removed at its source location.

As you may mistakenly click on the "add overlay" button while you're already adding one (and as such lose the work you've done already), it would be best to disable this button during editing.

Instead of working with buttons, it would be nicer if it was possible to stretch and move overlays with dragging handles. This should be possible with OpenLayers controls.

It would be nice to able to export more than one layer at a time. Ideally, this would be in a zip file (see https://github.com/Touffy/client-zip maybe), but otherwise it could be a huge JSON as well.

Preferably, make it possible for people to select which layers to export instead of just all of them. That would allow people to share projects with multiple images amongst each other.

Zooming in on an image overlay goes quite slow for big images. By generating a smaller image in advance for other zoom levels, it should be possible to increase the performance of the script.

Probably something to be made optional, but it is probably a best practice to always have an export of all mapped images. Maybe it would be an idea to show a small warning icon if a mapped image was never exported? And also show this icon again if changes were made locally?

Obviously, this should not be shown if a user imported the mapped image.

The main purpose of this feature would be to have a backup of all mapped images in case you accidentally clear the cache or if your browser data becomes corrupted.

Due to the absolute styling applied to the warning message about the permitted data sources, the scrollbar style of the sidebar isn't doing its thing whenever the contents overflow. This causes the accept button to be invisible until people zoom out. A simple addition of scroll:auto to this message will probably fix this.