Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mar 17 ott 2017 alle ore 22:38 Andreas Lattmann <
andreas.lattm...@ga-2.it> ha scritto:

> >Come minimo è semanticamente >sbagliato e contro le "regole" di OSM, una
> >descrizione va in description, non in >name.
>
> Sono curioso di sapere di quale regola stai parlando. È nel wiki? Ne è
> stato parlato nella ml nazionale?
>

http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mar 17 ott 2017 alle ore 10:45 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> OSM non si deve adeguare a nessuna burocrazia CAI o delle Regione.
> Semplicemente i percorsi sono accatastati cosi' e noi liberiamo i dati come
> li abbiamo.
> Togliere quello che e' stato deciso come nome ufficiale del percorso
> perche' ad alcuni non piace non ha molto senso per me, sarebbe una sorta di
> vandalismo ed allonaterebbe il CAI (come altre realta') dal mondo OSM.
>

Non si tratta di togliere nulla, si tratta di mettere in name il nome,
quando ce n'è uno vero, e in description il "da-a" sempre. Se si trattasse
di un import di massa automatizzato capirei la difficoltà, ma visto che si
fa comunque a mano proprio non vedo la difficoltà.


> I problemi di ricerca che mi elenchi sono tutti facilmente risolvibili con
> delle query
>

Mi sapresti fare un esempio di query che distingue un nome vero da una
descrizione travestita, utilizzabile in un progetto su larga scala tipo
OpenandroMaps, 4UMaps o simili? Io sono dichiaratamente scarso, ma non ci
arrivo.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno lun 16 ott 2017 alle ore 23:01 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> Non vedo dove sia controproducente
>

Beh, nel momento in cui capisci che possa non piacere direi che lo sai
già... :-)

Ne avevamo già parlato. Come minimo è semanticamente sbagliato e contro le
"regole" di OSM, una descrizione va in description, non in name. Capisco
che CAI e Regioni abbiano le loro regole, e capisco l'esigenza di
inventarsi un nome quando devi scrivere l'indice di un libro, ma questo non
è il CAI e neanche un libro.

Il problema pratico è che i nomi propri servono a identificare delle cose.
Se metti name=Canale dei Genovesi e name=Canale dei Torinesi permetti di
identificare due percorsi non altrimenti evidenti. Se cominci ad aggiungere
dei "da qui a lì" su tutti i sentieri circostanti l'informazione importante
(i nomi veri) viene diluita perché devi cercare in mezzo a enne stringhe
esteticamente uguali. Allo stesso tempo non aggiungi nulla di utile perché
il sentiero Carnino-Colle del Pas lo identifico molto prima e molto meglio
tramite i POI. Se nessuna mappa commerciale indica questi nomi c'è una
ragione... sarebbe illeggibile. Alla fine la scelta sarà fra generare delle
mappe piene di scritte ridicole o non visualizzare i nomi, perdendosi però
quel 5% che sarebbe utile, e nessuna delle due è una buona soluzione.

Ma a prescindere da tutto il resto è semplicemente sbagliato semanticamente
e non so perché OSM debba adeguarsi alla pigrizia burocratica del CAI.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno ven 13 ott 2017 alle ore 21:17 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

>
> Capisco che possa non piacere ma visto che e' diventata la regola ed i
> percorsi sono accatastati cosi' presso le regioni e nel catasto nazionale
> del CAI (per il quale i CAI ha stipulato un accordo col MIBAC) non avrebbe
> senso omettere questa informazione se la si conosce.
>

Beh, ma se una regola si rivela controproducente si può sempre cambiare.
Non conosco la situazione altrove ma nel cuneese avrai il 95% dei nomi che
sono fittizi (partenza-arrivo), il risultato finale sarà che il 5% di nomi
interessanti passerà inosservato. A quel punto è come non mettere nulla.

Ricordo che esiste la key noname, utilizzabile anche sulle relazioni per
cui non c'è veramente problema a spostare i nomi fittizi in description
(che poi quello sono)
http://wiki.openstreetmap.org/wiki/Key:noname
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Così per sapere, hai visto la faccina e letto il resto del messaggio?

