Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Paolo Monegato]

Il 15/12/2015 11:53, Aury88 ha scritto:

Paolo Monegato wrote

Tra l'altro lì si potrebbe anche mettere quel che vien fuori dai
dibattiti in ML, tipo quando si definisce di taggare una cosa in un dato
modo.

dove intendi? nella discussione della pagina tag?


Nel "glossario / How to map a". Ogni volta che si giunge ad un accordo 
sarebbe da aggiornare lì.



Se non ho capito male vorresti in pratica che ci fosse una pagina
generale che richiama contenuti di altre pagine... forse si potrebbe
fare con dei cassetti a scomparsa che includano le pagine come fossero
dei template (così una volta che si aggiorna la "sottopagina"
automaticamente si aggiorna anche la superiore)...
Servirebbe però un esempio pratico per capire bene.

  si diciamo di si! penso che prima servirebbe il template o qualcosa del
genere che permetta questa cosa...non l'ho vista mai applicata purtroppo,
quindi non credo esista proprio la possibilità di farlo, almeno al momento
attuale. ripeto posso creare penso una sorta di mockup cioè una cosa che si
presenta simile ma che non è realizzata usando il "motore" della cosa
desiderata, ma facendo tutto a mano.


Magari appena riesco provo a fare un esempio su una sandbox...


Le sottopagine sono delle pagine normali che si trovano "sotto" un altra
pagina.
Esempio: WikiProject Italy/Ciclovie è una sotto pagina di WikiProject
Italy (che invece è una pagina che si trova nel namespace principale:

ok chiaro. il come è strutturato il link con sottopagine e namespace non è
importante di per se, l'importante è la possibilità di seguire il percorso
logico da una pagina all'altra secondo me. l'uso di namespace può essere
utile per andare direttamente a delle (macro)categorie principali ma poi la
struttura come sottopagina per gli elementi minori potrebbe risultare
limitante per quanto riguarda quegli elementi presenti in più ambiti e che
quindi, con una struttura basata sulle sottopagine, richiederebbero il
ricreare più volte lo stesso contenuto per sottopagine differenti (con il
rischio di disallineamento tra le varie pagine trattanti lo stesso
oggetto)..


No, perché ti basta richiamare le stesse pagine/sottopagine ovunque ti 
serva. Ma per farti capire come intendo devo farti un esempio sul wiki...


ciao
Paolo M

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Paolo Monegato wrote
> Non ti conviene cercare direttamente su IT:Map_Features? Io ce l'ho nei 
> preferiti e se cerco un tag per prima cosa guardo lì con un bel 
> CTRL+F... Se però cerco qualcosa di più specifico vado direttamente nel 
> wiki.

Conviene se so come si chiama l'oggetto...mi capita spesso di mappare degli
elementi che non so cosa siano o come vengano chiamati e quindi l'unica è
risalire all'oggetto tramite la sua descrizione fisica (le immgini sono
molto utili per questo)...l'idea iniziale del wiki con percorso logico era
permettere una ricerca basandosi sull'ambito di utilizzo dell'elemento e
questo seguendo la logica con cui spesso si mappa...cioè partendo
dall'elemento più esteso e poi a mappare gli elementi al suo interno (il cui
ambito sarà naturalmente l'elemento più esteso). sono poche le pagine wiki
che descrivono non solo l'elemento e il tag per lui necessario, ma anche
dove cercare per avere i tag delle cose all'interno del suddetto elemento.
strutturando così il wiki invece questa cosa diventava più naturale e anche
facile da manutenere. imho

> Tra l'altro lì si potrebbe anche mettere quel che vien fuori dai 
> dibattiti in ML, tipo quando si definisce di taggare una cosa in un dato 
> modo.

dove intendi? nella discussione della pagina tag?

> Se non ho capito male vorresti in pratica che ci fosse una pagina 
> generale che richiama contenuti di altre pagine... forse si potrebbe 
> fare con dei cassetti a scomparsa che includano le pagine come fossero 
> dei template (così una volta che si aggiorna la "sottopagina" 
> automaticamente si aggiorna anche la superiore)...
> Servirebbe però un esempio pratico per capire bene.

 si diciamo di si! penso che prima servirebbe il template o qualcosa del
genere che permetta questa cosa...non l'ho vista mai applicata purtroppo,
quindi non credo esista proprio la possibilità di farlo, almeno al momento
attuale. ripeto posso creare penso una sorta di mockup cioè una cosa che si
presenta simile ma che non è realizzata usando il "motore" della cosa
desiderata, ma facendo tutto a mano.

> Le sottopagine sono delle pagine normali che si trovano "sotto" un altra 
> pagina.
> Esempio: WikiProject Italy/Ciclovie è una sotto pagina di WikiProject 
> Italy (che invece è una pagina che si trova nel namespace principale: 

ok chiaro. il come è strutturato il link con sottopagine e namespace non è
importante di per se, l'importante è la possibilità di seguire il percorso
logico da una pagina all'altra secondo me. l'uso di namespace può essere
utile per andare direttamente a delle (macro)categorie principali ma poi la
struttura come sottopagina per gli elementi minori potrebbe risultare
limitante per quanto riguarda quegli elementi presenti in più ambiti e che
quindi, con una struttura basata sulle sottopagine, richiederebbero il 
ricreare più volte lo stesso contenuto per sottopagine differenti (con il
rischio di disallineamento tra le varie pagine trattanti lo stesso
oggetto)..si potrebbe fare anche così ma secondo me è più comodo che ogni
tag abbia una propria pagina e che poi ci sia un modo per legarle ad una o
più altre pagine (che potrebbero contenere a loro volta tag o anche non
contenerne affatto). Una cosa simile credo siano le categorie in wikipedia
ma anche li sono ad un livello effettivamente molto più semplice di quanto
proponevo.




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5862512.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

2015-12-09 8:35 GMT+01:00 Federico Leva (Nemo) :

> FYI, Translate compila automaticamente un glossario, o piú precisamente
> una memoria di traduzione (che però equivale a un glossario se le stringhe
> da tradurre sono brevi).
> Cliccate
> https://translatewiki.net/w/i.php?title=Special:Translate=out-osm-site=translated=translate
> e poi cliccate qualche parola per vedere i suggerimenti di traduzione.
> Ovviamente i suggerimenti non sono completi perché ci sono "solo" 3
> prodotti OSM in traduzione qui.
> https://translatewiki.net/wiki/Translating:OpenStreetMap
>


come mai utilizzano google analytics? Al proposito, consiglio a tutti che
non lo conoscono ancora, due estensioni del browser: ghostery e no-script.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

2015-12-09 8:35 GMT+01:00 Federico Leva (Nemo) :

> Ovviamente i suggerimenti non sono completi perché ci sono "solo" 3
> prodotti OSM in traduzione qui.
> https://translatewiki.net/wiki/Translating:OpenStreetMap
>


si, questi prodotti sono:
OpenStreetMap - Website
Potlatch 2 - Help
Potlatch 2 - Main

Quindi il wiki viene gestito altrove, come anche JOSM.


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Federico Leva (Nemo)]

Su Google Analytics non chiedere a me, lo vieterei per legge. :)

> Quindi il wiki viene gestito altrove, come anche JOSM.

Non capisco. Il sito che si traduce in translatewiki.net è OSM.org, non 
wiki.OSM.org: Translate può essere installato *su* OSM wiki, per 
tradurre le pagine del wiki medesimo. Quindi il wiki resta gestito 
esattamente com'è ora.


Nemo

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

2015-12-09 10:21 GMT+01:00 Federico Leva (Nemo) :

>
> Non capisco. Il sito che si traduce in translatewiki.net è OSM.org, non
> wiki.OSM.org: Translate può essere installato *su* OSM wiki, per tradurre
> le pagine del wiki medesimo. Quindi il wiki resta gestito esattamente com'è
> ora.




si, l'argomento della presente discussione è il wiki di OSM. Per avere
informazioni sulla traduzione c'è una pagina wiki:
http://wiki.openstreetmap.org/wiki/Wiki_Translation
Per richiedere l'installazione di componenti aggiuntivi bisogna scrivere al
admin del osm wiki.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Federico Leva (Nemo)]

> si, l'argomento della presente discussione è il wiki di OSM. Per 
avere informazioni sulla traduzione c'è una pagina wiki: 
http://wiki.openstreetmap.org/wiki/Wiki_Translation


Ho già collegato quella pagina nel mio primo messaggio in questa 
discussione.


> Per richiedere l'installazione di componenti aggiuntivi bisogna 
scrivere al admin del osm wiki.


TomH è già d'accordo, vedi collegamento già fornito:
https://lists.openstreetmap.org/pipermail/talk-it/2015-December/050399.html

Nemo

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

2015-12-09 11:56 GMT+01:00 Federico Leva (Nemo) :

> TomH è già d'accordo,
>
>
ottimo, è lui che conta ;-)

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Paolo Monegato]

Il 08/12/2015 18:37, Aury88 ha scritto:

Paolo Monegato wrote

1) Che non ho ben capito come vorresti riorganizzare la cosa, e da quel
che si capiva pareva che ogni volta per scegliere un tag ci volessero
alcuni minuti (per questo parlavo di complicazione inutile)...

si. teoricamente ci vuole più tempo se sai già cosa stai cercando. al
momento attuale la ricerca che faccio io è praticamente: ho una cosa che
voglio mappare, so come si chiama in italiano cerco la descrizione in
inglese che più gli si avvicina in
http://wiki.openstreetmap.org/wiki/Map_Features
che naturalmente ha tempi lunghi di caricamento e di consultazione...in
questa pagina la separazione per key non sempre è di aiuto.


Non ti conviene cercare direttamente su IT:Map_Features? Io ce l'ho nei 
preferiti e se cerco un tag per prima cosa guardo lì con un bel 
CTRL+F... Se però cerco qualcosa di più specifico vado direttamente nel 
wiki.



in questo caso un percorso logico che guidasse nella scelta del tag poteva
essere utile
con la pagina glossario però basta sapere come si definisce in italiano cosa
si vuole mappare, il che evita tutta la lunga faccenda della ricerca del tag
tramite la sua descrizione, ed è certamente più breve che non serguire un
percorso logico nel wiki.


Tra l'altro lì si potrebbe anche mettere quel che vien fuori dai 
dibattiti in ML, tipo quando si definisce di taggare una cosa in un dato 
modo.



  Perché veramente io non capisco come
