As some of the fellow Wiki Contributors on this wiki appears to have resumed development of our interactive minimap system (demo on my profile at the moment), I have a question in regards to optimizing the memory usage for this system.
Currently the minimap works in that we have one large image, which gets resized - but if you're zoomed in on the minimap, you don't really need to have all the content not displayed within the canvas boundaries, and if you're zoomed out, you don't need the fine-detail image that might very well be 10000x10000 pixels alone.
The possible solution I have come up to solve this is to provide a tiling system - based on how other map systems such as Leaflet (leafletjs), Google Maps, OpenMapTiles, etc. works [note: could need more in-depth technical validation].
To quickly explain the way tiling works, is that instead of having just 1 image to work with, if you zoom in, you get small pieces of the map as tile images, and only the images within your canvas area are fetched, with regards to the respective needed quality level and so forth. An example of a tiling service would be something like `www.example.org/fantastic-frontier-map/world/x/y/zoom.png`.
The problem so far is to figure out how these tile images will actually be provided - and organized. I would prefer to have it hosted here on the FANDOM wiki, as a guarantee that the images are available and can be updated by members of this community. But since I do not know of any CDN as a part of the FANDOM wiki, it seems that we would need to make our own approach to how to provide these images, which can become quite tedious for the individual to start.
My thoughts so far is that:
A) We can have a custom data file (MediaWiki scope?) which contains a JSON structure of the tiling data.
-> Pros: From prior examples, this can be done.
-> Cons: From prior examples, I know that many of our members do not know about the MediaWiki scope, data files or something as tech-nerdy as JSON. This would be quite infeasible for onboarding new contributors, be a quite large file, at the fault of breaking the syntax. Also, we are not aware of a way to make it so tile images do not show up in the search cluttering results with hundreds, if not thousands of results of images.
B) We can (possibly?) use some JS API calls to MediaWiki/FANDOM Wiki to base our pulling of images based on image name.
-> Pros: This would make it much easier for people to add / update images, as it only depends on the image name. No coding experiences needed.
-> Cons: This does not tell us about the total grid size of tile images (ex. 5 columns of tiles, 6 rows), so we ultimately may need a supplement, unless the JS API can do this in a single init call. Also, we are not aware of a way to make it so tile images do not show up in the search cluttering results with hundreds, if not thousands of results of images.
I look forward to reading what thoughts you and / or your fellow Wiki Managers know of / recommend on this field :)
Hello! I've taken a good long look at the interactive map you've created. It's quite brilliant, and I understand the issues you're encountering and the questions you're bringing up.
Regarding memory usage, that is indeed an issue and I'm not sure how you can solve it regardless of where the data and script are hosted.
I should also mention the bus factor. The concept of wikis is to provide accessibility to a large audience who can also contribute and edit. Particularly complex scripts like this one make it a bit more difficult to edit and contribute, which makes the tool difficult to maintain if some day you are not able or available to do so. If you're concerned about the tech-nerdiness of JSON, imagine someone who doesn't know the term JS being in a position to maintain the tool and you will be closer to level of the average editor.
The tool you've made is gorgeous as it is. I don't want to see you pour more and more effort into it for potentially limited returns. My recommendation is that you focus on alternative solutions that are less complex than this one rather than doubling down investing in it.
Thank you for the reply. So, as the situation with the minimap stands, adding effort into new additional capabilities for that system may not be worth the outcome.
Taking a step back to look at the current system and managing it on a broader view, I would think it more feasible to look into ways to make the adjustments / changes of such a minimap system more visual and simple to setup.
By this, I mean changing out anything that requires knowledge of JSON with a graphical user interface to add/edit/remove map markers, map regions, map worlds and so forth.
Of course, the interactive minimap will - to my understanding - never become the only minimap that we offer, but is a supplement to the static one.