Il gio 12 ott 2017, 07:41 Andreas Lattmann  ha
scritto:

> >Ma si che si mappa per il rendering, tu vai in giro per monti a fare
> query da terminale con un laptop? ;-)
>
> Non si mappa per il rendering per ovvi motivi: mapnik non renderizza le
> relazioni ma altri renderer si (e comunque ci vuole uno standard comune).
> Su Osmand ad esempio li renderizza. Poi non è detto che la relazione non
> includano way che hanno un nome proprio, tipo quelle che includono vie del
> paese. In quel caso come fai? Via pinco Sentiero dei forsennati?
> La migliore soluzione è sempre non mappare per il rendering.
>
> Andreas Lattmann
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mer 11 ott 2017 alle ore 18:48 matteocalosi <
matteocal...@gmail.com> ha scritto:

>
> Lo so che non si mappa per il rendering ma i renderer escursionistici non
> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a ragione
> perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
> l'esempio delle relazioni liguri) quindi aggiungere il nome di un sentiero
> sulla way è di fatto l'unico modo di vederlo. Se non fosse formalmente
> errata come cosa io preferirei aggiungerlo piuttosto che perdere la
> visualizzazione del nome dei soli sentieri che lo hanno ufficializzato.
>

Ma si che si mappa per il rendering, tu vai in giro per monti a fare query
da terminale con un laptop? ;-)

Seriamente, ci sono due problemi:
1) Il circolo vizioso: tu metti i nomi sulle way perché i renderer ignorano
le relazioni e i renderer continuano a ignorare le relazioni perché tanto
tu metti i nomi sulle way.
2) per il rendering le relazioni sono meglio, perché rappresentano il
sentiero nella sua interezza. La way prima o poi finisce invariabilmente
spezzata in enne segmenti in seguito alle variazioni di incline,
trail_visibility, sac_scale, mtb:scale, surface e quant'altro. Il
risultato, a meno di avere un renderer particolarmente sofisticato che
riunisce i segmenti in base al name, è che i nomi finiscono per non essere
visualizzati (oppure vengono troncati) perché ciascun segmento viene
trattato a sé ed è troppo corto per ospitare il nome.

Personalmente, nel mio piccolo, ignoro il name sulle way con SAC scale
inferiore a T4 da tempo, principalmente per l'abbondanza di nomi inutili
("da qui a lì", "scorciatoia", "continua", "sterrato ciclabile",
"collegamento con..." ecc.) che fanno casino e basta.

Ciao
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Strada interrotta e routing

[Massimiliano Guidi]

>
> No, almeno inizialmente mi serviva qualcosa da usare da un PC.
>

Scarica QMapShack, poi prendi i .pbf da Geofabrik e con Routino (integrato
in QMS) crei il database di routing per fare i test. Ti tocca comunque
aspettare 24 ore per i file aggiornati di Geofabrik. Per far prima dovresti
poter salvare in .osm  da JOSM e convertire in .pbf con OSMConvert, ma non
ho mai provato.

Indispensabile leggere la documentazione di QMS, non è molto intuitivo come
software.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Vandalisi in atto Trieste

[Massimiliano Guidi]

Il giorno gio 14 set 2017 alle ore 02:51 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> no, non ci può essere un tag formalmente invalido, tutti i tags sono
> formalmente validi ("ogni tag che vuoi"). Al massimo ci sono tags che non
> sono come li intendeva chi li ha messo...
>

Uh? Se la pagina wiki dice che un tag si applica solo ai nodi quando lo
applichi a una way *è* invalido. Ho già fatto l'esempio di natural=peak, lo
espando per chiarezza.

Con il sistema attuale se tagghi una way con natural=peak il server accetta
il dato, è successo almeno 227 volte ad opera di N mappatori che
probabilmente volevano mappare una cresta (natural=arete) ma non sapevano
come farlo. Conseguenze:
a) ci sono 227 errori nel databse
b) ci sono N mappatori che continueranno a sbagliare credendo di essere nel
giusto
c) ci sono 227 creste che potevano essere mappate e non lo sono
d) ci saranno M persone che dovranno perdere del tempo a correggere un dato
errato