intendi fare:
- vuoi riformare le tabelle su Map Features?

  no
la tabella semplicemente viene ricostruita dalle sole ramificazioni
sottostanti in maniera meccanica non manuale come le
attuali...fondamentalmente hai diciamo 2 campi per ogni pagina tag. il primo
con il tag un immagine e una descrizione breve. un secondo per una
descrizione più completa con eventuali sottotag e rimandi ai livelli
inferiori e superiori. il 1° campo venire visualizzato, se richiesto, in una
qualsiasi delle pagine dei livelli superiori la pagina tag. il campo può
essere messo magari in una tabella, assieme a tutti gli altri tag, di tutti
i livelli inferiori il livello da cui richiami questa visualizzazione. è un
po' come avviene attualmente per i gruppi...per esempio dalla pagina gruppo
"Education_features"[1] visualizzi già i tag usati per i vari tipi di
scuola...nella mia idea questa visualizzazione è realizzata automaticamente
attingendo dalle singole pagine dei tag dei livelli inferiori il generico
livello "Education" (per esempio). non visualizzi solo le scuole però, puoi
anche estendere la lista ai livelli ancora inferiori e vedere subito
all'interno dell'oggetto amenity=school che altri tipi di tag sono
utilizzati (non parliamo di "sottotag" come name, addr* usati sullo stesso
oggetto, ma per esempio di building=school, amenity=parking,
leisure=recreation_ground cioè gli oggetti interni dal punto di vista
geometrico/geografico)


Se non ho capito male vorresti in pratica che ci fosse una pagina 
generale che richiama contenuti di altre pagine... forse si potrebbe 
fare con dei cassetti a scomparsa che includano le pagine come fossero 
dei template (così una volta che si aggiorna la "sottopagina" 
automaticamente si aggiorna anche la superiore)...

Servirebbe però un esempio pratico per capire bene.

  
- o vuoi categorizzare le pagine in modo diverso?

  credo di sì...come sono categorizzate attualmente? il vedo solo pagine a se
stanti alcune volte linkate e raggruppate  da pagine gruppo o pagine key.
l'uso delle categorie non è sfruttato se non per le traduzioni.
nell'idea originaria la categorizzazione in realtà  è data dalla struttura
ad albero per cui gli elementi fanno parte delle "categorie" dei livelli
superiori; ma non credo sia necessario esplicitarlo...basta mettere una
pagina sotto un altra.


Il wiki è abbastanza incasinato. Ci sono centinaia di pagine non 
categorizzate [1] e/o orfane [2] (cioè prive di collegamenti in entrata) 
che quindi di fatto è quasi come se non esistessero perché ci si arriva 
solo se le conosci...


   
- o intendi una serie di sottopagine?
  
- oppure vorresti dei namespace dedicati?

  onestamente non  saprei dire...se intendi sottopagine quelle raggiungibili
solo tramite link sì, ci potrebbero essere ma non è su quelle che vorrei la
struttura ad albero...


Le sottopagine sono delle pagine normali che si trovano "sotto" un altra 
pagina.
Esempio: WikiProject Italy/Ciclovie è una sotto pagina di WikiProject 
Italy (che invece è una pagina che si trova nel namespace principale: 
guarda l'url, dopo wiki/ c'è subito il nome della pagina... Invece per 
Ciclovie devi prima digitare anche WikiProject Italy).
Volendo puoi trattarle come fossero dei Template e farle apparire in un 
altra pagina...



i namespace dedicati non ho capito cosa intendi.


In sostanza se una pagina è tipo Wiki Project Italy è nel namespace 
principale, la pagina di discussione ha un suo namespace (se guardi 
l'indirizzo vedrai che dopo /wiki/ trovi Talk: e poi il nome della 
pagina), 

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Federico Leva (Nemo) wrote
> 1) organizzazione multilingue pessima, rimasta a pratiche che erano 
> obsolete già 10 anni fa (traduzione difficile, sincronizzazione 
> inesistente): la soluzione è pronta e si chiama Translate, il consenso 
> c'è e la conversione può essere graduale 
> https://wiki.openstreetmap.org/wiki/Talk:Wiki_Translation#Translate_extension 

 tu ritieni quindi che i problemi siano in parte dovuti alla mancanza di
traduzione delle pagine wiki...a mio avviso non è necessariamente quello
infatti molti dei tag "ridondanti" hanno anch'essi una dicitura in inglese e
quindi chi li ha inseriti ha una conoscenza o comunque capacità di
comprensione dell'inglese...temo che il grosso del problema sia proprio il
non aver trovato il tag giusto (perchè in pagine orfane, male o non
documentato, perchè messo in un orda di tag)...è chiaro comunque che come è
adesso la traduzione non aiuta di certo a mantenere il wiki efficiente e
quindi una soluzione in questo senso è più che ben accetta imho. non capisco
comunque come funziona questo translate.


> 2) duplicazione non-linguistica delle informazioni, per esempio fra 
> pagine specifiche dei tag e pagine con tabelle che sintetizzano piú tag: 
> la soluzione è come minimo una transclusione via 
> LabeledSectionTransclusion, al meglio un sistema semantico con SMW o
> Cargo.

capisco credo anche qui il problema ma non capisco alcune soluzioni
proposte...il problema è il fatto che molti tag sono indicati sia in pagine
specifiche sia in pagine che elencano più tag, ma il modificare info su uno
dei due non modifica automaticamente l'info sull'altro, giusto?
Forse ho capito come funziona la LabeledSectionTransclusio, ma mi sarebbe
comunque utile una spiegazione, mentre le altre due soluzioni (SMW, Cargo)
non ho capito proprio come funzionino.

anche questo è un problema che sento...è infatti l'idea della struttura
modulare che permettesse di switchare per visualizzare l'elenco tag (e
relative descrizioni brevi) delle ramificazioni inferiori proponeva una
soluzione a questo problema, se ho capito bene la seconda problematica da te
indicata ...




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861943.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 06.12.2015 um 20:34 schrieb Aury88 :
> 
> ..mentre il
> semplice avviso non vedo particolari problematiche e potrebbe essere davvero
> molto utile e probabilmente più efficacie di un wiki organizzato
> diversamente.


in Josm è già realizzato nel validatore. 


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Paolo Monegato]

Il 07/12/2015 18:54, Federico Leva (Nemo) ha scritto:
Scusate, rispondo senza aver letto tutto. Storicamente, secondo me i 
principalissimi problemi del wiki OSM sono due:
1) organizzazione multilingue pessima, rimasta a pratiche che erano 
obsolete già 10 anni fa (traduzione difficile, sincronizzazione 
inesistente): la soluzione è pronta e si chiama Translate, il consenso 
c'è e la conversione può essere graduale 
https://wiki.openstreetmap.org/wiki/Talk:Wiki_Translation#Translate_extension 
;
2) duplicazione non-linguistica delle informazioni, per esempio fra 
pagine specifiche dei tag e pagine con tabelle che sintetizzano piú 
tag: la soluzione è come minimo una transclusione via 
LabeledSectionTransclusion, al meglio un sistema semantico con SMW o 
Cargo.


A proposito di estensioni... Servirebbe pure TimedMediaHandler. Anche 
VisualEditor sarebbe utilissimo (peccato che non si possa, causa 
versione di mediawiki)...


ciao
Paolo M

ps: E forse pure usare FlaggedRevs sul ns principale non sarebbe una 
cattiva idea... così da evitare modifiche non discusse sulle pagine di 
riferimento (di solito quelle in inglese)



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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Paolo Monegato]

Il 07/12/2015 17:41, Aury88 ha scritto:

Paolo Monegato wrote

Bah, son sempre stato del parere che per i niubbi una pagina come Map
features o come How to map a [1] sia più che sufficiente...

Ma il sistema da te
proposto, sempre se l'ho capito, mi sembra un'inutile complicazione.

Chiarissimo, come non detto allora; è evidente che se l'idea, oltre che
confusionaria, risulta inutile oltre che complicata è evidente che non solo
non migliorerebbe la situazione, ma risulterebbe addirittura
controproducente. Essendo tra l'altro le cose da te indicate già realizzate
immagino che la situazione wiki sia già sufficientemente adeguata per il suo
scopo e sia solo una questione di tempo . La confusione che trovo io nella
consultazione della wiki probabilmente è solo frutto della mia non
conoscenza di quella particolare pagina, mentre l'impressione di una
situazione tag ridondanti tendente a peggiorare e necessariamente solo
appunto una mia persolissima impressione.

direi a questo punto che conviene  provare  a migliorare quella
paginanoto che mancano moltissimi tag (anche i più banali come un po'
tutte le highway, porti, un po' tutti gli shop dai panettieri ai supermarket
) e vengono suggeriti alcuni di fatto sconsigliati (come landuse=farm) e
questo sicuramente non contribuisce alla sua efficacia...


Vedo che non hai capito bene il senso del mio intervento. In sostanza ho 
detto due cose distinte:


1) Che non ho ben capito come vorresti riorganizzare la cosa, e da quel 
che si capiva pareva che ogni volta per scegliere un tag ci volessero 
alcuni minuti (per questo parlavo di complicazione inutile)...


2) Che a mio avviso per il niubbo una pagina tipo Map Features è 
sufficiente (sempre se il niubbo guarda il wiki, perché dubito che la 
maggioranza dei nuovi utenti lo guardi). Solo più avanti ti metti a fare 
cose più dettagliate. Io sono andato avanti un bel pezzo usando solo 
quella pagina... Dunque semmai la riorganizzazione del wiki serve a chi 
mappa già da un po'.



Tornando al punto 1, rinnovo l'invito a creare una o più sandbox per 
spiegare visivamente quel che proponi. Ovvero crea delle sottopagine 
della tua pagina utente dove prendi un tag, o una serie di tag, e fai un 
esempio di come dovrebbe essere. Perché veramente io non capisco come 
intendi fare:

- vuoi riformare le tabelle su Map Features?
- o vuoi categorizzare le pagine in modo diverso?
- o intendi una serie di sottopagine?
- oppure vorresti dei namespace dedicati?
Facci un esempio pratico, sul wiki, perché altrimenti non riesco a darti 
un parere.


ciao
Paolo M

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Paolo Monegato wrote
> Vedo che non hai capito bene il senso del mio intervento. 

 credo in realtà di aver capito pcosa dici, e visto che siete stati già in
