IT talk:CAI
Profilo altimetrico
Un popolare servizio online Waymarkedtrails può rappresentare graficamente il profilo altimentrico del percorso. Condizione perchè nei dettagli sia visualizzato è che il percorso non abbia rami e che abbia nei membri iniziale e finale della relazione il ruolo "start" e "goal", analogamente a quanto di può fare per la relazione "From" e "to".
--Cascafico (talk) 10:06, 30 March 2017 (UTC)
Inserire i PDI prossimi
Ho fatto questa query [1] che potrebbe essere utile per evidenziare i PUnti Di Interesse (PDI) inseribili nella relazione del sentiero. I valori di prossimità (around) sono arbitrari. Chi vuole provarla deve reperire l'id della relazione rapidamente sul sito waymarked trails [2]
[1] http://overpass-turbo.eu/s/pKx [2] https://hiking.waymarkedtrails.org/
--Cascafico (talk) 09:39, 14 June 2017 (UTC)
Rifugi/bivacchi
Non mi e' chiara una cosa: quando si parla di rifugi gestiti da inserire nelle relazioni del sentiero si intende solo quelli gestiti dal CAI, giusto? E per quanto ri guarda i non gestiti/bivacchi vari? Si possono aggiungere tutti quelli presenti sul sentiero?
--Gabrielesani (talk) 07:44, 25 October 2018 (UTC)
state (closed / alternate / temporary)
Come ho già segnalato nella malinglist la key state=closed non è contemplata in OSM. Tra le varie key disponibili per segnalare un percorso che si è dovuto chiudere con una ordinanza sindacale, protezione civile, CAI o altro ente preposto alla gestione e/o manutenzione (ad es. ferrata in manutenzione, pericolo idrogeologico, ecc.) si può fare ricorso ad altre key ad es. Key:locked o la più generica access. Considerato l'importante di questa infromazione, a mio avviso è necessario porla tra quelle obbligatorie e sostituire state=closed (riportato anche nella pagina Hiking utilizzando al suo posto un'altra key. --Dino Michelini (talk) 09:42, 4 December 2020 (UTC)
name di un percorso
Nella tabella dove sono riportati i tag per costruire la route hiking CAI credo che l'esempio riportato per "name" sia un refuso delle prime versioni della pagina. Infatti, nella spiegazione si scrive «Il nome del percorso, se è noto, NON deve essere abbreviato. Se non ha un nome come “Sentiero degli Alpini” non si compila il tag. Il percorso è comunque già definito dal suo ref. (È convenzione in alcune regioni di assegnare un nome in base ai toponimi locali; ma questa pratica non può essere presa come una raccomandazione generica e viene svolta solo da chi collabora con i catasti regionali)».
L'esempio della tabella riporta le località salienti del percorso che sono già presenti in from e to (quindi risultano dal punto di vista informatico come dato ridondante nel data base) ed è in contrasto con quando scritto nella spiegazione. Pertanto, l'esempio è fuorviante e genera confusione. Per chiarire l'ambiguità presente propongo di modificare l'esempio in:
| name | Sentiero Frassati (corretto)
Varese Ligure - Passo Chiapparino - La Pelosa (errato) |
--Dino Michelini (talk) 16:59, 25 January 2021 (UTC)
Forse mettere errato e' esagerato, perche' come dice sopra non e' una raccomandazione generale ma non e' neanche un errore. Concordo comunque sul fatto che l'esempio sia fuorviante --Gabrielesani (talk) 13:38, 26 January 2021 (UTC)
- Non sono d'accordo nella interpretazione che dai. Il passo a cui fai riferimento si riferisce alla pratica del sostituire il nome del percorsoVedi nomi propri su enciclopedia Treccani con dei toponimi solo in certi catasti regionali (quali?); infatti si scrive che questa pratica (sostituire il nome con i toponimi) non può essere presa come una raccomandazione generica e viene svolta solo da chi collabora con i catasti regionali e poiché OSM non è un catasto né regionale/nazionale, né personale, non si comprende l'esempio se non ipotizzando che si sia commesso un refuso sfuggito fino ad ora.
- La regola, quindi, rimane quella scritta in premessa: se il percorso ha un nome lo si aggiunge al name, altrimenti lo si omette. Anche waymarkedtrails.org segue questa regola, leggendo e visualizzando i tag name, ref, from, to; quindi, se manca nella route ad es. il name visualizza from - to, o in loro assenza il ref, oppure, nulla, ma se la route ha il name correttamente valorizzato secondo la regola omette il from - to.
- Dal punto di vista tecnico, inserire manualmente il name costruito su from-to non ha alcuna ragione di esistere e non porta nessun vantaggio, anzi, oltre a contraddire la regola sulla ridondanza dei data base, farebbe fare del lavoro (poco) inutile al mapper. La proposta di correggere l’errore presente nell’esempio mi sembra valida perché bene evidenzia come il name non può essere sostituito da nomi di località from - to. --Dino Michelini (talk) 17:47, 29 January 2021 (UTC)
Percorsi escursionistici a tappe
Oltre ai classici percorsi CAI di limitato chilometraggio e che si possono percorrere nell’arco di poche ore esistono anche percorsi a lungo percorrenza che si sviluppano quindi in più tappe e più giorni come l’Alta Via n. 1 della Valle d'Aosta, il Sentiero Italia, la Grande Traversata delle Alpi solo per fare alcuni esempi. Attualmente nel paragrafo Percorsi escursionistici si dà per scontato che quanto riportato sia sufficiente alla loro mappatura e per questo non si citano questi trekking non proponendo schemi di realizzazione delle route. Per questo non è chiaro come si debba mappare questi percorsi che hanno un numero di route avvolte notevole da gestire; gli esempi citati sostanzialmente adottano soluzioni simili ma non essendo codificate presentano risultati non standardizzati e soddisfacenti.
Rispetto al singolo percorso escursionistico di un giorno la differenza fondamentale nella gestione delle numerose route consiste nel dover individuare in modo univoco e ordinato la singola tappa all’interno della superroute o route di modo che ad es. sia possibile al sito waymarkedtrails.org costruire automaticamente e correttamente i dati relativi alla distanza e al profilo altimetrico (ascesa e discesa), produrre i file gps e kml. La soluzione di fatto escogitata e adottata consiste nell’inserire nel nome della route oltre al nome (del trekking, cammino, percorso) anche il numero della tappa. Ovviamente sul come fare ciò si demanda alla “libera interpretazione” del mappatore, con evidenti conseguenze del caso: ad es. nel S.I. il name della tappa viene costruito in un certo modo ad es. Sentiero Italia(relation 1021025)-> (SI A00) Sentiero Italia - Friuli Venezia Giulia(relation 7332771)-> (SI A01) Bivio Rifugio Calvi – Rifugio(relation 6925687), nel caso della Alta Via n. 1 si ha uno schema simile ma diverso Alta Via n. 1 della Valle d'Aosta(relation 1706143)-> Alta Via n. 1 della Valle d'Aosta - Tappa 1](relation 9630569).
Altro argomento non trattato chiaramente è come assegnare il livello di network rispettivamente alle varie route. Poiché questi percorsi sono organizzati a tappe e con più route organizzate su più livelli non si esplicita bene quale network vada assegnato ad es. alla route di ogni singola tappa, alla route del livello regionale, nazionale o internazionale. Per l’assenza standard discussi e condivisi sulla wiki la casistica è varia, si va dalla singola tappa locale (SI E01) Garessio - Ormea relation 7569936) del S.I. ora con network=nwn mentre alla versione #16 era lwn ma la route regionale (SI E00) Sentiero Italia – Piemonte ([https://www.openstreetmap.org/relation/7029511/history relation 7029511), ad eccezione della prima versione di 4 anni fai, ha sempre avuto network=rwn. Purtroppo, la pagina CAI non fornisce informazioni dedicate sull’argomento mentre sarebbe utile inserire esempi significativi di come costruire le varie route ed assegnare correttamente i valori ai tag. --Dino Michelini (talk) 13:28, 22 February 2021 (UTC)
Tag doppio che fa confusione
Faccio presente che esiste già il tag https://wiki.openstreetmap.org/wiki/Key:source_ref scritto con l'underscore, invece che col due punti. Penso che ciò possa provocare fraintendimenti. Proporrei di cambiarlo in un qualcosa che non richiami la "sorgente" bensì il manutentore.
Ciao,
Secondo me sono "sbagliati" entrambi perché: 1. source_ref sarebbe: Used to link external source of information: photos, video links 2. source:ref senza source=* è privo di significato. Ho visto che alcuni hanno già usato "source_ref" (forse l'editor ha corretto il tag?). Valuterei di creare un tag apposta, ref:IT:CAI=* con una pagina wiki che spiega di cosa si tratta e come ricavarlo (ed eventualmente usarlo) oppure se non è necessario, il tag ref=* può già bastare.Francians (talk) 05:44, 24 April 2021 (UTC)
source:ref=*dovrebbe indicare la fonte della proprietà ref. Vedi Key:source#Multiple_source_tags_.28historic.29 --AnyFile (talk) 08:24, 2 June 2021 (UTC)- Inoltre cosa significa la spiegazione?
Se è chi gestisce la cosa allora andrebbe in operator. Qui siamo forse nel caso in cui il sentiero è di proprietà e viene gestito dal comune/provincia/ecc, ma il percorso e i cartelli dal CAI? --AnyFile (talk) 08:28, 2 June 2021 (UTC)Il codice della sezione che monitora la situazione di quel determinato percorso
Unità di misura in destination
Nella sezione Luoghi di posa, dove si parla di destination leggo:
Nel caso di tabelle di tipo nuovo dove siano indicati anche le distanze, riportare i valori con la lettere h davanti alle ore e la dicitura km davanti alle distanze, separate da una virgola.
Mettere h e km davanti al numero ha poco senso. Le regole sulle unità di misura dicono che vanno messi dopo il numero, non prima. Capisco che bisogna scrivere quello che c'è scritto sul cartello, ma almeno non scriviamo qui come regola generale che le unità di misura vanno scritte prima (e soprattutto spero che sui cartelli siano scritte nel punto corretto, cioè dopo) --AnyFile (talk) 16:45, 30 July 2021 (UTC)
I understood that h or km are prefix used by computer to decode distance or duration.
But data are messy. Some example from this overpass query:
--Pyrog (talk) 11:29, 12 December 2021 (UTC)
Proposta modifica preset "Sedi"
Ciao, vorrei suggerire una modifica al preset delle sedi che svecchi il tagging rispecchiando maggiormente quello attuale. Propongo di modificare il suggerimento di: name=Club Alpino Italiano sezione Viterbo con name=Club Alpino Italiano + branch=Sezione Viterbo e inoltre di cancellare il seguente suggerimento: addr:country=IT --Ivanbranco (talk) 17:18, 26 October 2022 (UTC)
Analizzando i dati relativi ai luoghi di posa, ho riscontrato numerosi casi simili a questo:
https://www.openstreetmap.org/node/12339994587
Di seguito i tag principali:
tourim=information
information=guidepost
destination=H24;Zambla Bassa 0.50;Zambla Alta 1.20|H30;Cappella Forcella 0.50;Zorzone 1.10;Plassa -Arera 1.40
image=https://commons.wikimedia.org/wiki/File:20241031-val_vedra_fondovalle-060.jpg
Dall'immagine risulta evidente che vi sono due cartelli distinti (indicanti la stessa direzione), i cui contenuti sono stati correttamente separati con il carattere pipe | nel tag destination=*.
Tuttavia, come prima "destinazione" in ciascun gruppo è stato inserito il ref dell'itinerario (es. H24, H30), trattandolo come se fosse una località raggiungibile. A mio avviso, questi riferimenti andrebbero piuttosto separati in un tag specifico:
destination:ref=H24|H30
Considerando che per i luoghi di posa si è scelto uno schema ispirato a quello delle lanes, dove le "corsie" sono separate da pipe | e le destinazioni da punto e virgola ;, appare naturale estendere l'uso di questo modello anche ai tag nel namespace destination:*, come destination:ref (o destination:symbol).
A supporto, cito un esempio di tagging per destination:ref:lanes dalla seguente pagina:
In quel caso, la cartellonistica indica che tutte le direzioni condividono il riferimento B 27, mentre le prime due hanno anche B 243, ed è stato mappato così:
destination:ref:lanes=B 27;B 243|B 27;B 243|B 27
Inoltre, esiste già un esempio avanzato anche con i segnavia che combina ref e symbol all'interno del namespace direction_*, come mostrato qui:
https://wiki.openstreetmap.org/wiki/Key:direction_north#Example
Proposta operativa:
Se non ci sono obiezioni, vorrei estendere la pagina CAI per documentare anche questi tag opzionali (destination:ref, eventualmente anche destination:symbol), e in seguito procedere ad aggiornare ove possibile i dati già caricati su OSM.
--Francians (talk) 05:04, 11 June 2025 (UTC)
- Sono l'autore del cartello che usi come esempio. Ho utilizzato quella notazione per il tag destination= perché descrive in modo preciso e completo il contenuto del cartello stesso. In pratica, è possibile ricostruirne l'aspetto esatto a partire dai dati.
La proposta che fai perde la correlazione tra i ref e le destinazioni, poiché vengono separati in due tag distinti. Ad esempio, non sarebbe più chiaro che "H24" si riferisce esclusivamente alle destinazioni "Zambla Alta/Bassa" e non alle altre. Si potrebbe pensare a un formato alternativo che mantenga questa correlazione tra i due tag e gestisca anche casi più complessi (come combinazioni di cartelli con riferimenti singoli, multipli o assenti), ma così facendo si perderebbe l’immediatezza e la chiarezza dell’attuale utilizzo del campo destination. Inoltre, questo nuovo formato risulterebbe più difficile da mantenere per chi non conosce la struttura originale. Pensa al caso in cui venga aggiunto/rimosso un nuovo cartello e un utente modifichi il campo destination senza aggiornare il relativo ref.
Considera inoltre che è già diffuso l’uso di inserire il guidepost all’interno delle relazioni dei rispettivi ref. Il campo destination:ref che proponi sarebbe quindi, un duplicato di questa informazione.
Alla fine, mi sono semplicemente attenuto alla linea guida che suggerisce di riportare nel campo destination ciò che è effettivamente scritto sul cartello, evitando di omettere informazioni sulla base di un’interpretazione soggettiva di cosa sia o meno una destinazione. Tra l'altro, anche il ref potrebbe essere considerato una destinazione dal punto di vista di un escursionista che intende seguire un determinato sentiero identificato da quel riferimento.
--Amadvance (talk) 07:10, 11 June 2025 (UTC)
- Grazie per la risposta dettagliata - condivido molti dei tuoi punti, in particolare il principio di mappare fedelmente ciò che si vede sul cartello.
- Vorrei però chiarire un aspetto tecnico importante: la separazione dei tag destination=* e destination:ref=* non comporta la perdita di alcuna informazione, se si mantiene la corrispondenza tra le "corsie" tramite il separatore |. Proprio come nel caso del tagging *lanes, la posizione degli elementi in ciascun gruppo (separati da |) mantiene l’associazione tra il riferimento del sentiero e le destinazioni elencate.
- Nel caso in esame, i due cartelli indicano:
- destination=H24;Zambla Bassa 0.50;Zambla Alta 1.20|H30;Cappella Forcella 0.50;Zorzone 1.10;Plassa -Arera 1.40
- che, nella mia proposta, diventerebbe:
- destination=Zambla Bassa 0.50;Zambla Alta 1.20|Cappella Forcella 0.50;Zorzone 1.10;Plassa -Arera 1.40
- destination:ref=H24|H30
- L’associazione tra ref e destinazioni rimane perfettamente leggibile e persino più strutturata, favorendo l’elaborazione automatica (per stili, routing, query, ecc.).
- Infine, capisco che per l’escursionista il ref sia percepito come destinazione — ma da un punto di vista formale è un identificativo di percorso, non un luogo fisico. Per questo proporre un campo dedicato come destination:ref=* può aiutare a distinguere le due nature, pur conservandole entrambe.
- In sintesi, non propongo di rimuovere o sostituire l’attuale uso di destination=*, ma solo di documentare la possibilità di usare (in aggiunta e in coerenza) anche destination:ref=*, per chi desidera strutturare meglio l’informazione senza perdere nulla della realtà sul terreno.
- Concordo che sia possibile mappare con un formalismo adeguato, ma spero converrai con me che avere due tag da mantenere sincronizzati sia più complicato e meno intuitivo. Pensa ai casi con cartelli che riportano più riferimenti o nessuno: bisognerebbe separare i riferimenti con ; nei casi con più ref, e usare || per indicare i cartelli senza ref. È troppo facile commettere errori nel sincronismo trai i due tag, e impossibile da intuire se non si conosce il formalismo. Pensa al caso di un utente che voglia aggiornare un guidepost: è molto probabile che modifichi solo il tag destination, dimenticando l’altro.
- Posso condividere la mia esperienza di mappatore, avendo mappato migliaia di guidepost, e posso dirti che la semplicità di comprensione, inserimento e modifica dei tag è un aspetto fondamentale. Complicare questi aspetti è deleterio per l’inserimento e la correttezza delle informazioni.
- Considera che esiste già un metodo per mappare con precisione queste informazioni: le relazioni destination_sign, che già prevedono un tag destination:ref. Tuttavia, sono poco utilizzate proprio perché più complesse. Ora, introdurre un ulteriore formalismo di mappatura mi sembra controproducente.
- Per quanto riguarda la questione se un ref sia o meno una destinazione, è una considerazione soggettiva che dipende dal punto di vista da cui la si analizza. Invece, ciò che è scritto sul cartello è un fatto oggettivo. Ti faccio un altro esempio: ci sono cartelli con forma di freccia che indicano solo il nome del sentiero, come "Via Mercatorum". Il nome del sentiero è una destinazione oppure no? E se sul cartello c’è scritto solo quello, dovremmo lasciare il campo destination vuoto? Esistono una miriade di casi simili, e la soluzione più ovvia è semplicemente inserire ciò che è scritto sul cartello.
--Amadvance (talk) 12:13, 11 June 2025 (UTC)
- Grazie per la risposta articolata, però vorrei chiarire due punti importanti:
- 1. Il namespace destination:* (in particolare destination:ref=*) non è un'invenzione mia.
- La mia intenzione è solo di documentare questa possibilità anche nella pagina CAI, con un esempio d’uso.
- 2. La wiki attuale non impone l’inclusione dei ref nel campo destination=*.
- Il testo dice:
- "Le informazioni sui luoghi da raggiungere con i tempi di percorrenza e/o le distanze laddove indicate. Ogni destinazione inserita all'interno di una freccia deve essere separata da punto e virgola (;), la successiva freccia deve essere separata dalla prima con un "pipe" (|). Si deve riportare quello che è scritto sulla tabella senza aggiungere altro."
- Non viene fatta alcuna menzione esplicita ai ref. La frase “si deve riportare quello che è scritto sulla tabella” può essere intesa in più modi: c’è chi ci include i ref come destinazioni e chi, invece, li separa trattandoli come dati di contesto. Entrambe le interpretazioni sono plausibili, ma nessuna delle due è attualmente normata - il che rafforza la necessità di definire esempi condivisi.
- --Francians (talk) 17:23, 11 June 2025 (UTC)
- Il campo destination:ref è già utilizzato, ma non sui nodi. Anzi, la documentazone ufficiale dice espressamente di non usarlo in quel contesto. Vedi la pagina https://wiki.openstreetmap.org/wiki/Key%3Adestination%3Aref dove dice "Used on these elements". Il caso del nodo è marcato con la barra rossa e dice "should not be used on nodes".
- --Amadvance (talk) 20:49, 11 June 2025 (UTC)
- Hai perfettamente ragione nel dire che nella pagina Key:destination:ref i nodi sono attualmente indicati come should not be used.
- Tuttavia, vorrei segnalare un contesto importante che spiega questa apparente incongruenza.
- Quella pagina deriva direttamente dalla proposta originale del 2012: https://wiki.openstreetmap.org/wiki/Proposal:Destination_details
- che era specificamente pensata per gli svincoli stradali, e non contemplava l’uso del namespace destination:* nei guidepost o in contesti escursionistici.
- Dal 2017 è stato aggiunto nella pagina Key:destination un riferimento esplicito all’uso del tag anche per i segnavia: https://wiki.openstreetmap.org/w/index.php?title=Key%3Adestination&diff=1512025&oldid=1431488
- Solo nel 2021, il pannello laterale della stessa pagina è stato aggiornato per abilitare esplicitamente l’uso su nodi, riflettendo il fatto che il tagging su guidepost era ormai una pratica diffusa: https://wiki.openstreetmap.org/w/index.php?title=Key:destination&diff=prev&oldid=2216526
- Infine, oggi destination:ref=* risulta utilizzato oltre 1.400 volte su nodi, come indicato da Taginfo.
- Tutto questo fa pensare che il divieto attuale should not be used on nodes nella pagina destination:ref sia un retaggio non aggiornato della proposta originaria e non tenga conto dell’evoluzione reale del tagging nei contesti escursionistici.
- Un conto è modificare la documentazione per descrivere uno standard de facto, come è stato fatto per destination; un altro è proporre una modifica che orienti il mapping futuro.
- Non basta semplicemente rimuovere il divieto di usare destination:ref sui nodi: è necessario anche spiegare perché farlo e come usarlo.
- Attualmente, però, esistono solo 57 nodi con information=guidepost e destination:ref=*, e non si può certo considerare questo uno standard de facto.
- Ribadisco che esistono già tre metodi alternativi alla proposta in questione:
- L’uso del tag destination sul nodo guidepost.
- L’inserimento del guidepost nella relazione di tipo route identificata dal ref.
- L’uso delle relazioni destination_sign, già concepite per modellare in dettaglio i cartelli.
- Non vedo la necessità di introdurre un quarto metodo, soprattutto considerando che questo richiederebbe una sincronizzazione manuale tra i valori dei tag destination e destination:ref, operazione che introduce ambiguità, fragilità e ridondanza, e che, a quanto mi risulta, non ha equivalenti nel modello dati di OpenStreetMap.
- Questa necessità di sincronizzare le informazioni per rappresentare correttamente i cartelli è un limite fondamentale della proposta. Situazioni simili vengono risolte tramite relazioni che legano i dati, e infatti le destination_sign esistono proprio per assegnare attributi specifici ai cartelli, lasciando il nodo guidepost più semplice.
- Se invece si rinuncia a mantenere sincronizzati destination e destination:ref, allora la proposta è equivalente all’inserimento del guidepost nella relazione dei sentieri, che è già una prassi consolidata.
- A mio parere, questi sono limiti oggettivi che bloccano l’adozione della proposta così com’è formulata. Se vuoi comunque procedere, è necessario avviare una discussione nei canali ufficiali e raccogliere un consenso chiaro della comunità.
- 1. Sono perfettamente d'accordo che ogni modifica strutturale vada discussa nei canali della comunità. In questo caso, però, sto solo proponendo di aggiungere esempi per documentare come alcuni mappatori affrontano situazioni in cui – come è evidente – non esiste ancora un accordo comune.
- Il medesimo caso era anche stato menzionato su WeeklyOSM: https://weeklyosm.eu/it/archives/4504
- Purtroppo però senza essere riportato nella wiki.
- 2. Ti faccio notare che anche tu applichi un criterio interpretativo: ad esempio nel tuo caso non hai inserito “Via dei Mulini” o “con sentiero H25” nel tag destination=*, pur essendo scritti sul cartello.
- Questo dimostra che già oggi si seleziona cosa riportare e cosa no, quindi discutere come farlo in modo coerente non è una forzatura, ma un chiarimento utile a tutti.
- --Francians (talk) 17:08, 12 June 2025 (UTC)
- Inserire un esempio del genere nella documentazione equivale a presentarlo come un metodo di mappatura ufficialmente approvato. I mappatori utilizzano infatti gli esempi nella documentazione proprio per capire cosa è consigliabile fare o evitare. Tuttavia, al momento ci sono solo 57 utilizzi di destination:ref su nodi con information=guidepost in tutto il mondo. Non si tratta quindi di una pratica de facto, ma di un nuovo metodo di mappatura non pre-esistente.
- Per fare un controesempio, esistono 47978 guidepost inclusi in relazioni route=hiking che hanno anche un ref, questa sì che può essere considerata una pratica de facto, che va documentata su come indicare i ref utilizzati in un guidepost.
- Il blog post da te citato è antico, di ben 10 anni fa. Evidentemente quella pratica non ha preso piede e non è stata approvata ufficialmente. Inoltre, non tratta il caso di più ref, e quindi è differente da quello che stai proponendo.
- Per quanto riguarda il cartello con la dicitura H25, è possibile che io abbia commesso un errore nella mappatura, o semplicemente ne avessi mappati molti in quel giorno. Correzioni sono sempre ben accette. Inserisco sempre l’immagine proprio per offrire un riferimento verificabile. Non ho intenzione di forzare nuovi schemi di mappatura.
- Ti invito a continuare la discussione nei canali ufficiali, in modo da raccogliere ulteriori pareri e portare avanti il confronto in modo più produttivo. Continuare qui non sembra portare a una conclusione condivisa.
- Capisco la tua posizione e ci tengo a dire che non era un'accusa, ma un modo per evidenziare che, anche nel tuo caso, c’è una selezione delle informazioni presenti sul cartello. È normale e condivisibile, ma ribadisco la necessità di formalizzare esempi concreti su cosa è corretto riportare e dove.
- Quanto al canale: la wiki è uno spazio ufficiale di discussione. Se avessi iniziato da una mailing list internazionale, mi sarebbe stato detto che il contesto CAI va discusso qui :)