Se ci fosse stata una validazione dei dati a priori queste way sarebbero
state rifiutate dal server con un messaggio di errore che spiega agli N
mappatori che quella taggatura si usa solo sui nodi invitandoli a leggere
la relativa pagina del wiki (ti sembrerà strano ma un sacco di gente non sa
nemmeno che il wiki esiste). Conseguenze:
a) non ci sono errori
b) ci sono N/2 mappatori che hanno imparato qualcosa (non tutti hanno
voglia di RTFM)
c) ci sono 113 creste mappate
d) nessuno perde tempo

Cosa c'è che non va nella validazione a priori? Per la cronaca ho aperto la
prima way incriminata che ho trovato con overpass ed è lì da 9 mesi, alla
faccia dei monitoraggi a posteriori.

Ovviamente è un esempio banale e insignificante, però vedi che anche un
oggetto banale come una vetta viene sbagliato in buona fede. Accettare solo
valori validi sulle chiavi più comuni e collaudate non lede né la libertà
né la creatività di chicchessia, si possono sempre proporre nuovi valori
alla comunità e sperimentare nuove chiavi senza freni. Però le cose
palesemente sbagliate non ha senso farle passare.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Vandalisi in atto Trieste

[Massimiliano Guidi]

Il giorno mer 13 set 2017 alle ore 17:51 Alessandro  ha
scritto:

> Il 13/09/2017 10:37, Max1234Ita ha scritto:
> >
> > Il "vaccino" contro questo genere d'inconvenienti sarebbe sì allargare la
> > Comunità, così da avere un migliore controllo, IMHO, però, sarebbe
> efficace
> > anche l'introduzione, a livello delle API di OSM, di un qualche sistema
> di
> > autenticazione/identificazione univoca del'utente, o meglio del suo
> computer
> > e del software da lui utilizzato per l'editing.
> >
> > Questo permetterebbe forse, in caso di azioni illegali, di bloccare ogni
> > successivo upload proveniente dal quel particolare punto di accesso
> > (macchina + sw usato).
>
> Potrebbe servire per una certa percentuale di utenti ma il problema
> rimarrebbe.
> Una folta comunità e la conoscenza di alcuni dei molti strumenti utili
> per il monitoraggio è la miglior medicina.
>

Il monitoraggio della comunità ha un problema di fondo ineliminabile:
intervieni a posteriori, quindi per definizione in ritardo. Se poi ci metti
i tempi che ha il DWG a rispondere, nonché la riluttanza ad intervenire in
diversi casi già passati su questa lista, capisci che è una strategia
fallimentare. Che sei un vandalo deliberato o uno che spacca le cose senza
rendertene conto non va bene comunque, devi essere fermato il prima
possibile. Una volta OSM era una cosa vuota da riempire e formare, era
anche comprensibile tirar dentro chiunque e accettare l'approssimazione.
Oggi c'è un sacco di roba costata fatica, ci sono un sacco di gente e di
servizi che dipendono da questi dati, e al tempo stesso sono dati sempre
più complessi da maneggiare. Un minimo di serietà deve essere pretesa.