due a proporre il glossario ho capito che probabilmente è la soluzione
migliore per affrontare la problematica.

> 1) Che non ho ben capito come vorresti riorganizzare la cosa, e da quel 
> che si capiva pareva che ogni volta per scegliere un tag ci volessero 
> alcuni minuti (per questo parlavo di complicazione inutile)...

si. teoricamente ci vuole più tempo se sai già cosa stai cercando. al
momento attuale la ricerca che faccio io è praticamente: ho una cosa che
voglio mappare, so come si chiama in italiano cerco la descrizione in
inglese che più gli si avvicina in
http://wiki.openstreetmap.org/wiki/Map_Features
che naturalmente ha tempi lunghi di caricamento e di consultazione...in
questa pagina la separazione per key non sempre è di aiuto.
in questo caso un percorso logico che guidasse nella scelta del tag poteva
essere utile
con la pagina glossario però basta sapere come si definisce in italiano cosa
si vuole mappare, il che evita tutta la lunga faccenda della ricerca del tag
tramite la sua descrizione, ed è certamente più breve che non serguire un
percorso logico nel wiki.


> 2) Che a mio avviso per il niubbo una pagina tipo Map Features è 
> sufficiente (sempre se il niubbo guarda il wiki, perché dubito che la 
> maggioranza dei nuovi utenti lo guardi). Solo più avanti ti metti a fare 
> cose più dettagliate. Io sono andato avanti un bel pezzo usando solo 
> quella pagina... Dunque semmai la riorganizzazione del wiki serve a chi 
> mappa già da un po'.

 la proposta era per entrambi i tipi di utente se non ci fosse stata la
pagina glossario. visto che c'è il glossario per l'utente inesperto risulta
molto più comodo/veloce la consultazione di quella pagina rispetto la mia
proposta.


> Tornando al punto 1, rinnovo l'invito a creare una o più sandbox per 
> spiegare visivamente quel che proponi. Ovvero crea delle sottopagine 
> della tua pagina utente dove prendi un tag, o una serie di tag, e fai un 
> esempio di come dovrebbe essere.

 purtroppo l'idea che avevo in mente io con una struttura ad albero
switchabile non è possibile ottenerla con il wiki attuale credo...potrei
fare un esempio molto ridotto a pochi tag forse ma che è solo all'apparenza
simile, ma di fatto viene basato sull' aver riscritto tutto pagina per
pagina...quindi tabelle realizzate a mano e non caricando gli elementi nelle
ramificazioni inferiori.


>  Perché veramente io non capisco come 
> intendi fare:
> - vuoi riformare le tabelle su Map Features?

 no
la tabella semplicemente viene ricostruita dalle sole ramificazioni
sottostanti in maniera meccanica non manuale come le
attuali...fondamentalmente hai diciamo 2 campi per ogni pagina tag. il primo
con il tag un immagine e una descrizione breve. un secondo per una
descrizione più completa con eventuali sottotag e rimandi ai livelli
inferiori e superiori. il 1° campo venire visualizzato, se richiesto, in una 
qualsiasi delle pagine dei livelli superiori la pagina tag. il campo può
essere messo magari in una tabella, assieme a tutti gli altri tag, di tutti
i livelli inferiori il livello da cui richiami questa visualizzazione. è un
po' come avviene attualmente per i gruppi...per esempio dalla pagina gruppo
"Education_features"[1] visualizzi già i tag usati per i vari tipi di
scuola...nella mia idea questa visualizzazione è realizzata automaticamente
attingendo dalle singole pagine dei tag dei livelli inferiori il generico
livello "Education" (per esempio). non visualizzi solo le scuole però, puoi
anche estendere la lista ai livelli ancora inferiori e vedere subito
all'interno dell'oggetto amenity=school che altri tipi di tag sono
utilizzati (non parliamo di "sottotag" come name, addr* usati sullo stesso
oggetto, ma per esempio di building=school, amenity=parking,
leisure=recreation_ground cioè gli oggetti interni dal punto di vista
geometrico/geografico) 

>  
> - o vuoi categorizzare le pagine in modo diverso?

 credo di sì...come sono categorizzate attualmente? il vedo solo pagine a se
stanti alcune volte linkate e raggruppate  da pagine gruppo o pagine key.
l'uso delle categorie non è sfruttato se non per le traduzioni.
nell'idea originaria la categorizzazione in realtà  è data dalla struttura
ad albero per cui gli elementi fanno parte delle "categorie" dei livelli
superiori; ma non credo sia necessario esplicitarlo...basta mettere una
pagina sotto un altra.

>   
> - o intendi una serie di sottopagine?
>  
> - oppure vorresti dei namespace dedicati?

 onestamente non  saprei dire...se intendi sottopagine quelle raggiungibili
solo tramite link sì, ci potrebbero essere ma non è su quelle che vorrei la
struttura ad albero...essendo la struttura ad albero in grado di generare la
lista dei tag, come accennato sù, se questa struttura venisse realizzata
semplicemente tramite link c'è il rischio di ingigantire inutilmente la

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 08.12.2015 um 18:37 schrieb Aury88 :
> 
> ho una cosa che
> voglio mappare, so come si chiama in italiano cerco la descrizione in
> inglese che più gli si avvicina in
> http://wiki.openstreetmap.org/wiki/Map_Features
> che naturalmente ha tempi lunghi di caricamento e di consultazione...in
> questa pagina la separazione per key non sempre è di aiuto.


per me Mapfeatures è una pagina che ti dà un'idea generale come funziona il 
tagging. Va bene leggersela all'inizio un paio di volte per capire il principio 
del tagging e per conoscere le chiavi ed i tags principali.

Mai andrei a cercare un tag specifico lì, perché la lista è lunga, ma ci sono 
(appositamente) riportati soltanto alcuni tags (quelli più utili /diffusi), 
quindi il rischio è grande che non trovi quel tag specifico che ti serve.

Io al solito uso la ricerca freetext nel wiki, e la ricerca di taginfo, oppure 
delle pagine chiave come quella di "shop", "historic" o "building".

Concordo comunque con chi l'ha scritto, che le pagine italiane del wiki non 
coprano tutti i tags definiti in inglese e talvolta non sono aggiornati.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Federico Leva (Nemo)]

FYI, Translate compila automaticamente un glossario, o piú precisamente 
una memoria di traduzione (che però equivale a un glossario se le 
stringhe da tradurre sono brevi).
Cliccate 
https://translatewiki.net/w/i.php?title=Special:Translate=out-osm-site=translated=translate 
e poi cliccate qualche parola per vedere i suggerimenti di traduzione.
Ovviamente i suggerimenti non sono completi perché ci sono "solo" 3 
prodotti OSM in traduzione qui. 
https://translatewiki.net/wiki/Translating:OpenStreetMap


Nemo

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 07.12.2015 um 18:05 schrieb Alessandro :
> 
> man_made=cross
> man_made=summit_cross
> summit:cross=yes
> historic=wayside_cross
> 
> le occorrenze nel mondo e in Liguria di questi oggetti sono rispettivamente
> 1743, 1
> 132, 0
> 1372, 4
> 63433, 36
> 
> E questo con un oggetto relativamente semplice.
> Ma c'è veramente bisogno di tutti questi tag? A mio avviso no



i mapper hanno ritenuto di si. ;-)
Comunque non si tratta dello stesso oggetto, sono oggetti un po' diversi (1 è 
generico, 2 è monumentale, 3 è un attributo per un altro oggetto (quindi 
letteralmente non potrebbe essere una croce ISOLATA) e 4 è una croce in scala 
per chi passa vicino.

In tedesco, per esempio, avendo 2 parole distinte, nessuno si lamenterebbe di 
presunti sovrapposizioni tra Gipfelkreuz e Wegkreuz.


> , basterebbe un man_made=cross con tag primario, poi uno si può sbizzarrire 
> con tutto quello che si vuole.


perché fermarsi lì, basterebbe un tag poi=yes, i dettagli si aggiungono poi ;-)

Seriamente, il livello di dettaglio iniziale lo scelgono i mappatori, ed è 
abbastanza importante per come si sviluppa l'ontologia del tagging poi di 
seguito...



> Che senso ha specificare che è un man_made=summit_cross quando posso capirlo 
> dalla vicinanza con una vetta?


non lo puoi, anche un wayside cross potrebbe trovarsi vicino una vetta. 


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Paolo Monegato wrote
> 
> Bah, son sempre stato del parere che per i niubbi una pagina come Map 
> features o come How to map a [1] sia più che sufficiente...
> 
> Ma il sistema da te 
> proposto, sempre se l'ho capito, mi sembra un'inutile complicazione.

Chiarissimo, come non detto allora; è evidente che se l'idea, oltre che
confusionaria, risulta inutile oltre che complicata è evidente che non solo
non migliorerebbe la situazione, ma risulterebbe addirittura
controproducente. Essendo tra l'altro le cose da te indicate già realizzate
immagino che la situazione wiki sia già sufficientemente adeguata per il suo
scopo e sia solo una questione di tempo . La confusione che trovo io nella
consultazione della wiki probabilmente è solo frutto della mia non
conoscenza di quella particolare pagina, mentre l'impressione di una
situazione tag ridondanti tendente a peggiorare e necessariamente solo
appunto una mia persolissima impressione.

direi a questo punto che conviene  provare  a migliorare quella
paginanoto che mancano moltissimi tag (anche i più banali come un po'
tutte le highway, porti, un po' tutti gli shop dai panettieri ai supermarket
) e vengono suggeriti alcuni di fatto sconsigliati (come landuse=farm) e
questo sicuramente non contribuisce alla sua efficacia...



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861896.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Alessandro]

Personalmente trovo (anche se dovrei dire *oggettivamente*) un gran 
casino nel tagging.
Se provate a fare qualcosa di serio è il primo grosso scoglio che dovete 
affrontare.


In questi giorni scaricando dei dataset regionali
http://www.regione.liguria.it/opendata/dati-cartografici.html
mi sono detto: iniziamo da qualcosa di semplice.

Ho preso un layer che pensavo fosse banale per incrociarlo con i dati 
all'interno di OSM. Ho scelto il layer "croce_isolata", un oggetto 
abbastanza univoco nella sua definizione.
Peccato che in OSM ci siano almeno queste definizioni che sono 
corrispondenti a croce_isolata (poi magari non le ho scoperte nemmeno 
tutte):


