I'm asking the CAI for clarification, I'll let you know.

you said "probably maintained by 'Club Alpino Italiano', but that's not the case. 401b is not known to the CAI, perhaps it once existed and was decommissioned, in any case it is not currently a CAI trail.

rimossa relazione route=canyoning (schema draft non approvato wiki.osm.org/wiki/Proposal:Canyoning) con name inventato e non verificabile (wiki.osm.org/wiki/Verifiability). Mantenute le way idrografiche originali.

rimossa relazione route=canyoning (schema draft non approvato wiki.osm.org/wiki/Proposal:Canyoning) con name inventato e non verificabile (wiki.osm.org/wiki/Verifiability). Mantenute le way idrografiche originali.

Ciao Alessandro, ho ripristinato la toponomastica standard sia sui nodi dei centri abitati che sulle relazioni dei confini amministrativi. Come indicato nelle linee guida per il FVG (osm.wiki/Multilingual_names#Friuli-Venezia_Giulia), per il friulano si usano i tag dedicati (name:fur)=*. L'uso delle barre nel tag name generale altera sia la pronuncia dei navigatori sui nodi, sia il geocoding (Nominatim) sui confini. I toponimi friulani restano tutti correttamente mappati in name:fur. Se vuoi approfondire o proporre modifiche alle linee guida, parliamone sul forum italiano.

Thanks for checking and explaining the local context.

My point was mostly about avoiding tag duplication if the way gets split in the future, as keeping operator on the relation is usually cleaner. But if you think the current setup makes the most sense right now, it's completely fine with me too!

I don't know exactly what the real situation is on the ground, but I would have created another "relation" and then set the operator tag to the "relation". Doing so doesn't cause any conflict.

The value of the "operator" tag on the "way" conflicts with the value of the "operator" tag on the "relation"

Hi, you broke the relation/13758524, now it has "gaps"

Ciao, la way che hai eliminato non esiste o è stata cancellata dalla vegetazione o da una frana?

Thanks for the reply, but this still doesn't address my technical observations

Ok, non saprei come mappare al meglio un percorso che viene tabellato solo in inverno. Fai tu come ritieni giusto, non ho consigli validi da darti.
Buon mapping.

Potrebbe essere una ipotesi valida, anche se mi sembra strana che facciano una cosa del genere. Se è così non saprei come gestire la stagionalità. Ma mi incuriosisce un altro aspetto: sono sicuro di essere passato davanti al cartello mostrato in mapillary e mi pare strano non averlo notato e quindi la tua ipotesi sembrerebbe valida. Se vedi nella stessa foto, a destra (semi nascosti), ci sono 2 cartelli di cui 1 riporta "Forest Sound Track". Comunque, non ho capito: tu hai visto cartelli "Saisera Wild Track” lungo tutto il percorso?

Ciao, ho percorso alcuni tratti del percorso che alla fine hai chiamato “Saisera Wild Track”, ma non ho visto cartelli con quel nome, mentre ho visto altri cartelli e più spesso cartelli "Forest Sound Track". Da dove hai tratto il nome “Saisera Wild Track”?

Non so se ci siamo capiti: tu punti più sul fatto che ci sono nuove tracce e che è da vedere se path o track e su questo tu hai una conoscenza migliore della mia perché il mio ultimo sopraluogo credo che sia stato almeno 2 anni fa'. Ma il problema che ho notato è riferito solo alla "rottura" delle relation, nel senso che prima 2 o 3 sentieri passavano di lì e dopo la tua modifica risultano "rotti" nel senso che non sono più lineari e presentano dei "baffi". Secondo me la cosa migliore è eliminare i "baffi" e riportare ile relation allo stato originale. Se ci sono nuovi track o variazioni dei path, questo di solito non dovrebbe intaccare l'integrità delle relation. Non so se sono riuscito ad essere chiaro.

Ciao, la tua modifica ha "rotto" almeno 2 relation, nel senso che adesso le relation non sono più lineari e presentano dei "gaps". Visato che usi un editor evoluto (JOSM) ci sono degli strumenti molto utili per gestire le relation. Non so se li conosci, se non li conosci ti posso dare una mano. In ogni caso la situazione va' sistemata, fammi sapere quando vorrai intervenire. Ciao e buon mapping.

Ciao Alessandro. Ho ripristinato il tag name corretto, dato che le quattro varianti linguistiche erano (e sono) già mappate correttamente nei rispettivi tag ISO dedicati (name:fur, name:sl, name:de).

Capisco lo spirito del progetto con ARLeF/NPLD, ma duplicare i toponimi accumulandoli nel tag name principale separati da slash viola le linee guida fondamentali di OpenStreetMap (vedi pagine Wiki Key:name e Names in multilingual areas).

Il tag name deve contenere esclusivamente il toponimo locale primario basato sulla segnaletica fisica presente sul posto (principio del Ground Truth). Inserire stringhe multilingua composite nel tag principale compromette il rendering della mappa ed è considerata una bad practice, specialmente quando i dati linguistici sono già presenti e strutturati nei tag corretti.

Ti invito a non ripetere questo tipo di inserimenti cumulativi e a utilizzare esclusivamente i tag di localizzazione linguistica per dare visibilità alle minoranze. Grazie per la collaborazione e buon mapping.

Ciao Ivan, ho dato un'occhiata alla sezione del sito (https://www.refuges.info/nav/3278/pays/Italia/) e vedo che la copertura dei rifugi italiani è davvero minima e frammentaria. Tra l'altro, il layer (https://maps.refuges.info/hiking/{z}/{x}/{y}.png) visualizza già correttamente i punti d'appoggio leggendo direttamente i tag standard di OSM. Mi chiedo quindi quale sia l'effettiva utilità di inserire un tag proprietario, non internazionale e non riconosciuto dai validatori di JOSM, quando l'interoperabilità tra i due sistemi esiste già grazie ai tag nativi. Non rischiamo solo di appesantire i dati con chiavi non standard?

dimenticavo: JOSM lo segna come tag sconosciuto o qualcosa del genere

Ok, grazie, ma non dovrebbe esserci una wiki in inglese o in italiano?