Oggi per mappare basta avere un indirizzo email con cui iscriversi e gli
indirizzi email gratis sono ovunque. Nel tempo che blocchi un account a
Karma ne ha fatti altri due, ha vinto lui in partenza, è un sistema che
premia i troll. Chiedi un cellulare per validare periodicamente l'account
via SMS e vedi che il 90% del vandalismo volontario sparisce. Se mi dici
che ha dei costi insostenibili amen, ma dai discorsi che si sentono ogni
volta in questi casi mi pare manchi proprio la volontà "politica" di far
qualcosa.
Poi c'è anche una questione di validazione del dato. Perché devono esserci
227 way con il tag natural=peak? Perché se scrivo "Steep as hell" nel tag
incline viene accettato? E' vero che un nome inventato o una posizione
sbagliata non si possono individuare via software, ma c'è una marea di
oggetti con taggatura *formalmente* invalida. Questa cosa si può bloccare
immediatamente nel momento in cui viene caricata sul server, con un doppio
risultato: non hai dati palesemente marci, e allo stesso tempo educhi chi
sta cercando di caricarli senza probabilmente rendersene conto. Invece no,
carichiamo tutto, poi magari qualcuno se ne accorge e corregge...
E alla fine c'è il peer reviewing. E' proprio impossibile avere un'opzione
per essere avvisati quando modificano qualche oggetto su cui si è
intervenuti? Si suppone che chi c'è intervenuto abbia una conoscenza
dell'oggetto stesso per cui è il candidato ideale a fare una verifica al
volo. Prevengo l'obiezione, gli "armchair mappers" che riceverebbero troppo
notifiche hanno solo da non attivare il servizio. Al momento questa cosa
con un servizio esterno non si può fare a priori visto che basta spezzare
una way per farle perdere la sua storia (altro problema non da poco).

Scusate lo sfogo, ma sono un po' (troppo) stufo di vedere certe cose.

Ciao.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sentiero attrezzato (no ferrata)

[Massimiliano Guidi]

Il giorno mar 5 set 2017 alle ore 10:29 Lorenzo Milesi 
ha scritto:

>
> Come si deve taggare un percorso escursionistico dove però sono presenti
> delle catene? Non è da considerarsi alpinistico, e nemmeno una via ferrata
> (credo), è solo un tratto dove per sicurezza sono stati messe catene o
> pedane per il passaggio.
>

Anche se è una catena si mappa come cavo
http://wiki.openstreetmap.org/wiki/Key:safety_rope

Le altre misure di sicurezza qui
http://wiki.openstreetmap.org/wiki/Key:assisted_trail

Le ferrate sono effettivamente un'altra cosa, sono attrezzate per
assicurarsi. Suppongo possano esistere però casi intermedi in cui il
confine è labile.

Ciao
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] OSM e CAI

[Massimiliano Guidi]

Il giorno sab 17 dic 2016 alle ore 21:06 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> Diciamo che io potrei anche essere daccordo che se non ha un nome proprio
> basta il numero e magari from e to. Il problema e' che in alcune regioni
> dove il CAI e' legato da convenzioni e' necessario identificare il percorso
> e come spesso accade quando si e' persa la memoria dei vecchi su qual'era
> il nome di quel tracciato, gli se ne da uno nuovo che identifica il
> percorso con dei toponimi di partenza, intermedi e arrivo. Questo diventa a
> catasto il nome del sentiero, viene riportato sui cartelli, e risulta cosi'
> anche nel catasto regionale.
> Di fatto diventa il "name". Anche in posti dove non c'e' questo rapporto
> CAI-regione sono molti i sentieri identificati cosi' anche sui cartelli
> quindi e' una situazione reale.
>

Non è che diventa il name, viene usato al suo posto, che è diverso. Dalle
mie parti un sentiero che ha un nome proprio è l'eccezione, non la regola.
Poi colloquialmente si usa sovente l'espressione "il sentiero del $monte",
ma è una descrizione, non un nome proprio. Ha un valore semantico diverso.
Io capisco la pratica CAI, ma è in contrasto con la prassi che si dovrebbe
usare su OSM. Oltretutto, pensaci bene, se per gli scopi del CAI vuoi usare
il contenuto di description al posto di name in assenza di quest'ultimo è
assolutamente banale farlo a posteriori. Se tu mischi le cose in fase di
inserimento dati invece è impossibile separarle in seguito in maniera
automatizzata: quale algoritmo sa distinguere la differenza tra il nome
reale "Canale dei Genovesi" e il pseudo-nome "Carnino-Marguareis"?


> Per la lunghezza e problemi simili vale quanto detto sopra. Il problema
> esiste da sempre, sta al cartografo risolverlo. Detto questo pero' se vuoi
> sviluppare un po' il concetto di short_name potresti mettere su una pagina
> wiki e cominciare a lavorarci, magari se viene fuori una cosa ragionevole
> diventa utilizzabile e risolve parte del problema.Rimane il fatto che e' un
> taggare per il rendering ma in fondo lo e' anche osmc:symbol
>