man_made=cross
man_made=summit_cross
summit:cross=yes
historic=wayside_cross

le occorrenze nel mondo e in Liguria di questi oggetti sono rispettivamente
1743, 1
132, 0
1372, 4
63433, 36

E questo con un oggetto relativamente semplice.
Ma c'è veramente bisogno di tutti questi tag? A mio avviso no, 
basterebbe un man_made=cross con tag primario, poi uno si può 
sbizzarrire con tutto quello che si vuole.
Che senso ha specificare che è un man_made=summit_cross quando posso 
capirlo dalla vicinanza con una vetta?
E historic=wayside_cross non basterebbe aggiungere anche lì un tag 
secondario, dal start_date a uno più generico?
E man_made=summit_cross VS summit:cross=yes che senso ha? Perchè c'è chi 
dice 'ma se la croce è sul punto di vetta?' Ma se la piazzi a 8cm da 
dove hai messo il natural=peak ti processano per crimini all'umanità???


Alessandro Ale_zena-IT



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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Paolo Monegato]

Il 06/12/2015 09:53, Aury88 ha scritto:

dieterdreist wrote

si,  purtroppo, la soluzione sarebbe di mettere a posto, non di cambiare
tutto per alcuni problemi parziali.

ma io non ho mai parlato di cambiare tutto, ne di cambiare qualcosa che non
sia la struttura del wiki (non viene cambiato neanche il contenuto del wiki,
cioè i tag suggeriti, solo come arrivi alle pagine).

Una volta posizionato un tag sotto un percorso logico, l'oggetto della
pagina rimane li...al massimo verrà aggiornato il tag suggerito. mettiamo
che passiamo dal considerare l'amenity=fuel un negozio e di conseguenza
avviamo un passaggio al key shop, la sua pagina sarà sempre sotto, per
esempio, ^/retestradale/attivitàcommerciale/vendità/benzina...ne più ne meno
che il cambiamento richiesto dall'attuale wiki


Non è che potresti fare un esempio concreto, tipo su una tua sandbox sul 
wiki?

Perché non è che si capisca tanto...


ergo una migliore documentazione (diciamo passo-passo) può essere di grande
aiuto ad evitare che qualcuno inserisca un tag nuovo per una cosa già
mappata...almeno per i niubbi.


Bah, son sempre stato del parere che per i niubbi una pagina come Map 
features o come How to map a [1] sia più che sufficiente... forse 
potrebbe servire anche una pagina tipo questa [2]. Ma il sistema da te 
proposto, sempre se l'ho capito, mi sembra un'inutile complicazione.


ciao
Paolo M

[1] http://wiki.openstreetmap.org/wiki/IT:Glossario_OSM
[2] http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Federico Leva (Nemo)]

Scusate, rispondo senza aver letto tutto. Storicamente, secondo me i 
principalissimi problemi del wiki OSM sono due:
1) organizzazione multilingue pessima, rimasta a pratiche che erano 
obsolete già 10 anni fa (traduzione difficile, sincronizzazione 
inesistente): la soluzione è pronta e si chiama Translate, il consenso 
c'è e la conversione può essere graduale 
https://wiki.openstreetmap.org/wiki/Talk:Wiki_Translation#Translate_extension 
;
2) duplicazione non-linguistica delle informazioni, per esempio fra 
pagine specifiche dei tag e pagine con tabelle che sintetizzano piú tag: 
la soluzione è come minimo una transclusione via 
LabeledSectionTransclusion, al meglio un sistema semantico con SMW o Cargo.


Nemo

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Alessandro]

Il 06/12/2015 10:17, Aury88 ha scritto:


  l'idea di questa mail era discutere del wiki e discutere di possibili
miglioramenti. se, come giustamente dici tu, siamo solo in 2 ad essere
d'accordo nella mailinglist nazionale, che possibilità ha l'idea di
"sfondare" proponendola in un altra wiki dove la discussione in inglese
sarebbe necessariamente meno approfondita e chiara?
A mio avviso se un idea non prende neanche a livello nazionale è poco utile
proporla ad una mailinglist internazionale...



Già. Proviamo a vedere quante persone sono d'accordo (sperando non parta 
un mailstorm da migliaia-di-messaggi-moltissimi-inutili).


Alessandro Ale_zena_IT

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Marcello]

Sono assolutamente d'accordo al riordino del wiki. Tanto per far capire
quanto è arduo in alcune occasioni, almeno per me, districarmi tra le
varie pagine che a volte si possono trovare sullo stesso argomento,
adesso parto dal link che trovo nei preset di JOSM, almeno spero di
arrivare direttamente alla versione più diffusa.

Altro argomento che è off-topic rispetto al titolo del thread ma era
emerso durante la discussione è la proliferazione dei tag. Sono
d'accordo che se non c'è un tag corrispondente a quanto si vuole mappare
si può utilizzare un tag nuovo, ma credo che prima di fare l'upload
l'editor dovrebbe avvisare che si sta aggiungendo un tag per il quale
non trova corrispondenza. Ho fatto una prova con Josm, che a differenza
degli altri editor fa un controllo formale sui dati, ho scritto syop
invece di shop come potrebbe avvenire per un errore di battitura,
caricato senza nessun avviso. Controllando con Taginfo molti dei tag
meno utilizzati contengono errori di battitura o hanno l'iniziale
maiuscola, se si riuscisse ad arginare questi errori si avrebbero meno
tag e più dati utili.

Ciao
Marcello

Il 06/12/2015 16:16, Alessandro ha scritto:
> Il 06/12/2015 10:17, Aury88 ha scritto:
>>
>>   l'idea di questa mail era discutere del wiki e discutere di possibili
>> miglioramenti. se, come giustamente dici tu, siamo solo in 2 ad essere
>> d'accordo nella mailinglist nazionale, che possibilità ha l'idea di
>> "sfondare" proponendola in un altra wiki dove la discussione in inglese
>> sarebbe necessariamente meno approfondita e chiara?
>> A mio avviso se un idea non prende neanche a livello nazionale è poco
>> utile
>> proporla ad una mailinglist internazionale...
>>
>
> Già. Proviamo a vedere quante persone sono d'accordo (sperando non
> parta un mailstorm da migliaia-di-messaggi-moltissimi-inutili).
>
> Alessandro Ale_zena_IT
>
>


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Alessandro wrote
> Premesso si tratta di un argomento importante, anche se ne discuterete 
> per 2 o 3000 mail per venirne a capo rimarrete in 2 ad essere d'accordo 
> mentre il resto del mondo continuerà ad andare avanti come prima.
> Per raggiungere un minimo di scopo occorre discuterne sulla mailing-list 
> del tagging (Martin ultimamente ne sà qualcosa con la discussione delle 
> subaree :-) )

 l'idea di questa mail era discutere del wiki e discutere di possibili
miglioramenti. se, come giustamente dici tu, siamo solo in 2 ad essere
d'accordo nella mailinglist nazionale, che possibilità ha l'idea di
"sfondare" proponendola in un altra wiki dove la discussione in inglese
sarebbe necessariamente meno approfondita e chiara?
A mio avviso se un idea non prende neanche a livello nazionale è poco utile
proporla ad una mailinglist internazionale...
Visto che siamo solo in 2 a ritenere che il wiki, così com'è, diventi ogni
giorno che passa potenzialemente meno chiara, sopratutto per i nuovi
arrivati, si vede che o non è un problema percepito o non è la soluzione che
alla community interessa o ritiene efficace.


> Poco fa ho trovato barrier=czech_hedgehog (su taginfo 3 presenze ma ha 
> la sua bella pagina wiki) e volevo piangere.
> Non ho tempo però perchè sto lavorando a una cross reference su alcuni 
> layer del DBtopo della Regione Liguria.
> Nel caso suesposto mi chiedo se non potevano infilarla sotto 
> barrier=qualcosa e poi barrier:type=tutto_quello_che _diavolo_vogliono

si e no...nel senso che nessuno lo impedisce, ma visto che il tipo di
barriera  viene normalmente specificato direttamente come il value di
barrier non mi sembra errata.

L'idea dei sottotag è quella di non aumentare troppo i tag principali...se
per esempio esistesse una decina di bariere militari anti-nave un altra
anti-carro un altra anti-qualcosa si sarebbe potuto raggrupparle sotto un
generico barrier=military e poi specificare sotto type, oppure fare un
barrier=anti_qualcosa per ciascuno e poi specificare sotto ciascuno la
tipologia...non so quante siano i tipi di barriere militari o comunque
concettualmente raggruppabili quindi non so se conveniva creare un sottotag
o se invece non fosse più giusta la scelta fatta.

la mia proposta non avrebbe impedito la creazione di quel tag se non ce ne
fosse stato un altro utilizzabile...forse avrebbe  favorito l'uso di
sottotag ma solo se esisteva già una ramificazione che comprendesse
concettualmente anche questo tipo di barrier ...non so se mi sono spiegato
bene...



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861799.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

dieterdreist wrote
> si,  purtroppo, la soluzione sarebbe di mettere a posto, non di cambiare
> tutto per alcuni problemi parziali.

ma io non ho mai parlato di cambiare tutto, ne di cambiare qualcosa che non
sia la struttura del wiki (non viene cambiato neanche il contenuto del wiki,
cioè i tag suggeriti, solo come arrivi alle pagine).

Una volta posizionato un tag sotto un percorso logico, l'oggetto della
pagina rimane li...al massimo verrà aggiornato il tag suggerito. mettiamo
che passiamo dal considerare l'amenity=fuel un negozio e di conseguenza
avviamo un passaggio al key shop, la sua pagina sarà sempre sotto, per
esempio, ^/retestradale/attivitàcommerciale/vendità/benzina...ne più ne meno
che il cambiamento richiesto dall'attuale wiki

il cambiare tutto è quello che proponi tu: modificare degli elementi già
inseriti sulla mappa, cosa che di fatto non si è mai fatta e più un tag è
diffuso, per quanto ridondante esso sia, più e difficile che venga fatto.non
dico che sia impossibile, dico che nessuno lo ha mai fatto e più passa il
tempo meno è probabile, e questo perchè non si è sicuri che un tag
ridondante/sinonimo in realtà non sia stato usato per indicare qualcosa di
leggermente differente (se è stato usato un altro tag ci potrebbe essere
pure un motivo, no? a meno che non si dia per scontato l'ignoranza del
mappatore).

