[Talk-it] Uniformiamo e riduciamo i tag

Aury88 spacedriver88 a gmail.com
Gio 30 Maggio 2013 15:58:09 UTC


dieterdreist wrote
> 
> Aury88 wrote
>>  Se a questo si aggiungono le varie combinazioni e i vari stili di
>> mappatura
>>  posso dire con buona certezza che gli stessi elementi in varie parti del
>>  mondo (o anche solo nella stessa regione) vengono mappati in n modi
>>  diversi.
> non è necessariamente un problema, il problema più grosso si crea quando
> si
> utilizza lo stesso tag per descrivere delle cose diverse, mentre usare 2
> tags diversi per la stessa cosa non è desiderabile ma non crea ne anche
> grossi problemi, fa aumentare però lo sforzo per creare una mappa
> consistente, ma rende allo stesso tempo più facile la vita del mappatore.

Come già detto la premessa è mantenere la capacità di descrivere una cosa in
maniera completa. quello di cui parlo non è semplicemente di ridurre il
numero di tag, ma un loro utilizzo più coerente e condiviso, quando
possibile, tra l'uno e l'altro. 
appunto l'esempio del tag rovine o access=yes o public: sono due tag che
possono venire usati in molti ambiti in unione con molti altri tag senza far
perdere informazioni e che permettono per tutti gli edifici, a prescindere
dalla tipologia  a cui appartengono, di definire il loro stato o il loro
criterio di accesso al pubblico. l'obiettivo nell'esempio potrebbe essere
raggiunto usando per tutti una sola tipologia di tag (o meglio una sola
tipologia di key con il value dipendente dal tipo di accesso, naturalmente)
per descrivere l'accesso pubblico, privato o altri.
quindi secondo me più ordinato e molto più facile da utilizzare/ricordare


dieterdreist wrote
> 
> Aury88 wrote
>>  Per esempio l'amenity=school viene posta sull'area appartenente
>>  all'istituto
>>  scolastico mentre il building=school viene posto sulla struttura vera e
>>  propria
> non è così, amenity=school viene usato per indicare una istituzione del
> tipo scuola, mentre building=school indica un edificio del tipo scuola
> (non
> ci deve per forza essere una scuola attiva dentro)

 io mi rifererisco a quello che dice wiki inglese  : 
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool
e  italiano:
http://wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dschool
cioè descrivono l'utilizzo del tag come dico io, cioè generalmente per ogni
scuola c'è un area delimitata con il tag school ed associato il nome della
scuola ed un area con il tag building riferito all'edificio vero e
proprio.Attento io non dico che i due tag siano equivalenti, anzi al massimo
mi lamento di quelli che utilizzano o l'uno o l'altro;Questo esempio è
portato per introdurre la differenza con la mappatura di altre amenity
(town-hall potrebbe essere mappato nella stessa identica maniera...anche i
tribunali o, perchè no, le stazioni di polizia o le carceri)

(Ps: non capisco cosa intendi con il fatto che non ci debba essere per forza
una scuola attiva dentro building=school.)

dieterdreist wrote
> 
> Aury88 wrote
>>  questo schema
>>  però non viene riproposto quasi mai in altri ambiti; per esempio nel
>>  kindergarten (asilo/materna), le        nursing_home (casa di riposo per
>>  anziani)
>>  ecc ecc, dove non si fa accenno a questo schema...
> come no

no: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten
wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dkindergarten
per coerenza lo schemino di mappatura presente in school dovrebbe essere
messo anche nel wiki di kidergarten ;
E lo stesso per nursing_home
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dnursing_home
invece non si accenna minimamente a ciò, né con che tag debbano essere
mappati gli edifici 

dieterdreist wrote
> 
> Aury88 wrote
>>  Lo stesso vale per gli hospital (naturalmente questo
>>  diventa il value per i key amenity e building) ed university.
> +1, anche se building=university non è molto specifico come ne anche
> building=hospital, in realtà in entrambi e casi mi aspetterei più tipi di
> edificio (in un'università per esempio ci sono laboratori, una mensa,
> delle
> aule, uffici, ...)