Non è affatto taggare per il rendering, e non è compito del cartografo,
soprattutto in un'era in cui le mappe coprono il mondo intero e sono
generate da dei computer. Collegare GTA a Grande Traversata delle Alpi è
banale per un essere umano, non per un computer. Se fai l'acronimo
prendendo le iniziali ottieni GTDA, che non è quello che usa la gente
normalmente. Chiaro che se l'algoritmo lo scrive un italiano può escludere
automaticamente articoli, congiunzioni e preposizioni, ma non sei comunque
sicuro che corrisponda alla realtà perché da un'altra parte magari si fa
l'acronimo anche con l'iniziale di un articolo. Per uno straniero che mette
su un server con copertura mondiale è pura fantascienza risolvere questi
problemi su scala globale. Se guardi in giro con le OpenAndroMaps che
implementano una semplificazione automatica dei nomi a volte trovi cose
discutibili. Se un qualcosa ha sia un nome che un acronimo diffuso
indicarlo esplicitamente ha molto senso. Il concetto di short_name non lo
invento io, è un tag già in uso descritto nella pagina della key name.
Curiosamente in quella pagina c'è un link alla pagina
http://wiki.openstreetmap.org/wiki/Key:short_name che ti rimanda alla
pagina da cui provieni. Probabilmente non hanno ritenuto che ci fosse altro
da dire. Io credo sia adatto allo scopo.

Infatti e' una menata e come avrai visto dalla wiki non e' certo una cosa
> obbligatoria e caldeggiata. E' soltanto una necessita' in alcune zone come
> Liguria, Piemonte, Toscana, Emilia Romagna dove esiste una correlazione fra
> rete sentieristica regionale e quella non inserita in quella regionale. A
> quelli come noi a cui servono queste informazioni semplifica molto la vita
> per fare query e tenere sotto controllo le cose. Nessuno si aspetta che
> qualun altro usi questi tag se non gli sono utili.
>

Il problema è che se li inserisci con un namespace ne rendi più complicato
l'utilizzo agli altri. I ref della REL sono utili, ma se li metti un
namespace proprio nessuno che non sia a conoscenza della cosa li vede. I
namespace sono ammessi, ma c'è un invito esplicito a usarli solo se
necessario quando i benefici superano gli inconvenienti proprio per queste
ragioni http://wiki.openstreetmap.org/wiki/Namespace


> Sarebbe anche da mettere nero su bianco che nomi tipo "collegamento
> con...", "scorciatoia", "sentiero per il rifugio x" non sono nomi e non
> dovrebbero essere inseriti, sempre per il criterio che non aggiungono
> informazioni utili.
>
>
> Se sono segnati cosi' sui cartelli o nei catasti sono i nomi dei sentieri
> anche se non sono belli e sembrano piu' descrizioni
>

A ragionare così mettiamo "name=toilette" su ogni vespasiano... :-)
Sul cartello di solito c'è scritto "tagliare i tornanti provoca erosioni",
ma anche ci fosse scritto "scorciatoia" non sarebbe comunque un nome ma
un'indicazione. Parlavo comunque di cose scritte 

Re: [Talk-it] OSM e CAI

[Massimiliano Guidi]

>
> sono un po' di corsa, butto lì un paio di osservazioni
>
>
Ritorno espandendo un po' il concetto espresso ieri di fretta. Sarò lungo,
sorry.