la mia idea non era di modificare il wiki per far modificare i tag...che sia
amenity o shop poco importa (anche se sarebbe meglio mantenere una logica)
purchè ci sia univocità sul significato del tag. la mia idea era modificare
la struttura del wiki in modo tale che il tag scelto sia quello ottenuto
tramite percorso logico contestualizzato ,cioè fatto per selezionare tra i
50 tipi di erba quello che mi serve per il contesto in oggetto della
mappatura...essendo il contesto perso ormai in molti dei key in questa
maniera lo si preserva nella logica del wiki seguita nell'aggiungere il key.
questa cosa evita a mio avviso:
 1) che un tag usato per un preciso ambito possa venir utilizzato in un
altro 
 2) che un tag usato per un preciso ambito non venga trovato/notato da uno
che cercava quel tipo di tag.

a mio avviso una volta che si è inserito un tag ridondante o errato può
essere già troppo tardi...bisogna puntare sul primo inserimento corretto e
non puntare su un qualcuno che passando nota l'"errore", lo interpreti come
tale (cioè abbia certezza che sia una ridondanza e non l'indicazione di un
qualcosa di differente) e lo modifichi.
 ergo una migliore documentazione (diciamo passo-passo) può essere di grande
aiuto ad evitare che qualcuno inserisca un tag nuovo per una cosa già
mappata...almeno per i niubbi.





-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861797.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Marcello Arcangeli wrote
> Altro argomento che è off-topic rispetto al titolo del thread ma era
> emerso durante la discussione è la proliferazione dei tag. Sono
> d'accordo che se non c'è un tag corrispondente a quanto si vuole mappare
> si può utilizzare un tag nuovo, ma credo che prima di fare l'upload
> l'editor dovrebbe avvisare che si sta aggiungendo un tag per il quale
> non trova corrispondenza. Ho fatto una prova con Josm, che a differenza
> degli altri editor fa un controllo formale sui dati, ho scritto syop
> invece di shop come potrebbe avvenire per un errore di battitura,
> caricato senza nessun avviso. Controllando con Taginfo molti dei tag
> meno utilizzati contengono errori di battitura o hanno l'iniziale
> maiuscola, se si riuscisse ad arginare questi errori si avrebbero meno
> tag e più dati utili. 

non credo sia proprio OT...alla fine, almeno per me, è una conseguenza più o
meno diretta della, almeno per me, confusione del wiki.

quello è un lavoro che faccio ogni tanto, cioè andare sul taginfo e
verificare i tag che compaiono una o comunque poche volte..però sono in
grado di agire solo su quelli appunto effettivamente frutto di refuso o
l'uso scorretto di plurali o termini americani al posto di quelli inglesi
(probabilmente ne esistono alcuni in altre lingue ma io sono in grado di
correggere solo quelli italiani ed inglesi)...in questi casi devo dire che
mi conforta il fatto di trovarli molto spesso già corretti, indice comunque
di un attenzione molto alta su questo tema. il problemi rimangono i sinonimi
che come non correggo io temo non li corregga nessuno o pochi.

stavo pensando anche io ad una cosa come un messaggio di avvertimento per i
value nuovi...sarei stato curioso in particolare di vedere come cambierebbe
la situazione se all'atto dell'inserimento di un value nuovo venisse
richiesta una breve descrizione del nuovo tag a fini documentativi
(moltissimi tag non sono descritti nel wikie si trovano solo in taginfo ma
senza info) non credo però quella fosse una strada praticabile...mentre il
semplice avviso non vedo particolari problematiche e potrebbe essere davvero
molto utile e probabilmente più efficacie di un wiki organizzato
diversamente.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861833.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 11:24 schrieb Aury88 :
> 
> la mia idea era il rendere accessibile
> il tag dopo esserci arrivato con un percorso logico che ti costringe a
> legare il tag alla situazione.
> tu non cerchi più erba, cerchi l'erba nella pastorizia; non cerchi più
> l'oggeto, ma l'oggetto all'interno di uno specifico contesto...quanto meno
> questo  ti permette di escludere molti dei tag e quindi permettere di
> concentrarsi su una lista molto più breve e magari anche il più svogliato
> comincia a leggersi la descrizione.


ben venga, sono davvero curioso di provare il tuo sistema!

Anche a me piacerebbe poter offrire un sistema guidato ai mappatori 
occasionali, per esempio per aggiungere (il proprio) negozi(o) (quindi 
comincerei con un campo delimitato, dove c'è la speranza di creare una cosa 
sufficientemente completa per essere utile).

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

Am 05.12.2015 um 12:33 schrieb Aury88 :

>> non è così:
>> http://taginfo.openstreetmap.org/reports/historic_development#num_tags
> 
> cosa non è così? il fatto che ci sia una crescita quasi continua con ormai
> oltre le 55000 keys, gli oltre 70'000'000 tags, (che naturalmente è molto
> pompato per quei value tipo wikipedia, contact:*, ref:vatin, website,name...
> che devono essere tra loro necessariamente differenti ) e ben 500 tipi di
> relazioni in cosa smentirebbero la mia affermazione? e quali delle mie
> affermazioni smentirebbero? sul fatto che la situazione rischi di diventare
> sempre più confusionaria o sulla necessità di una struttura locica per
> discriminare le situazioni e quindi i tag utilizzati?


si, hai ragione (scusa la brevità del mio post, sto malato al letto). Cosa 
volevo dire: in realtà se vedi periodi più lunghi, ogni tanto c'è uno sforzo di 
correggere i tipo e si abbassa un po'. La quantità enorme di keys a mio avviso 
è dovuto oltre agli errori di digitazione anche agli import che introducono 
nuove chiavi del tipo dataset:name ecc.
Poi che i tags sono tanti è come dici tu dovuto a valori individuali per chiavi 
come note, name, ref, description, website, Wikipedia ecc.

Non vorrei negare in generale che inserire delle cose in osm è complesso, ma 
non vedo via d'uscita. Guarda quante parole hanno le lingue, e non è un caso o 
esagerato, quelle parole servono per essere precisi e per farsi capire nel 
dettaglio.

C'era 5 anni fa una proposta per un sistema che avrebbe introdotto un livello 
di astrazione:  
http://wiki.openstreetmap.org/wiki/SotM_2010_session:_Tag_Central:_a_Schema_for_OSM

Attualmente sia josm che iD offrono un livello di astrazione per i tags 
(presets). Quello di iD non mi piace particolarmente perché si basa sui numeri 
"nudi", e quelli possono essere non significativi per al meno due motivi 
(imports e numero assoluto basso). L'altro giorno ho cercato un tag per una 
galleria d'arte (ho cercato "gallery ") e mi ha restituito "shop=art" ma non mi 
ha restituito tourism =gallery. Visto che nella "mia" galleria d'arte non si 
vendevano le opere il tag sarebbe stato sbagliato (e senza guardarmi i tags non 
mi sarei nemmeno accorto). 
Per me la soluzione è quella di creare un vocabolario con tags che poi si usano 
in combinazione (chiave/valore), dove le chiavi hanno un significato, per 
esempio 'natural' attualmente non ha più significato perché la gente lo ha 
interpretato diversamente e hanno messo dei valori nuovi che non sono più 
unificabili sotto una definizione comune.

In generale, anche se vedo problemi nel dettaglio, per me in grosso modo 
funziona;-)
Uno dei problemi grossi è quello di cercare per forza un tag esistente e 
assimilabile mentre in realtà si vorrebbe un tag nuovo, perché così si svaluta 
anche tutto il resto che ha già questo tag, e di cui si perde la definizione 
esatta.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 14:16 schrieb Stefano :
> 
> Anche a me piacerebbe poter offrire un sistema guidato ai mappatori 
> occasionali, per esempio per aggiungere (il proprio) negozi(o) (quindi 
> comincerei con un campo delimitato, dove c'è la speranza di creare una cosa 
> sufficientemente completa per essere utile).
> 
> http://su.openstreetmap.it
> 


si, esattamente così, ma in automatico. Ho provato di inserire un panificio ma 
non ha trovato alcuna categoria (forse un problema del accesso tramite 
telefonino, le liste erano sempre tutte vuote e l'indirizzo suggerito era a 
Genova mentre ho messo l indicatore su una posizione a Roma).

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Ok, quindi, se ho capito, ti riferivi al fatto che si è cercato in certi
periodi di limitare il numero di tag. a mio avviso quella è una conferma di
quanto dico: oltre ad essere un problema sentito anche da altri, senza una
buona documentazione alla base continuerà ad esserci qualcuno che si inventa
un tag per indicare una cosa già taggata...per quanto ci si sforzi, per
quanto si intervenga sui tag unici, che pure vengono elencati da taginfo, i
tag aumentano e questo perchè non tutti conoscono taginfo e non tutti
trovano quello che cercano su wiki e taginfo. penso che molto sia dovuto al
fatto che il tag sono messi in un elenco, non in una disposizione logica.


dieterdreist wrote
> Per me la soluzione è quella di creare un vocabolario con tags che poi si
> usano in combinazione (chiave/valore), dove le chiavi hanno un
> significato, per esempio 'natural' attualmente non ha più significato
> perché la gente lo ha interpretato diversamente e hanno messo dei valori
> nuovi che non sono più unificabili sotto una definizione comune.

si, il vocabolario era un'altra possibilità ma non è sempre applicabile.
molto spesso il significato di un termine lo si capisce dal contesto non
dalla parola in se. si dovrebbe quindi specificare per la parola  i contesti
in cui potrebbe venire considerata, con associato per ciascuno il tag o la
combinazione di tag.
L'idea del vocabolario era in parte integrata nella mia idea quando
proponevo di etichettare le varie voci con il relativo termine (e sinonimi)
nelle varie lingue...ma come via da seguire in più e permettendo comunque di
trovare la parola ma contestualizzata, cioè trovi direttamente la pagina ma
vedi anche in che "ramificazione" si trova.

Quella del vocabolario credo sia una strada  percorribile con l'attuale
wiki...magari tramite una sorta di  template (purchè i termini elencati
siano ricercabili) applicato ad ogni pagina, ma la mia idea comunque non era
solo risolvere le problematiche relative la scelta del/i tag, ma anche come
essi vengono applicati. come si influenzino l'un l'altro. il tutto in una
struttura il più modulare e standardizzata possibile in modo da rendere non
solo la ricerca, ma anche la consultazione il più facile possibile.


