La nostra wiki, come è e come dovrebbe essere

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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 adeguato....se 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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist


sent from a phone

> Am 05.12.2015 um 09:06 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Aury88
In reply to this post by 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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Carlo Nardi
In reply to this post by Aury88


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 adeguato....se 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

[hidden email]

https://lists.openstreetmap.org/listinfo/talk-it


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist
In reply to this post by Aury88


sent from a phone

> Am 05.12.2015 um 10:28 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Aury88
In reply to this post by dieterdreist
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 palestre....una 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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Aury88
In reply to this post by dieterdreist
dieterdreist wrote
sent from a phone

> Am 05.12.2015 um 10:28 schrieb Aury88 <[hidden email]>:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist
In reply to this post by Aury88


sent from a phone

> Am 05.12.2015 um 10:49 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> ha scritto:


sent from a phone

> Am 05.12.2015 um 10:49 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it

_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Aury88
In reply to this post by dieterdreist
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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist


sent from a phone

Am 05.12.2015 um 12:33 schrieb Aury88 <[hidden email]>:

>> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist
In reply to this post by Aury88


sent from a phone

> Am 05.12.2015 um 11:24 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

sabas88


On Dec 5, 2015 1:54 PM, "Martin Koppenhoefer" <[hidden email]> wrote:
>
>
>
> sent from a phone
>
> > Am 05.12.2015 um 11:24 schrieb Aury88 <[hidden email]>:
> >
> > 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-it


_______________________________________________
Talk-it mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist


sent from a phone

Am 05.12.2015 um 14:16 schrieb Stefano <[hidden email]>:

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Aury88
In reply to this post by dieterdreist
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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist


sent from a phone

> Am 05.12.2015 um 14:45 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist
In reply to this post by Aury88


sent from a phone

> Am 05.12.2015 um 14:45 schrieb Aury88 <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: 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 impossibile....per 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 maniera....e 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
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

Alessandro P.
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
Reply | Threaded
Open this post in threaded view
|

Re: La nostra wiki, come è e come dovrebbe essere

dieterdreist


sent from a phone

> Am 05.12.2015 um 18:37 schrieb Alessandro <[hidden email]>:
>
> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-it
123