il bello di quello schema è proprio la possibilità di utilizzare i normali
tag per descrivere gli elementi diversi presenti nel territorio ed in uso
dall'ente/istituto...nell'esempio della scuola c'è un amenity=parking dentro
l'area amenity=school per dire che quel parcheggio è della scuola. Notare
che non si è dovuta inventare una combinazione key=value nuova tipo
school=parking per descrivere ciò...si è usato per il parcheggio il tag che
si usa per un qualsiasi altro parcheggio.  per i
building...hospital/university: nulla vieta, se esiste, di utilizzare un
value  più preciso e diverso per ogni edificio appartenente l'istituzione io
credo di averlo fatto per una biblioteca dentro una scuola

dieterdreist wrote
> 
> Aury88 wrote
>> I miei dubbi sono : non si potrebbe usare/proporre uno stile unico? e
>>  proprio necessario che ci sia così tanta differenza su come si mappano
>>  oggetti diversi ? .
> credo che ha senso usare tags diversi per oggetti diversi.

molti tag descrivono caratteristiche generiche ...una rovina, l'accesso
pubblico sono caratteristiche applicabili in egual maniera a vari
elementi... perchè per ciascuno bisogna inventarsi un tag quando già ne
esiste uno che descrive la stessa identica cosa ?  quello che propongo io
non implica assolutamente il descrivere oggetti diversi con il medesimo tag,
implica usare il medesimo tag per descrivere caratteristiche comuni tra
tipologie diverse di oggetti.



dieterdreist wrote
> 
> Aury88 wrote
>> è inconsistente building=ruins con la logica della tipologia di edificio
>> ("rovina" non è una tipologia, è uno stato/ una condizione)
>> alla fine davanti al key building solitamente mettiamo lo scopo
>>  dell'edificio (residential, apartments, school, hospital ecc )
> -1, non, mettiamo il tipo come definito da anni per il key building

questa mi sfugge...dove è scritta questa cosa? 
come descrivo un edificio appartamento o delle villette a schiera? come
descrivo l'edificio di una scuola o un edificio ospedaliero? 
io faccio solitamente riferimento a questa pagina:
http://wiki.openstreetmap.org/wiki/Map_Features#Building
da qui il tag Building sembra venire usato:
- ogni tanto per dare una descrizione sul utilizzo dell'edificio (per scopi
scolastici, ospedalieri, abitativi)ecc ecc. e in questi casi ogni tanto il
tag è generico (appunto residential o school non dice che tipo di scuola tra
quelle dai 5 ai 18-19 anni di età, affida questo compito ad un altro tag )
altre volte è più preciso (house, terrace, apartments per specificare che
tipo di residenza...qui a quanto pare, a differenza delle scuole, si può
essere più specifici direttamente con il key building in sostituzione del
generico value residential )
-ogni tanto per descrivere lo stato in cui si trova l'edificio
(building=ruins)
-ogni tanto il genere di accesso (building=pubblic) 
è sopratutto per questi ultimi casi che mi riferisco quando parlo di
incoerenza.. bisogna decidere che genere di informazione affidare al key
building e lasciare le altre descrizioni ad altri value (sopratutto se
applicabili anche ad altri tipi di oggetto; una stazione ferroviaria può
essere ad accesso pubblico come anche una libreria...perchè quindi non fare
un tag apposta? da notare che nel primo il key building è già occupato dal
tag building=train_station; per il secondo dovrei mettere forse un
building=civic+amenity=library oppure un building=public+amenity=library)


dieterdreist wrote
> 
> Aury88 wrote
>>  Ho portato l'esempio delle amenity, ma pensiamo per esempio agli edifici
>>  abbandonati/ruderi. È proprio necessaria la presenza del tag
>>  building=ruins?
>> 
>>  , mentre ruins
>>  non è lo scopo ma lo stato in cui si trova l'edificio.  ergo per i
>> ruderi
>>  secondo me si dovrebbe usare i tag building=* +ruins=yes
> sembra logico ma ha dei problemi, in quanto richiede da tutti gli utenti
> di
> interpretare anche il tag ruins (ed altri come disused, abandoned, ...),
> perciò c'è un accordo di usare un sistema per prevenire a
> malinterpretazioni, per esempio highway=construction, construction=primary
> invece di highway=primary, construction=yes

