IT talk:CAI

From OpenStreetMap Wiki
Jump to navigation Jump to search

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?

Il codice della sezione che monitora la situazione di quel determinato percorso

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)

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)