For example, the currently selected object on the map. It is not clear how to separate changes to Map Data objects and changes to the selected element. It is necessary to track changes in the active element, otherwise at least the Edit button will break.

addObject/removeObject in leaflet.map.js could fire some event for active object change. The listener that calls updateLinks could listen to that event.

I also saw a problem in PR: when you click the Map Data checkbox, the cookie with the current location is no longer updated

Okay, firing events from addObject / removeObject turned out to be the best idea. And I changed this PR to use baselayerchange/overlaylayerchange

I also replaced map.on("layeradd",...), which tracks the layer's on/off state with dataLayer.on("add", ...). Using overlaylayerchange in this case doesn't work, because this event isn't thrown when opening a new page with ...&layers=D Plus add / remove looks cleaner in my opinion.

With the latest changes I was able to render Lake Huron locally in a reasonable amount of time (<20s, including 4.5s API response time; 455k nodes). Also map data display is extremely fast now (e.g. 100ms instead of 3s). That is definitely a significant speed-up.

Ideas for follow up PRs:

Furthermore, switching from XML to JSON has improved the response time from 20s to 8s (both values include 4.5s API time). For reference, I've uploaded the quick hack here: https://gist.github.com/mmd-osm/d45ff3b4f41908b1c075d70d1b6fdebe (edit: added fetch based + error handling alternative).

We should think about adding some error handling:

Jquery uses JSON.parse for parsing of ajax() result.

In a next step switching to fetch would allow using
https://developer.mozilla.org/en-US/docs/Web/API/Response/json
Where the parsing is done without blocking the main thread.

We probably need to fire baselayerchange either from map.setState or from map.updateLayers. Otherwise if you edit &layers=X in the location bar, share urls are updated to its previous value.

If we follow the same principles as leaflet.layers.js, baselayerchange should be fired by the same function that does map.addLayer, so I guess map.updateLayers should fire it.

Otherwise if you edit &layers=X in the location bar, share urls are updated to its previous value.

Do I understand correctly that you are talking about the current behavior of the website, and not after PR? At least in Firefox, changing &layers=X does not change the layers on the map, only if you open in a new tab

@AntonKhorev 's comment wasn't exactly clear to me either. I think it's the following. Note that once you change the layer in the URL (in the example below from "C" to "H"), the share link "layer" attribute is updated accordingly:

This doesn't seem to work anymore with the changes in this PR.

Besides, there may be some timing issue in the current code, as the behavior is not 100% reproducible for me, even today. Sometimes the map layer changes along with the share link, in other cases, the old layer is still shown.

Ah, I understand. I only tested changing the letters that represent the overlay (D/N/G). Changing the letters that respond to tile layers works now. PR broke it. I'll try to fix it

Leaflet ships with a layers control which lets you switch between layers. That thing is responsible for firing baselayerchange events. We don't use this control because we have our own layers menu. Therefore we're responsible for firing that event, which we do:

The problem is that our layers menu is not the only thing that can switch layers. All other places where layer change happens need also to fire baselayerchange. I think that map.updateLayers is the only such place. Lack of baselayerchange there becomes more noticeable with this PR because it uses this event.

Similar story with overlaylayerchange, although it's not a standard Leaflet event. Leaflet layers controluses overlayadd and overlayremove.