Premessa: "non si mappa per il rendering", lo dico subito io, così facciamo
prima. Precisiamo anche però che questo mantra è scritto male, il
significato corretto originale è "non si mappa *sbagliato* per il
rendering". Cioè se il mio renderer di fiducia non visualizza i sentieri la
soluzione è cambiare il sw, non mappare i sentieri come track, cosa che
avveniva spesso agli inizi. Mi sembra che ultimamente questo significato
originale si sia un po' perso, a volte sembra che l'interesse sia riempire
un database e basta, lasciando poi a qualche fantomatico "algoritmo" il
compito di districarsi nela labirinto. In realtà mappiamo tutti per avere,
alla fine, un qualche tipo di rendering, soprattutto in ambito
escursionistico dove la fruizione del dato passa più o meno
obbligatoriamente tramite una rappresentazione grafica. Dunque è ampiamente
il caso di porsi il problema dell'utilizzo finale dei dati inserendoli fin
dall'inizio in modo da facilitarne l'uso. Personalmente negli ultimi due
anni ho lavorato parecchio alla realizzazione di mappe escursionistiche su
dati OSM trovandomi di fronte a diversi problemi a interpretare i dati per
diverse ragioni, in particolare perché lo stile di mappatura varia
selvaggiamente da una zona all'altra.

Il CAI interviene su OSM in un momento in cui, almeno per l'arco alpino,
gran parte del lavoro di inserimento è già fatto. Quindi in massima parte
non si tratterà  di inserire una sentieristica, ma di corregere, uniformare
e classificare correttamente quella che già esiste. Inoltre essendo OSM un
progetto internazionale e utilizzato in gran parte da strumenti automatici
bisogna tener conto della realtà esistente anche se cozza un po' con le
tradizioni locali, se no l'informazione inserita finisce per essere poco
utile. Secondo me questa collaborazione tra OSM e CAI rappresenta
l'occasione giusta per fare ordine e pulizia, ma anche e soprattutto per
provare a stilare delle linee guida da usare in generale per tutto il
discorso escursionistico e non solo per le cose ufficialmente gestite dal
CAI.

Veniamo ai punti che secondo me sarebbero da valutare.

Nomi, descrizioni e ref.
Credo sia la cosa che ha fatto dannare di più, con il risultato finale che
ho deciso di non visualizzare i nomi se non in casi particolari. A volte
sono attribuiti alla way, a volte alla relazione. A volte hanno senso, a
volte sono inventati. Di sicuro sono sempre ingombranti. Questa cosa non è
da sottovalutare, perché stringhe lunghe prendono spazio e soprattutto a
livelli di zoom bassi o a scale molto ridotte non ci stanno o cozzano con
altre cose diminuendo la leggibilità della mappa.
In base ai criteri espressi su
http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only e nel
paragrafo successivo se una cosa non ha un nome proprio non si deve
darglielo a tutti costi.
"Sentiero degli alpini" è un nome proprio, usato dalla gente che però non
dà indicazioni sul luogo dove si sviluppa il percorso. Io ho un forte
interesse a rappresentare questa cosa su una mappa, perché mi permette di
individuare con sicurezza un percorso non altrimenti indentificabile.
"Varese Ligure - Passo Chiapparino - La Pelosa" invece non è un nome
proprio e non ho nessun interesse a visualizzarlo perché non mi aggiunge
nessuna informazione utile e crea i fastidi citati sopra. E' una
descrizione che è utile avere, ma deve essere classificata come tale.
Inserirla come descrizione permette anche di far convivere il nome proprio
con la descrizione. Cioè posso usare contemporaneamente il nome "sentiero
degli alpini" e anche l'informazione "partenza-arrivo", cosa
particolarmente utile nel caso di nomi diffusi come appunto "sentiero degli
alpini" o "via del sale" che si trovano ovunque sulle Alpi.
C'è poi un problema di lunghezza in cose come l'Alta Via dei Monti Liguri o
la Grande Traversata delle Alpi, veramente o zoommi "abbestia" o non ci
stanno, e ironia della sorte questo tipo di informazione è più utile a
livelli di zoom bassi. Dunque l'esigenza di avere delle abbreviazioni
esiste, e non solo in OSM tant'è vero che anche sui segnavia spesso si
usano gli acronimi. Bisognerebbe regolamentare questa cosa, esiste in uso
il tag short_name che non ha una pagina wiki specifica ma credo sia adatto
allo scopo. In questo modo uno può usare per le mappe l'acronimo e per
altri usi il nome esteso creando un'equivalenza chiara.
Poi ci sono i codici identificativi. Non me ne voglia Alfredo ma l'uso di
namespace come ref:REL o rwn:name sono una menata infinita da gestire,
soprattutto se si pensa all'uso che viene fatto normalmente dei dati OSM,
cioè l'elaborazione automatica su ampie aree che non può tener conto di
queste cose di cui oltretutto non credo esistano esempi in uso, perlomeno
io non ne ho trovati. Se un sentiero ha più codici (MTB, CAI, FIE ecc) si
fanno più relazioni, tanto 

