[Talk-it-cai] Commenti vari sul Wiki "CAI"

Alfredo Gattai alfredo.gattai at gmail.com
Thu Nov 1 12:00:04 UTC 2018


Ciao Volker,

nessuna noia ci mancherebbe, vedi sotto:


> trovo scritto nella riga "symbol": "... ad esempio “non segnalato” ..."
> C'è il tag trailblazed=yes|no per indicare la presenza o assenza di
> segnaletica.
>

La scelta e' ricaduta su l'uso semplice di symbol perche' trailblazed e'
"proposed", non e' alternativo a symbol e servirebbe per dare una risposta
binaria si/no.
Vedo che e' applicato molto sulle way e praticamente mai sulle relation.
Con symbol puoi specificare con parole il tipo di simbolo (quindi piu'
specifico di trailblazed) e se non c'e' segnaletica si mette "non
segnalato". Alla fine e' piu' semplice e da l'informazione che serve.


Attenzione: secondo le convenzioni OSM una route relation del tipo "hiking"
> dovrebbe sempre descrivere un sentiero con segnaletica, o con segnaletica
> prevista (con "state=proposed" e "trailblazed=no").
>
Il tag trailblazed=no su una relazione senza "state=proposed"  fa senso
> solo su singoli ways nel caso che mancha la segnaletica su un pezzo del
> sentiero che, per il resto, dispone di segnaletica
>

Tralasciando trailblazed per quanto scritto sopra, i percorsi a cui e'
stato dato un numero ma non sono ancora segnalati non sono proposti, sono
veri percorsi a volte riportati su cartine escursionistiche ma che non
hanno ancora la segnaletica o e' talmente fatiscente da considerarsi nulla.
Ovviamente non e' che chiunque puo' creare relazioni a caso, abbiamo
deviato dalla regola standard solo per qui mappatori CAI che hanno
sottomano il catasto dei percorsi e sono a conoscenza di tali dati. Il
vantaggio di questo approccio e' che si da l'informazione dell'esistenza di
un percorso, si da l'informazione che quel percorso ha in effetti un numero
e si e' gia' rivelato utile in casi di soccorso perche' chi usava
applicazioni che renderizzano le relazioni ha potuto farne uso accelerando
gli interventi. Ad esempio Osmand ed ora anche GeoresQ mostrano
correttamente queste informazioni.


>
> nelle righe "ascent" e "descent" è scritto
> " Per I dislivelli si possono inserire inizialmente quelli calcolati ma
> alla prima occasione vanno validati con un rilievo "
> Il problema di questo è che in realtà il risultato di un rilievo, non è un
> valore di dislivello in salita|discesa, ma una serie di misure rilevate con
> un GPS, prese ad intervalli fissi o di tempo o di distanza. Ad ogni punto
> viene misurata la posizione long/lat e, possibilmente la quota. Se si
> misura solo long/lat,la quota viene calcolato utilizzando delle tabelle,
> cui prcisione dipende dal prezzo che costa l'accesso (quello non a
> pagamento sono di bassa risoluzione spaziale, e bassa precisione
> verticale).  La conversione di questi valori in un valore di salita o
> discesa dipende drammaticamente dal intervallo, dalla qualità dei dati per
> la quota, e dal algoritmo di interpolazione. La stessa traccia GPX può dare
> risultati molto diversi, secondo il metodo di calcolo (anche divergenze di
> più di 50%). Per quello un rilievo con metodi amatoriali (cioè un Garmin
> "normale) deve essere preso colle pinze. Se è disponibile un valore
> rilevato da un topografo professionale, avrei più fiducia nella sua misura
> che nelle mia.
>

Argomento gia' dibattuto in passato. E' assodato che un GPS portatile od
uno smartphone non danno risultati precisi in termini di altitudine e
quindi il GPX risultante non puo' essere preciso. Detto questo
l'informazione che se ne ricava e' sufficientemente precisa per dare il
giusto ordine di grandezza ai dislivelli.
Una cosa e' fare 10Km a piedi con ascent=50 e descent=10, altra cosa e'
farla con ascent=2000 e descent =1500. Non sono i 100/200 mt di errori che
si accumulano a fare la differenza.
Unendo poi i dislivelli alle distanze si ricavano i tempi di percorrenza
che sono sempre arrotondati per eccesso.
Per esperienza dopo averne calcolati tanti e dopo averli rimisurati con
altimetro tarato a dovere non ho trovato differenze drammatiche. Lo stesso
dicasi per le distanze, laddove un percoso lo permetteva (tipo su di una
sterrata), ho rimisurato le distanze con rotella metrica e non c'erano
differenze drammatiche nemmeno li. Nel complesso si puo' dire che
dislivelli, distanze e di conseguenza percorrenze ricavate dal solo GPS
vanno bene per lo scopo.
Gli unici casi in cui alla fine le percorrenze sballano sono i tratti molto
brevi ma credo che l'escursionista potra' perdonare l'errore se invece di
15 minuti ce ne mette 5.


> Rifugi/ricoveri e Bivacchi/Ripari
> manca un metodo per indicare come si accede. Non tutti sono sempre aperti.
> Possono essere accessibili solo colla chiave che è custodito altrove
>

Sono due cose diverse, i Rifugi/ricoveri non gestiti hano il tag operator
che consente di individuare il soggetto che ad esempio puo' fornire le
chiavi, mentre il Bivacco/Riparo e' inteso come sempre aperto.


>
> Luogo di posa
>
> Se un luogo di posa fa parte di una relazione, la chiave rwn:name contiene
> informazione ridondante. Meglio non metterlo
>

Si e' ridondante ma non nuoce. Se voglio fare una query dei soli LDP senza
interrogare le relazioni posso farlo senza problemi. Tieni presente che e'
compito affidato ai componenti CAI che partecipano alla pianificazione e
posa dei cartelli, non ci si aspetta certo che sia l'osmer che passa di li
a farsi carico di aggiungere questi tag.


>
> Strava
>
> Questa parte della pagina va aggiornata. La heatmap di Strava con livello
> utile di risoluzione non è più disponile. E' riservata ai iscritti di
> Strava. Ho letto che ci sarà un plugin JOSM che permetterà agli iscritti
> Strava di accedere in JOSM alla heatmap dettagliata se ho capito bene i
> messaggi sulla lista JOSM)
>