> Uno dei problemi grossi è quello di cercare per forza un tag esistente e
> assimilabile mentre in realtà si vorrebbe un tag nuovo, perché così si
> svaluta anche tutto il resto che ha già questo tag, e di cui si perde la
> definizione esatta.

se ho capito la frase tu dici che il problema è il cercare di usare un tag
già esistente per indicare qualcosa di nuovo, e che facendo così si
pregiudica il significato di quel tag per tutti gli elementi in qui quel tag
è applicato correttamente, giusto?
sono d'accordo ma sono dell'idea che questo sia una problematica dovuta al
fatto che, vista l'enormità di tag, si lavori per similitudine. cioè si
sceglie un tag che per significato è molto simile a quello che si sta
inserendo visto che è già documentato e largamente usato (e magari
renderizzato). succede pure questo, ma molto spesso succede il contrario
secondo me: quello che sto cercando lo si otterrebbe con una combinazione di
tag già esistenti , ma si fa molto prima ad inventarsi un tag nuovo...
il problema è che il secondo che passa non sa se usare la combinazione di
tag o usare il tag nuovo...in una qualche misura anche il tag nuovo svaluta
la scelta già fatta (perchè si è mappata in un altra maniera? forse
significa una cosa diversa? essendo nuovo e più breve come tag è da
preferire al vecchio frutto di combinazione?) (ps: io preferisco se
possibile la combinazione di (sub)tag già esistenti all'utilizzo di un nuovo
tag ma difficilmente un nuovo utente potrebbe preferire una cosa del genere)

non dico che il sistema da me proposto risolva al 100% la situazione, ma per
gli elementi più comuni l'imporre una logica/percorso guidato alla base
della scelta potrebbe permettere di scoprire qualche tag in più ed evitare
di inventarsene uno nuovo almeno per quelli principali.
 

poi ripeto che è una  cosa in più (due se consideriamo anche le etichette
riferite il vocabolo) rispetto l'attuale situazione ad elenco (che a mio
avviso dovrebbe poter essere richiamato in qualsiasi momento/pagina), di
conseguenza non dovrebbe peggiorare la fuibilità attuale, se mai, nel
peggiore dei casi, risulta totalmente inutile.

Buona guarigione ;-) 




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861737.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Stefano]

On Dec 5, 2015 1:54 PM, "Martin Koppenhoefer" 
wrote:
>
>
>
> sent from a phone
>
> > Am 05.12.2015 um 11:24 schrieb Aury88 :
> >
> > la mia idea era il rendere accessibile
> > il tag dopo esserci arrivato con un percorso logico che ti costringe a
> > legare il tag alla situazione.
> > tu non cerchi più erba, cerchi l'erba nella pastorizia; non cerchi più
> > l'oggeto, ma l'oggetto all'interno di uno specifico contesto...quanto
meno
> > questo  ti permette di escludere molti dei tag e quindi permettere di
> > concentrarsi su una lista molto più breve e magari anche il più
svogliato
> > comincia a leggersi la descrizione.
>
>
> ben venga, sono davvero curioso di provare il tuo sistema!
>
> Anche a me piacerebbe poter offrire un sistema guidato ai mappatori
occasionali, per esempio per aggiungere (il proprio) negozi(o) (quindi
comincerei con un campo delimitato, dove c'è la speranza di creare una cosa
sufficientemente completa per essere utile).

http://su.openstreetmap.it
>
> ciao
> Martin
> ___
> 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] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 14:45 schrieb Aury88 :
> 
> senza una
> buona documentazione alla base continuerà ad esserci qualcuno che si inventa
> un tag per indicare una cosa già taggata...per quanto ci si sforzi, per
> quanto si intervenga sui tag unici, che pure vengono elencati da taginfo, i
> tag aumentano e questo perchè non tutti conoscono taginfo e non tutti
> trovano quello che cercano su wiki e taginfo. penso che molto sia dovuto al
> fatto che il tag sono messi in un elenco, non in una disposizione logica.


ripeto, il problema di avere più tag per dire la stessa cosa è piccolissimo e 
facilmente risolvibile poi, il vero problema è avere lo stesso tag ma messo con 
intenzioni diversi (proprio il pericolo principale di taginfo). Sapere che un 
tag è molto diffuso comunque non ti dice niente sul suo utilizzo...

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 14:45 schrieb Aury88 :
> 
> si, il vocabolario era un'altra possibilità ma non è sempre applicabile.
> molto spesso il significato di un termine lo si capisce dal contesto non
> dalla parola in se


intendevo con quello che abbiamo: chiave =contesto, valore=specifico (es. shop 
vuol dire che si vende qualcosa, il valore dice che cos'è che si vende).

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

dieterdreist wrote
> intendevo con quello che abbiamo: chiave =contesto, valore=specifico (es.
> shop vuol dire che si vende qualcosa, il valore dice che cos'è che si
> vende).

sei stato proprio tu a dire che le  key natural sono state
decontestualizzate, e chissà quali altre... metà dei value praticamente poi
è sotto contesto amenity...ci sono tag sia sotto amenity sia sotto leisure
per indicare la stessa identica cosa. alcuni che usano indistintamente
landuse/landcover/natural ecc ecc
temo che in questo caso la strada non sia più percorribile, se non solo per
i nuovi tag.
se poi parliamo di value nello shop per indicare cosa si vende temo sia
quasi impossibileper esempio ci sono panifici che vendono solo pane,
panifici che vendono pane e dolci, panifici che vendono solo dolci.
negozi di vestiti che vendono anche intimo altri che vendono in più occhiali
e/o altri accessori, altri che vendono anche scarpe altri che hanno alcuni
di questi prodotti dedicati solo ad un genere ed altri ad entrambi.
negozi di ferramenta che vendono batterie e accendini o che ti rifanno le
chiavi (è un servizio o una vendita?) o ti aggiungono buchi alla cintura...
sarebbe potuto essere fattibile forse con sotto key riferiti ai singoli
prodotti un po' come si fa con i carburanti in amenity=fuel (che di per se
sarebbe più un negozio) o i materiali raccolti quando si parla di
spazzatura, ma shop="cosa viene venduto" non sempre è adeguato se non solo
per dare una indicazione molto generica...per ogni sfumatura potrebbe
nascere un nuovo tag ed essendo migliaia le sfumature i tag che possono
nascere per ciascuno potrebbero presto diventare decine e decine visto che
nessuno sarebbe più in grado di trovare un tag adeguato.

no, a mio avviso non è assolutamente facilmente risolvibile come dici tu:
chi controlla trova un tag  per una cosa che lui ha mappato con un tag
differente, cosa fa? modifica con il rischio di eliminare una differenza?
direi che probabilmente tiene quel tag così com'è non potendo essere certo
che quel negozio sia al 100% come l'altro che lui ha taggato nell'altra
manierae infatti quasi mai si è eliminato value ridondanti...quasi
sempre si è intervenuto su value con refusi o su doppioni evidenti (plurale,
termine americano, maiuscole)...ci sono ancora pagine che pur dicendo
chiaramente che un tag non va usato dimostrano come ancora quel tag sia
largamente usato e continuino a spuntare elementi taggati nel modo
errato...si è intervenuto per correggere? assolutamente no, sarebbe ormai un
edit di massa! la situazione sta migliorando? assolutamente no! il tag
scorretto continua a venir usato e tanto è più diffuso tanto più viene
usato.


imho quindi : la ridondanza non è facilmente risolvibile,
 la ridondanza è un danno per la mappa i mappatori e gli utilizzatori
 la ridondanza confonde e rischia di farti creare un ennesimo tag
ridondante= si autoalimenta
la ridondanza non aiuta in alcun modo a creare un tag adeguato quando
necessario...semplicemente ti lascia sempre nel dubbio di non aver trovato
un tag giusto già utilizzato.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861748.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 18:37 schrieb Alessandro :
> 
> Comunque, nelle P.A. il problema è opposto: estrema semplificazione.


si e no, a livello topografico le CTR hanno tante cose che noi non mappiamo 
(ancora), e distinguono cose che da noi sono unificate , cfr 
http://www2.provincia.pc.it/cartografico/Cartografia/img/elab_tem/Legenda_CTR.PDF

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 17:38 schrieb Aury88 :
> 
> , ma shop="cosa viene venduto" non sempre è adeguato se non solo
> per dare una indicazione molto generica...per ogni sfumatura potrebbe
> nascere un nuovo tag ed essendo migliaia le sfumature i tag che possono
> nascere per ciascuno potrebbero presto diventare decine e decine visto che
> nessuno sarebbe più in grado di trovare un tag adeguato.


la mia soluzione per questo problema è sells:prodotto =yes
Non cambia automaticamente il genere di negozio solo perché vende una cosa in 
più. Già una cosa semplice come un negozio di scarpe può avere tante forme (e 
meritarsi davvero un altro tag principale), per esempio la distinzione in 
scarpe da donna e scarpe da uomo e scarpe da bimbo. Un uomo non fa niente in un 
negozio di scarpe da donna. Oppure scarpe eleganti e scarpe sportive. Negozi 
con solo stivali e tacchi a spillo, negozi che vendono solo un marchio...
Oppure vestiti. Non distinguiamo nemmeno tra negozi per maschi e per femmine, 
completamente inutile per scopi reali come trovare un negozio per comprare, se 
OSM fosse stato fatto prevalentemente da donne non sarebbe così;-)

Invece le cose semplici come un panificio che vende anche pneumatici è risolto, 
ci metti sells:tyres=yes al shop=bakery

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Alessandro]

Premesso si tratta di un argomento importante, anche se ne discuterete 
per 2 o 3000 mail per venirne a capo rimarrete in 2 ad essere d'accordo 
mentre il resto del mondo continuerà ad andare avanti come prima.
Per raggiungere un minimo di scopo occorre discuterne sulla mailing-list 
del tagging (Martin ultimamente ne sà qualcosa con la discussione delle 
subaree :-) )


Poco fa ho trovato barrier=czech_hedgehog (su taginfo 3 presenze ma ha 
la sua bella pagina wiki) e volevo piangere.
Non ho tempo però perchè sto lavorando a una cross reference su alcuni 
layer del DBtopo della Regione Liguria.
Nel caso suesposto mi chiedo se non potevano infilarla sotto 
barrier=qualcosa e poi barrier:type=tutto_quello_che _diavolo_vogliono


