Adding proof of concept for using a maplibre backend vs. OL

[calebrob6]

Go-to ftw-inference-app/maplibre and check it out.

[isaaccorley]

Just needs a formatting with prettier

[ahocevar]

It works. But the question is: why would we want to switch to MapLibre? The focus here is on raster data, and this is where OpenLayers really shines - with data tiles, on-the-fly raster styling and raster analysis. In addition to that, we have a team that is very experienced with OpenLayers.

The pull request shows the effort it takes to make raster data work with MapLibre. In OpernLayers, you just use the GeoTIFF source (or GeoZarr), add your desired styles, and are done - including the possibility to interact with the underlying data (get band values etc.).

And finally, since I'm "the OpenLayers guy", I have a strong interest in OpenLayers being used.

That said, I'm not in favor of replacing OpenLayers with MapLibre here.

[m-mohr]

@ahocevar For context, the app is loading the PMTiles very slow in some areas of the map with very dense fields, for example. https://fieldsofthe.world/ftw-inference-app/dev/#map=10.52/84.6538/24.0556/mode:global/threshold:0.3/year:2025

Caleb is saying that his app with MapLibre renders it much faster, thus created a PR for it over the weekend.

Can we improve the situatiuon on the OpenLayers side to render faster?

Personally, I think we should first optimize the PMTiles files because a tile with 10+MB is not a good choice in any case. On slower connections your browser may not freeze up, but the transfer is then the bottleneck and we should also care for this. So I think we should only integrate an additional mapping library (that someone needs to maintain, who's doing it?) if we can't optimize ol/ol-pmtiles/the PMTiles files enough to get it fast enough.

I also don't see any crashes happening with different browsers and computers, it just loads slower for me. That should be improved, no question, but I think the approach should be different than proposed in this PR.

[m-mohr]

I just ran it, and there are a couple of issues with this in comparison to the existing version:

• The agreed switch between COG (aggregated values) + PMTiles (fields) was 10 (on OL), here it changes to the fields later. The data loads faster in MapLibre due to that, it just loads less data (probably level 11, not 10). It seems there's a disparity between MapLibre and OpenLayer with regards what zoom level 10 exactly means. See the screenshot attached, both libraries claim to be at ~10.2x and they switch roughly at that time in both cases, but show significantly different AOIs.
  
  We could also switch to loading the fields later in OpenLayers to improve performance. Is that switch wanted or was that an unintentional side effect? Then this PR should probably be changed to load the data also earlier and we'd have to check what the performance gain is then (if any). (Thanks to @ahocevar in this interesting lecture about zoom levels in mapping libraries.)
• There is no permalink for the view anymore, so sharing specific views is not possible anymore
• A comparison between custom inference run and global predictions is not available any more.
• The geocoding search is missing, no country boundaries, no labels, no switch between years.
• The attribution for the S2 cloudless layer is not correct. We were specifically asked by EOX to correct it according to their TOS, so this is not optional.
• No feedback mechanism.

Not sure whether this PR was meant to be a full replacement already or a draft and was meant to be improved to get the full functionality back. It is not in draft mode, thus not sure.

I think such a big change just two days before release is risky.