Sì. Ora che mi hai passato tutte e 3 le parti, possiamo dividerlo davvero in modo funzionale, senza cambiare il comportamento attuale.

Ti consiglio di non fare semplicemente 3 file da ~500 righe, perché tra poco avrai anche le attività e torneremmo allo stesso problema.

Struttura che farei

public/js/map/
│
├── mapboxMarkers.js          ← ENTRY POINT / API pubblica
│
├── mapboxState.js            ← stato condiviso della mappa
│
├── mapboxUtils.js            ← funzioni comuni
│
├── photoMarkers.js           ← marker foto singole + spiderfy
│
├── photoClusters.js          ← cluster foto HTML + smart zoom
│
├── mapboxSources.js          ← sources/layers Mapbox
│
└── activityMarkers.js        ← attività, da sviluppare

In questo modo avremo una separazione molto più pulita:

File	Responsabilità

mapboxMarkers.js	Facciata/API pubblica
mapboxState.js	mapboxMap, foto, attività, routes, Map dei marker
mapboxUtils.js	distanza, placeholder, funzioni comuni
photoMarkers.js	foto singole e spiderfy
photoClusters.js	cluster fotografici, collage, smart zoom
mapboxSources.js	addSource, addLayer, aggiornamento GeoJSON
activityMarkers.js	nuova gestione attività


E soprattutto eliminiamo una cosa importante

Nel codice che mi hai mandato ci sono due sistemi di cluster HTML:

updatePhotoClusterMarkers()

e

updatePhotoClusterHtmlMarkers()

che fanno sostanzialmente la stessa cosa ma in modo leggermente diverso.

Questo è uno dei motivi per cui il codice sta diventando difficile da mantenere.

Inoltre nella seconda implementazione c'è questa chiamata:

handlePhotoClusterClick(clusterFeature);

mentre la funzione è definita come:

function handlePhotoClusterClick(clusterId, center)

Quindi abbiamo anche una piccola incoerenza che conviene sistemare durante la divisione.

Il pallino blu di Mapbox

La modifica che hai fatto:

"circle-opacity": id === "photos" ? 0 : 0.9,
"circle-stroke-opacity": id === "photos" ? 0 : 1,

la manterrei.

Quindi:

Mapbox continua a creare/renderizzare il cluster;

queryRenderedFeatures() continua a trovarlo;

il cerchio blu di Mapbox non viene mostrato;

sopra ci mettiamo il nostro cluster HTML con le miniature.


Questo è importante perché se rimuoviamo completamente il layer photos-clusters, il sistema di cluster HTML che hai costruito perde il riferimento ai cluster visibili.


---

Punto fondamentale per le attività

Non farei:

if (id === "photos") {
   ...
}

if (id === "activities") {
   ...
}

dappertutto.

Meglio avere un sistema generico:

Mapbox
 ├── Photos
 │    ├── source
 │    ├── clusters
 │    ├── markers
 │    └── spiderfy
 │
 └── Activities
      ├── source
      ├── clusters
      └── markers

Così in futuro possiamo aggiungere, per esempio:

activityMarkers.js
activityClusters.js

senza toccare il sistema delle foto.


---

Quindi la versione finale sarà concettualmente così

// mapboxMarkers.js

import { setMap } from "./mapboxSources.js";
import {
  setPhotos,
  clearPhotos,
} from "./photoMarkers.js";
import {
  setActivities,
  clearActivities,
} from "./activityMarkers.js";
import {
  setRoutes,
} from "./mapboxSources.js";

window.MapboxMarkers = {
  setMap,
  setPhotos,
  setActivities,
  setRoutes,
};

e tutti i dettagli rimangono nei rispettivi moduli.

Non cambierei per ora la logica dei cluster/spiderfy più del necessario. Prima facciamo una separazione 1:1 del comportamento attuale, così non rischiamo di perdere i cluster che finalmente funzionano; poi possiamo migliorare il codice internamente.

L'unica cosa da verificare nel progetto è che questi file vengano caricati come ES modules, cioè con:

<script type="module" src="/js/map/mapboxMarkers.js"></script>

Se il tuo progetto è già impostato così, possiamo procedere direttamente con questa struttura.