Re: [Talk-it] OSM e CAI

[Massimiliano Guidi]

>
> Non è ancora definitiva ma una bozza avanzata è qui
>
> https://wiki.openstreetmap.org/wiki/CAI#I_tag_da_utilizzare


Ciao,

sono un po' di corsa, butto lì un paio di osservazioni.

A proposito del "name", tag definito obbligatorio nella tabella si dice
"Se non ha un nome come “Sentiero degli Alpini” si identifica solo con il
suo numero percorso "
cosa su cui sono estremamente d'accordo, nomi come "partenza-arrivo" che si
trovano spesso nel tagging esistente fanno casino in fase di rendering e
non aggiungono nulla e soprattutto non sono nomi, ma descrizioni (che è
peraltro utile avere per generare ad esempio delle legende o usi diversi
dalla mappa grafica). Però poi, anzi prima, come valore di esempio si mette
"Varese Ligure - Passo Chiapparino - La Pelosa" e la cosa mi sembra
contraddittoria.

L'altra osservazione è sull'uso di una scala di difficoltà "proprietaria".
Io capisco benissimo il desiderio e anche l'esigenza di usare la propria
scala, però già che si è lì credo sarebbe opportuno inserire, quantomeno
fra i tag rilevanti se non in quelli obbligatori anche la scala SAC,
suggerendo di verificare anche i valori già presenti che spesso sono
sballati (in particolare il T4 è spesso usato a sproposito in seguito
all'equivoco sul significato di "alpine") . Piaccia o meno la SAC ormai è
lo standard di OSM ed è quello che usano tutti. Classificare solo con la
scala CAI significa rendere il dato poco fruibile. Visto che si possono
usare entrambe e costa poco non vedo perché non farlo.

Maki.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Progetto Montagne Sicure

[Massimiliano Guidi]

Il giorno mer 9 nov 2016 alle ore 10:56 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> +1, chiaramente usare 2 chiavi differenti per la stessa proprietà non
> sembra vantaggioso, ma il resto del mondo per ora ha usato ref, ed è quello
> che è documentato nel wiki. Vogliamo chiedere pareri in lista
> internazionale?
>

Si potrebbe anche stabilire che emergency=access_point lo mappi sempre su
un nodo a se stante dedicato solo ed esclusivamente a quello scopo. A quel
punto per definizione non ci sono ambiguità e usi il ref semplice. Io non
la trovo sbagliata come cosa per due motivi:
1) nel caso del guidepost stai effettivamente mappando un palo di legno,
nel caso del punto di emergenza stai mappando un punto virtuale nello
spazio la cui precisione assoluta del punto di soccorso non è importante
(parlo di qualche metro ovviamente). Per essere più chiaro, se una valanga
spazza la balise la chiave guidepost perde di significato e va tolta (ok,
rimettiamo la palina...), l'access_point resta perfettamente valido.
2) separando i nodi diminuisci le possibilità di modifiche involontarie e
credo si renda anche più semplice la gestione del database. In particolare
penso che questo genere di informazioni vada mantenuto con particolare cura
dall'ente che li gestisce, ad esempio facendo girare script che verificano
periodicamente la loro esattezza (sempre nell'attesa che su OSM compaiano
sistemi di protezione del dato). Se i nodi sono separati credo sia più
semplice da gestire in maniera automatizzata, se ne trovi uno spostato puoi
ripristinarlo senza tanti patemi, tanto non impatta su altro.

Personalmente non seguo la lista internazionale, ma perché no?

Maki
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Progetto Montagne Sicure

[Massimiliano Guidi]