beh...penso che l'interpretazione da parte degli user sia un problema comune
e di cui soffrono anche alcuni tag attualmente in uso...anzi forse il
mettere in chiaro le cose e l'organizzarle meglio potrebbe evitare
maleinterpretazioni...
il tuo esempio è perfetto: in highway si dovrebbe descrivere l'elemento non
il suo stato di completamento/funzionamento secondo me. o almeno ad intuito
penserei così visto come generalmente viene utilizzato...invece ci troviamo
attualmente in questa
situazione:http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts
tutti più o meno validi a quanto pare e questo è un bel casino secondo me.
avete mai visto una highway=operational operational=unclassified? io no e
prima di informarmi non ci avrei mai neanche lontanamente pensato...eppure è
una forma prevista.
mettere un semplice tag con un key tipo "status" e value che può variare da
proposal; costruction; operational;disuse o abandoned;ruders;demolition
potrebbe andare bene per qualsiasi struttura (sia essa una strada, un porto,
un edificio ecc ecc)
oppure rendere il value comune a key diversi:
building=shop + shop=ruins (ma andrebbe meglio, secondo me, status=ruins e
lasciare al key shop la descrizione del negozio come si fa normalmente)
oppure se a seguito dello stato di degrado una struttura ha cambiato
funzione: 
 highway=path + status:primary=abandoned  o qualcosa del genere per dire che
la strada inizialmente era una primary adesso abbandonata ed utilizzata come
generico path (e questo casino è utile solo quando mappiamo in 4D).


dieterdreist wrote
> 
> Aury88 wrote
>>> e questo secondo me è fonte di potenziali danni/errori per la mappa che
>>> la
>>> rendono parzialmente o completamente inutilizzabile in certi ambiti.
>>>
> non capisco, puoi fare un esempio?

l'ultimo link è indicativo di questo. se guardi il wiki linkato vedrai come
la presenza di stili diversi renda qualsiasi software,  che voglia sfruttare
certe informazioni, di difficile realizzazione dovendo considerare tutte le
casistiche, o almeno le più utilizzate, di tag .
peggio ancora un navigatore avrebbe problemi nel gestire highway=operational
operational=unclassified... non riconoscendo il tipo di hightway
probabilmente non la importerebbe o la gestirebbe malissimo (generalmente è
un bene se lo status è diverso da operational ma se il programma
semplicemente importa highway=* , tipo OsmAnd, potrebbero diventare cavoli
amari ).
usare un tag comune per descrivere l'operatività degli elementi potrebbe
invece risultare comodissimo 
(passatemi la mia terminologia da ignorante di informatica  ) semplicemente
escludendo con un if qualsiasi elemento abbia il key status e con value
diverso da operational...questo prescindendo da qualsiasi altro tag (che sia
una ciclovia, un autostrada poco cambia...quelli continuerebbero a venir
gestiti nella vecchia maniera dal software).


dieterdreist wrote
> 
> Aury88 wrote
>>  
>> Quindi a mio avviso il wiki andrebbe rivisto in parte togliendo molti tag
>>  inutili/confusionari/ridondanti (d'altronde siamo in primavera...è il
>>  periodo giusto per fare pulizie ;) )
> prima di fare pulizie nella wiki si dovrebbe parlarne su lista
> internazionale "tagging", cosa è impegnativo. Molto. Se ti senti di
> cominciare nessuno te lo vieta ;-)
> 
> ciao,
> Martin

speravo in un parere/confronto/aiuto prima di imbarcarmi in questa titanica
impresa :P

Ciao Aury

_______________________________________________
Talk-it mailing list
Talk-it@
http://lists.openstreetmap.org/listinfo/talk-it





--
View this message in context: http://gis.19327.n5.nabble.com/Uniformiamo-e-riduciamo-i-tag-tp5763379p5763426.html
Sent from the Italy General mailing list archive at Nabble.com.



Maggiori informazioni sulla lista Talk-it