Comunque, nelle P.A. il problema è opposto: estrema semplificazione.

Alessandro Ale_Zena_IT


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 17:38 schrieb Aury88 :
> 
> sei stato proprio tu a dire che le  key natural sono state
> decontestualizzate, e chissà quali altre...


si,  purtroppo, la soluzione sarebbe di mettere a posto, non di cambiare tutto 
per alcuni problemi parziali.


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 17:38 schrieb Aury88 :
> 
> si è intervenuto per correggere? assolutamente no, sarebbe ormai un
> edit di massa!


mica non si possono fare, basta annunciarli, documentare precisamente e non 
avere pareri contrastanti contro di se...


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 10:49 schrieb Aury88 :
> 
> La situazione ogni giorno diventa più confusionaria...più aumentano i tag
> meno sarà possibile trovare il tag giusto quindi è necessario una struttura
> logica che permetta a mio avviso di dicriminare/selezionare il più possobile
> tra le migliaia di soluzioni.



non è così:
http://taginfo.openstreetmap.org/reports/historic_development#num_tags


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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Fabrizio Tambussa]

Perché non producete un documento con un'idea e una proposta di
riorganizzazione?
Sarebve più semplice da leggere e da mostrare in giro.
Saluti
Il 05/Dic/2015 11:57, "Martin Koppenhoefer"  ha
scritto:

>
>
> sent from a phone
>
> > Am 05.12.2015 um 10:49 schrieb Aury88 :
> >
> > La situazione ogni giorno diventa più confusionaria...più aumentano i tag
> > meno sarà possibile trovare il tag giusto quindi è necessario una
> struttura
> > logica che permetta a mio avviso di dicriminare/selezionare il più
> possobile
> > tra le migliaia di soluzioni.
>
>
>
> non è così:
> http://taginfo.openstreetmap.org/reports/historic_development#num_tags
>
>
> ciao
> Martin
> ___
> 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] La nostra wiki, come è e come dovrebbe essere

[Aury88]

dieterdreist wrote
> 
> non è così:
> http://taginfo.openstreetmap.org/reports/historic_development#num_tags

cosa non è così? il fatto che ci sia una crescita quasi continua con ormai
oltre le 55000 keys, gli oltre 70'000'000 tags, (che naturalmente è molto
pompato per quei value tipo wikipedia, contact:*, ref:vatin, website,name...
che devono essere tra loro necessariamente differenti ) e ben 500 tipi di
relazioni in cosa smentirebbero la mia affermazione? e quali delle mie
affermazioni smentirebbero? sul fatto che la situazione rischi di diventare
sempre più confusionaria o sulla necessità di una struttura locica per
discriminare le situazioni e quindi i tag utilizzati?





-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861728.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 09:06 schrieb Aury88 :
> 
> Per esempio: in una situazione come l'avere 5 tag differenti per indicare la
> stessa cosa facilmente diventa equivalente all'aver mappato 1/5 degli
> elementi e se si vogliono trovare tutti gli elementi  è facile che questo
> comporti per gli utilizzatori un lavoro 5 volte maggiore...



si, ma la priorità è sempre stata quella che deve essere facile per chi mappa, 
non facile per chi usa i dati. In realtà, avere 5 tag per dire la stessa cosa 
non è un grosso problema, anche se non è desiderabile, crea soltanto un poco 
più di lavoro per interpretare i dati. Il vero problema è il contrario: avere 
un tag che vuol dire cose diverse secondo il contesto/mappatore, e quindi 
diventa impossibile interpretare il senso.


> se poi
> consideriamo la variabile nodo/way/relazione il lavoro per lo stesso tipo di
> elemento dell'esempio può diventare 15 volte superiore.


questo non capisco 


> Il problema esplode velocemente se si considerano anche le combinazioni
> possibili di tag...


anche qui non capisco. 

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

dieterdreist wrote
> si, ma la priorità è sempre stata quella che deve essere facile per chi
> mappa, non facile per chi usa i dati. In realtà, avere 5 tag per dire la
> stessa cosa non è un grosso problema, anche se non è desiderabile, crea
> soltanto un poco più di lavoro per interpretare i dati. Il vero problema è
> il contrario: avere un tag che vuol dire cose diverse secondo il
> contesto/mappatore, e quindi diventa impossibile interpretare il senso.

non sono d'accordo...un utente esperto probabilmente sceglie il tag più
usato un utente inesperto non sapendo quale scegliere probabilmente va a
caso o non lo aggiunge non volendo inserire errori o aggiunge un tag che
ritiene più appropriato.

se fosse vero che la mappa dovrebbe essere facile per chi mappa ognuno
taggherebbe gli elementi mappati nella propria lingua...più facile di così,
giusto? invece no è il motivo è semplice...il dato poi deve poter essere
utilizzabile e più facile è meglio è.

io non trovo semplice cercare il tag giusto tra centinaia di tag che
aumentano ogni giorno con sinonimi in inglese che sottintendono
sfumature/similitudini o addirittura non sottonintendono nulla. quale
scelgo? non è che quello che ho scelto indica più un altra cosa?
il fatto che si usi un tag per indicare più cose non può essere frutto della
confusione determinata dall'avere tanti tag?


se la mappa non è utilizzabile la mappa è inutile. se la mappa facendo una
ricerca visualizza solo alcuni elementi e non gli stessi chiamati in un
altra maniera, è equivalente ad una mappa con solo mappati i primi chiamati
nel modo "giusto"...tempo fa luca si è lamentato di un utente che ha
cambiato il modo di indicare le capitali...e ne mancavano "solo"una 30-ina,
fai lo stesso ragionamento sui porti, sulle scuole, sui negozi, sulle
palestreuna mappa completa ma come se non lo fosse...

La situazione ogni giorno diventa più confusionaria...più aumentano i tag
meno sarà possibile trovare il tag giusto quindi è necessario una struttura
logica che permetta a mio avviso di dicriminare/selezionare il più possobile
tra le migliaia di soluzioni.



> questo non capisco 

leisure=gym (node),leisure=gym (way),leisure=gym (relation),ammenity=gym
(node),ammenity=gym (way);ammenity=gym (relation),leisure=pitch+sport=gym
(node),leisure=pitch+sport=gym (way),leisure=pitch+sport=gym
(relation),leisure=fitness(node),leisure=fitness(way),
leisure=fitness(relation), amenity=fitness(node), amenity=fitness(way),
amenity=fitness(relation)
amenity=sport+sport=gym(node), amenity=sport+sport=gym(way),
amenity=sport+sport=gym(relation),
amenity=sport+sport=fitness(node), amenity=sport+sport=fitness(way),
amenity=sport+sport=fitness(relation)
l'ultima volta che ho controllato c'erano 15 tag differenti applicati a
nodi, way e relation e in alcune api devi specificare il tipo di elemento.







-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861721.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

Ciao a tutti,
 volevo, aprire questa discussione perchè a mio avviso uno dei punti di
forza di OSM, e cioè il tagging flessibile, può diventare un serio problema
ed una grossa debolezza se non si riesce a fornire una documentazione
adeguata per i tag già in uso.
Una wiki mal strutturata, incompleta e/o"difficile" è più facile che non
venga letta o quanto meno compresa, specialmente dagli utenti meno esperti.
Per esempio: in una situazione come l'avere 5 tag differenti per indicare la
stessa cosa facilmente diventa equivalente all'aver mappato 1/5 degli
elementi e se si vogliono trovare tutti gli elementi  è facile che questo
comporti per gli utilizzatori un lavoro 5 volte maggiore...se poi
consideriamo la variabile nodo/way/relazione il lavoro per lo stesso tipo di
elemento dell'esempio può diventare 15 volte superiore.
Il problema esplode velocemente se si considerano anche le combinazioni
possibili di tag...
Tutto questo può essere attenuato in varie maniere: tool di QA,
miglioramento delle history, una migliore formazione degli utenti, tool di
auto-completamento nell'inserimento (come in iD) e l'informazione.

La nostra "informazione" è fatta tramite wiki ma è un macello da
esplorare...se una persona non conosce un tag, ma solo come un elemento
viene chiamato comunemente nella propria lingua, può risultare difficile
risalire al tag adeguatose la cosa che cerca non è messa nella lunga
lista di tag o è messa con una descrizione approssimativa o anche solo è
sprovvista di foto, può succedere che l'utente non riesca a capire che
quello che sta guardando è il tag che gli serve.

Il problema diventa più grave con mappatori inesperti che tenderanno a non
mappare o ad inventarsi un tag nuovo ma anche i mappatori esperti potrebbero
avere qualche difficoltà: se non sul tag spesso la problematica si sposta
sullo stile, sul dove/come applicare i tag

Ricordiamoci che la forza di una catena è pari alla forza del suo anello più
debole...non possiamo sperare in un miglioramento della qualità della mappa
senza valutare il miglioramento degli strumenti alla base della sua
realizzazione...il concetto, a mio avviso giusto, secondo cui più sono gli
occhi che controllano più è facile che gli errori vengano notati e corretti,
non è così scontato nel nostro caso, infatti qui non parliamo di dati
oggettivamente sbagliati  o linee di codice buggate, parliamo di stili/tag
che possono essere tutti ugualmente corretti (visto che il sistema di
tagging lo consente).
Sperando che questa non sfoci in un flame, vorrei avviare una discussione
che ci porti a determinare punti di forza e debolezza della nostra wiki ed
eventuali cambiamenti.

Da questo anno abbiamo il vantaggio di collaborare più strettamente con
Wikimedia Italia e vista la loro indubbia esperienza nel settore
wiki/(in)formazione potrebbero aiutarci/guidarci in questa evoluzione che a
mio avviso diventa sempre più fondamentale ed imprescindibile.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Carlo]

Quello descritto da Aury88, a mio avviso è un argomento molto importante.
Parecchie volte mi sono venuti i dubbi mentre stavo mappando su quale tag mettere, specialmente quando ci sono tag multipli. Basta guardare un'altra discussioni di questi giorni, quella sugli oratori, è semplice mettere i tag monastery:type= name= ma uno che inizia da poco a mappare, non penso che avrebbe pensato di mettere anche amenity= , io lo avrei lasciato. Anche la discussione sui pannelli solari, io avrei messo quelle principali (tipo di impianto e sorgente), ma no i tag sulla produzione ed altro.
Quello che mi piacerebbe che uscisse fuori da questa discussione, è un sistema di auto-completamento o suggerimento per i tag, cioè mappo un edificio e il primo tag metto edificio (tutti fino a qui ci riescono), poi iniziano a comparire e suggerire altri tag, che tipo di edificio è, residenziale o commerciale, . così via a cascata con tutte le possibili informazioni che posso mettere.
Penso che in questo modo, anche un nuovo mappatore, basta che segue la sequenza dei suggerimenti riesce a completare il tutto