Il giorno mar 8 nov 2016 alle ore 22:07 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
> se posso permettermi, avere più sistemi di riferimento in uso nella stessa
> zona, o piu associazioni in parallelo nella stessa zona che gestiscono
> indipendentemente i soccorsi già mi sembra una cattivissima idea per se.
> Nella realtà non è che si affida una zona ad un operatore per un periodo,
> e poi nel caso ci devono operare più organizzazioni c'è comunque una sola
> (associazione /istituzione ) che coordina gli altri?
>

Ma è quello il punto. Siccome non esiste un sistema nazionale per questa
cosa rischi a causa di una cattiva mappatura (o un cattivo rendering, o una
cattiva lettura) di mandare i soccorsi alla palina 111 del CNSAS invece che
al numero 111 della Croce Bianca che opera nella stessa zona o al numero
111 della Croce Rossa della zona accanto. Finché si tratta di iniziative
locali non puoi escludere a priori questi problemi; da un certo punto di
vista, finché non esiste un sistema unico, perfino se ognuno usasse un tag
proprietario non sarebbe nemmeno male. Almeno non ci si intralcia. E il
giorno in cui ci sarà il sistema unico potrai tenere senza ambiguità anche
i vecchi ref locali per retrocompatibilità.

Il giorno mar 8 nov 2016 alle ore 21:28 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> in realta' la presenza del tag emergency=access_point definisce gia'
> l'oggetto come tale e quindi il ref univoco lo e' di conseguenza.
>

Certo, se c'è solo quello. Quel tag è nato per le colonnine di soccorso
autostradali, difficilmente coesiste sullo stesso nodo con altre cose. Ma
se coincide con il nodo di una palina turistica o altro secondo me è facile
arrivare a confusioni. Anche se tu adesso fai un lavoro perfetto, basta un
editing maldestro in seguito a creare il caos.

In ogni caso per me che creo mappe dover scrivere un algoritmo che tiene
conto di diverse situazioni è una complicazione in più, che aumenta la
probabilità di fare errori. Se prevedi comunque la situazione in cui si usa
ref:emergency tanto vale usarlo sempre, almeno hai un criterio unico e
semplice. Non vedo il vantaggio di stare a distinguere se c'è già un ref o
meno.

Maki
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Progetto Montagne Sicure

[Massimiliano Guidi]

Ciao a tutti, primo post da queste parti. Scrivo da InBox, spero esca un
quoting decente.

In sintesi, mappare come emergency=access_point + ref=* se il codice è
> unico; mappare come emergency=access_point + tourism=information +
> information=guidepost + ref:emergency=* + ref=* se c'è un codice per le
> emergenze e un altro per le indicazioni turistiche.
>
> Se c'è un certo consenso potrebbe essere una buona idea integrare il
> wiki con queste indicazioni.
>
> In ottica di utilizzazione dei dati potrebbe essere indicato un
> algoritmo tipo questo:
>
> 1) ricerca del tag ref:emergency=* → se presente usare questo, altrimenti
> 2) ricerca del tag ref=* → se presente usare questo


Se posso permettermi una cosa del genere è complicata da gestire e si
presta troppo facilmente a fallimenti in caso di mapping imperfetto.
Siccome si parla di soccorsi i fallimenti non sono ammessi.

Dare al ref semplice un significato diverso in funzione della presenza o
assenza di altri tag è pericoloso. Un riferimento di emergenza deve essere
associato senza possibilità di errore all'associazione che lo gestisce.
Sarebbe anche bello pensarci a monte da parte dell'ente che fa questa cosa,
mettendo un prefisso o suffisso al numero per evitare doppioni con altre
entità. A livello di mappatura secondo me è indispensabile avere un
riferimento chiaro all'ente che gestisce la cosa e usare un solo tag che
sia sempre quello. Per cui se il soccorso alpino mette i numeri alle paline
si usa ref:emergency:cnsas=111, se lo fa la croce rossa si usa
ref:emergency:cri=111. In questo modo anche se ho due numeri uguali da
parte di diverse associazioni nella stessa zona sono sicuro che non ci sono
equivoci, so sempre a chi mi rivolgo e non devo inventarmi algoritmi nuovi.

Maki
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it