Fatto


>
> Commenti sulla pagina https://wiki.openstreetmap.org/wiki/IT:Hiking
>
> Ci sono alcuni problemini, che sono anche presenti nella pagina inglese
> corrispondente
>
> Attenzione col uso di highway=footway. Questo tag include l'implicito
> divieto per bici (incluso MTB) e cavalli, oltre a quella ovvia per i
> veicoli a motori (vedi
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions).
> Qundì in tutti casi dove ci sono footway che sono aperti anche alle bici
> bisogna aggiungere bicycle=designated (se c'è un segnale a tale effetto) o
> bicycle=permissive quando c'è l'uso senza segnaletica esplicita
> highway=path invece include implicitamente horse=yes e bicycle=yes
>

Di difficile applicazione perlomeno sul territorio italiano perche' ogni
Regione ed in cascata ogni Comune puo' legiferare diversamente.
Per esempio in Liguria e' permesso il passaggio in bici, MTB ed a cavallo
su tutti i footway e path laddove non sia espressamente vietato. E'
richiesto solo di usare prudenza, dare precedenza a pedoni e animali ed
evitare i percorsi a fondo naturale (quindi i path) con avverse condizioni
meteo e nelle 48 ore successive a forti piogge onde evitare danni al fondo.
Ovviamente poi ci sono zone, parchi e comuni che vietano il passaggio in
bici ma va segnalato.
Non credo possiamo farci molto qui se non rimanere generici e codificare i
divieti dove ci sono.


>
> Nella tabella per highway=track è scritto "Usare tracktype=* per
> descrivere la superficie". Non è esatto, tracktype descrive  una
> combinazione di livello di manutenzione e superficie (vedi
> https://wiki.openstreetmap.org/wiki/Key:tracktype)
> Per indicare il tipo di superficie c'è una separata chiave "surface=", che
> è menzionato poche righe più avanti nella stessa tabella.
>

Ho tolto quella dicitura era fuorviante.


>
> La descrizione di tourism=camp_site da solo è sbagliata. tourism=camp_site
> è un tag generico per campeggi che include anche molto campeggi ben
> attrezzati. Viene anche utilizzato per posti solo per camper. Bisogna
> sempre aggiungere backcountry
> <https://wiki.openstreetmap.org/wiki/Key:backcountry>=yes
> <https://wiki.openstreetmap.org/w/index.php?title=Tag:backcountry%3Dyes&action=edit&redlink=1>
> per definire un posto senza servizi e riservato a camminatori, bici, canoa,
> cavallo, ...
>

Non ne so abbastanza, correggi pure tu.


>
> barrier=gate necessità sempre anche l'indicazione di chi può passare. Come
> default c'è access=no.
> Mancano nella tabella gli altri tipi di barriere: stile, lift_gate,
> swing_gate, ... . Forse sarebbe meglio mettere solo un link alla  pagina
> barrier= <https://wiki.openstreetmap.org/wiki/Key:barrier>.
>

Non ne so abbastanza, correggi pure tu.


>
>
> *Pagina cai_scale
> <https://wiki.openstreetmap.org/wiki/Proposed_features/cai_scale>*
> Su questa pagina, che descrive sac_scale e cai_scale un aspetto
> fondamentale dovrebbe essere più evidenziato e descritto in modo più chiaro:
> sac_scale si riferisce ad singoli pezzi di un percorso e va inserito sul
> way, non dovrebbe essere inserito nella relazione, salvo i casi dove tutti
> i ways che fanno parte della relazione abbiano lo stesso valore di
> sac_scale.
> cai_scale si riferisce all'intero percorso e quindi viene solo assegnato a
> alla relazione e non alle singole way. Inoltre, per questo motivo si
> riferisce al pezzo più difficile del percorso.
> L'accenno che c'è adesso a questo, so trova sotto le lunghe tabelle.
> Dovrebbe essere spostato più in alto, prima delle tabelle.
>
>
Era rimasto un po' vago in effetti. Ho distinto nettamente e fatto un cenno
anche piu' in "alto" nella descrizione.


> Grazie di aver letto fino a qui,
>
>
Grazie a te per esserti preso la briga di analizzare e dare suggerimenti


Alfredo
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it-cai/attachments/20181101/960f49b5/attachment.html>


More information about the Talk-it-cai mailing list