Ciao
Carlo


Ciao a tutti,
 volevo, aprire questa discussione perchè a mio avviso uno dei punti di
forza di OSM, e cioè il tagging flessibile, può diventare un serio problema
ed una grossa debolezza se non si riesce a fornire una documentazione
adeguata per i tag già in uso.
Una wiki mal strutturata, incompleta e/o"difficile" è più facile che non
venga letta o quanto meno compresa, specialmente dagli utenti meno esperti.
Per esempio: in una situazione come l'avere 5 tag differenti per indicare la
stessa cosa facilmente diventa equivalente all'aver mappato 1/5 degli
elementi e se si vogliono trovare tutti gli elementi  è facile che questo
comporti per gli utilizzatori un lavoro 5 volte maggiore...se poi
consideriamo la variabile nodo/way/relazione il lavoro per lo stesso tipo di
elemento dell'esempio può diventare 15 volte superiore.
Il problema esplode velocemente se si considerano anche le combinazioni
possibili di tag...
Tutto questo può essere attenuato in varie maniere: tool di QA,
miglioramento delle history, una migliore formazione degli utenti, tool di
auto-completamento nell'inserimento (come in iD) e l'informazione.

La nostra "informazione" è fatta tramite wiki ma è un macello da
esplorare...se una persona non conosce un tag, ma solo come un elemento
viene chiamato comunemente nella propria lingua, può risultare difficile
risalire al tag adeguatose la cosa che cerca non è messa nella lunga
lista di tag o è messa con una descrizione approssimativa o anche solo è
sprovvista di foto, può succedere che l'utente non riesca a capire che
quello che sta guardando è il tag che gli serve.

Il problema diventa più grave con mappatori inesperti che tenderanno a non
mappare o ad inventarsi un tag nuovo ma anche i mappatori esperti potrebbero
avere qualche difficoltà: se non sul tag spesso la problematica si sposta
sullo stile, sul dove/come applicare i tag

Ricordiamoci che la forza di una catena è pari alla forza del suo anello più
debole...non possiamo sperare in un miglioramento della qualità della mappa
senza valutare il miglioramento degli strumenti alla base della sua
realizzazione...il concetto, a mio avviso giusto, secondo cui più sono gli
occhi che controllano più è facile che gli errori vengano notati e corretti,
non è così scontato nel nostro caso, infatti qui non parliamo di dati
oggettivamente sbagliati  o linee di codice buggate, parliamo di stili/tag
che possono essere tutti ugualmente corretti (visto che il sistema di
tagging lo consente).
Sperando che questa non sfoci in un flame, vorrei avviare una discussione
che ci porti a determinare punti di forza e debolezza della nostra wiki ed
eventuali cambiamenti.

Da questo anno abbiamo il vantaggio di collaborare più strettamente con
Wikimedia Italia e vista la loro indubbia esperienza nel settore
wiki/(in)formazione potrebbero aiutarci/guidarci in questa evoluzione che a
mio avviso diventa sempre più fondamentale ed imprescindibile.



-
Ciao,
Aury
--
View this message in context: http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712.html
Sent from the Italy General mailing list archive at Nabble.com.

___
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] La nostra wiki, come è e come dovrebbe essere

[Aury88]

La situazione attuale è una lista di tag con una prima distinzione in base
alla key.
questo comporta che, a parte alcuni casi semplici come shop o highway "auto
esplicativi", l'utente deve cercare comunque l'elemento non a livello di key
ma a livello di value...gym è una amenity o una leisure?
l'erba è una landuse o una natural?
Tutto questo comporta che l'utente debba cercare scorrendo quasi ad uno ad
uno la lista di elementi; di conseguenza o non lo fa o il rischio è non
trovare l'elemento cercato.


A mio avviso la prima grossa distinzione dovrebbe essere una cosa come tra
aree urbana/agricola/mare/natura/politica o altro ritenuto più
appropriato...
seguita da una struttura ad albero per ciascuno di queste aree per guidare
l'utente verso una lista sempre più ristretta di elementi.
gli elementi presenti in più tipi di territori dovrebbero essere
presenti/ripetuti in ciscuna lista. Un parco lo è sia in un area industriale
sia in un area residenziale.
Pero ogni livello, se ci sono, devono essere visibili i tag associati quel
livello ed eventuali sotto tag (in una lista espandibile.) oltre che alla
descrizione dell'elemento
In ogni livello dovrebbe essere possibile switchare tra:
*come applicare il tag proponendo prima il caso più semplice (nodo) fino ad
arrivare al caso più complesso dell'area (con aree e relazioni al suo
interno con ad'esse applicati i sotto tag e/o i tag degli elementi del
livello subito inferiore  )
*visualizzazione di una lista di tutti i tag principali presenti in tutti i
sotto livelli (esclusi i sottotag) con una breve descrizione,
*la struttura ad albero inferiore e superiore il livello corrente.
*le ramificazione al livello inferiore con breve descrizione.


La navigazione è potenzialmente più lenta ma la possibilità di switchare
alla lista dei tag di tutti i livelli inferiori ripristinerebbe la
situazione attuale.


Come già detto ogni pagina con tag dovrebbe fornire una descrizione e
proporre per primo lo stile di mappatura più semplice (per esempio tramite
nodo) con relativi tag
Dopo dovrebbe proporre, se esiste, la mappatura più complessa fornendo un
esempio con alcuni dei tag della ramificazione al liv inferiore.
per esempio in urbano/residenziale/servizio/istruzione/superiore (da adesso
/~) mostrare che la scuola è un eventuale inner del landuse=residential
(riferimento al livello superiore) è un ammenity=school +name +addr +
livello scolastico (livello corrente) sull'area esterna e che al suo interno
si identificano aree amenity=parking, building=yes, leisure=recreation_groud
rispettivamente dai livelli /~/parcheggio, /~/edificio /~ricreazione
da notare che nei confronti del liv superiore si usa il caso semplice cioè
la scuola superiore a se stante ...mentre nel livello
urbano/residenziale/servizio/istruzione si presenta un caso complesso
riferito al livello inferiore (esempio una scuola elementare e media che
condividono lo stesso spazio)

se si decide di proseguire al livello /~/edificio l'esempio complesso
sarebbe stato l'area esterna amenity=school (quindi non più con riferimento
all'area ancora sopra cioè quella residenziale), il livello building avrebbe
indicati building=yes +name +ref (che sono dei sottotag del livello corrente
e quindi prima non comparivano), con suggerimento per i nodi entrance,
presenza di cestini, distributori dell'acqua, telecamere ...quest'ultimi
elementi dei livelli inferiori. In fondo un link per la pagina di regole/tag
generali sul'indoormapping

come si può vedere queste istruzioni accompagnano nel processo di
miglioramento della mappa, cioè nell'aggiunta di dettagli sia in termini di
oggetti sia in termini di tag

Sarebbe estremamente utile trovare dei casi mappati abbastanza complessi, ma
non troppo, riconosciuti dalla community come fatti ad arte e usati come
esempio/linkati nelle rispettive pagine.
La descrizione comunque dovrebbe essere accompagnata da un immagine
esplicativa che dica dove devono essere poste le way... (leisure marina è
solo lo specchio d'acqua o solo le terre emerse o entrambi?)

ogni pagina dovrebbe avere una lista di etichette che indichi come viene
chiamato l'elemento nelle varie lingue (compresi i sinonimi) natualmente per
permetterne la ricerca
non sarebbe male mettere su un sistema stile wikidata in modo da poter
essere visualizzate eventualmente dalle app per l'editing.

il lavoro lo so è enorme ma si potrebbe provare con solo alcuni dei tag più
importanti (2-3 livelli) e vedere come va...il tutto naturalmente in un wiki
parallelo a quello attuale.






-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861718.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Martin Koppenhoefer]

sent from a phone

> Am 05.12.2015 um 10:28 schrieb Aury88 :
> 
> l'erba è una landuse o una natural?


non c'è la semplicità perché il mondo non è semplice. L'erba è un mangime, una 
droga, una decorazione, una superficie di un campo da calcio, ...? 

"erba" non è ne landuse né natural. Può occorrere in contesti di landuse e di 
natural.

Concordo però che nel caso di natural e landuse c'è un grande casino. Avevo 
anni fa tentato di trovare un sistema /interpretazione semplice e logico ma non 
ho trovato abbastanza sostenitori (proposta landcover).

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

Re: [Talk-it] La nostra wiki, come è e come dovrebbe essere

[Aury88]

dieterdreist wrote
> sent from a phone
> 
>> Am 05.12.2015 um 10:28 schrieb Aury88 

> spacedriver88@

> :
>> 
>> l'erba è una landuse o una natural?
> 
> 
> non c'è la semplicità perché il mondo non è semplice. L'erba è un mangime,
> una droga, una decorazione, una superficie di un campo da calcio, ...? 

esatto!...è in un lunghissimo elenco, con ad un certo punto grass, qualcuno
lo userà per indicare un campo per la pastorizia anche se subito sotto (dopo
soli magari altri 50 tag landuse) c'è meadow...il problema è che è arrivato
a quel tag non per via logica ma per un value in mezzo a tanti altri che di
per se descrive anche quello che sta cercando.l'erba è sia mangime che un
prato che un tipo di coltivazione . la mia idea era il rendere accessibile
il tag dopo esserci arrivato con un percorso logico che ti costringe a
legare il tag alla situazione.
tu non cerchi più erba, cerchi l'erba nella pastorizia; non cerchi più
l'oggeto, ma l'oggetto all'interno di uno specifico contesto...quanto meno
questo  ti permette di escludere molti dei tag e quindi permettere di
concentrarsi su una lista molto più breve e magari anche il più svogliato
comincia a leggersi la descrizione.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/La-nostra-wiki-come-e-e-come-dovrebbe-essere-tp5861712p5861724.html
Sent from the Italy General mailing list archive at Nabble.com.

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