Re: [Talk-it] "Svuotamento" di amenity= e highway=
Ho mandato una mail in [Tagging] giusto per scaldare un po' gli animi :) Venite a spalleggiarmi! Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/23 Martin Koppenhoefer : > Quindi se i tags sono chiave=valore oppure tag=si/no dipende > unicamente da noi mappatori e non richiede cambiamenti (delle Api +1 Inoltre il confine non è così netto, vedi ad esempio tunnel che è sempre stato tunnel=yes (o eventualmente tunnel=no) con la strana eccezione di tunnel=culvert (personalmente avrei preferito culvert=yes) Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/22 Carlo Stemberger : > Appoggio anch'io con decisione la proposta di Federico di passare dal > sistema "chiave:valore" al sistema "tag". > > Potrebbe essere più dura di una "semplice" riclassificazione dell'esistente; > temo infatti che sia da cambiare l'intera infrastruttura di OSM (nuove > API?). Però è l'unica strada che vedo per uscire una volta per tutte dalle > mille discussioni tassonomiche, che si potrebbero in tal modo evitare a > monte. sono contrario a forzare questa idea cambiando il sistema, perchè complicherebbe ulteriormente la vita di tutti. Inanzitutto richiederebbe 2 tipi di tag (width, lanes, maxspeed, ecc. richiedono valori di testo libero per la chiave, altri invece no). Invece se vogliamo una cosa del genere già attualmente la possiamo avere senza cambiare niente ( payment:coins=yes, payment:credit_cards=yes ) Quindi se i tags sono chiave=valore oppure tag=si/no dipende unicamente da noi mappatori e non richiede cambiamenti (delle Api ,...) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
On Thu, 22 Dec 2011 15:00:00 +0100, Carlo Stemberger wrote: > Appoggio anch'io con decisione la proposta di Federico di passare dal > sistema "chiave:valore" al sistema "tag". Era già così (quasi) nell'API 0.5, in cui potevi avere un oggetto con tag del tipo: amenity=bar amenity=cafe amenity=pub amenity=* i.e. con chiavi ripetute -- ognuno di quei key=value si potrebbe considerare un "tag" nel senso flickriano del termine. Non ho mai capito il motivo per cui hanno deciso che ogni chiave dovesse essere univoca; quel metodo inoltre non aveva i problemi del "multivalue" che ci ritroviamo adesso. La soluzione finale, secondo me, passerebbe almeno dal ripristino delle "chiavi non univoche"; poi eventualmente si potrebbe passare ad avere dei tag "semplici" (senza chiave: l'oggetto X è taggato "bar", "pub", "cafe") -- che però non funzionerebbe per cose tipo opening_hours che ha bisogno (necessariamente IMHO) di una key. > Potrebbe essere più dura di una "semplice" riclassificazione dell'esistente; > temo infatti che sia da cambiare l'intera infrastruttura di OSM (nuove API?). > Però è l'unica strada che vedo per uscire una volta per tutte dalle mille > discussioni tassonomiche, che si potrebbero in tal modo evitare a monte. Certo, concordo. Ma finché non cambia alla base, io dico che dare una sistemata ai key=value attuali male non fa. My 0.02€, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Appoggio anch'io con decisione la proposta di Federico di passare dal sistema "chiave:valore" al sistema "tag". Potrebbe essere più dura di una "semplice" riclassificazione dell'esistente; temo infatti che sia da cambiare l'intera infrastruttura di OSM (nuove API?). Però è l'unica strada che vedo per uscire una volta per tutte dalle mille discussioni tassonomiche, che si potrebbero in tal modo evitare a monte. Ciao! -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \<_)__/ +--- : :' : /( )\ ---+ `. `'` |\`> < /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/22 sabas88 : > Anche i tag 'turistici' sono sparsi, bisognerebbe farci un pensierino :) Scusate se insisto, ma ritengo abbastanza inutile raggruppare "sintatticamente" i tag per aree semantiche. Non vedo grande utilità al fatto che hotel sia considerato amenity piuttosto che tourism. Non mi risulta (ma potrei anche sbagliarmi) che esistano "utenti" di OSM (render, router ecc.) che si limitano a considerare la key ignorando il relativo value. Cioè ciascun tag di OSM è una coppia key=value e non si ottengono informazioni utili considerando la sola parte key. Vedrei più utile IMHO un raggruppamento "semantico" (tassonomia? folksonomia?), cioè una "ragnatela" di concetti che permetta di collegare tag affini. Non ho idea di come possa essere fatto (arricchendo il wiki attuale?) o se esista già. Forse si può addirittura ottenere in modo semiautomatico (taginfo? tagwatch?). Faccio un esempio: chiedersi come catalogare una fontanella (amenity=drinking_water), cioè se essa sia più una amenity oppure un tourism, mi sembra poco utile. Ma sarebbe più utile una "mappa" dei tag che mi suggerisse che sia i residenti, sia i turisti possono essere interessati alle fontanelle. In pratica una cosa simile ai motori di ricerca "related tag" di flickr: http://www.airtightinteractive.com/projects/related_tag_browser/app/ http://taggalaxy.de/ Ciao, Federico Ciao, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il giorno 22 dicembre 2011 11:01, Martin Koppenhoefer < dieterdre...@gmail.com> ha scritto: > o che verranno "naturali" una volta spulciati > > amenity, highway, landuse e leisure (che mi pare siano i tag più > abusati). > > > man_made > historic > tourism > > ciao, > Martin > > PS: rimango dal parere che si deve inventare dei tags ex-nuovo, per > specificare meglio di cosa si tratta, ma "cambiare" o "deprecare" dei > tags usati centomille volte non mi sembra fattibile. Per esempio manca > un tag per differenziare osteria, enoteca, tavola calda, trattoria, > ristorante > > Per esempio esiste il tag oven=wood_fired per indicare "forno a > legna", non è documentato (credo) e non è molto conosciuto, ma > qualcuno lo usa: > http://taginfo.openstreetmap.org/keys/oven#values > > Direi addio al concetto di usare solo 1 o due tags per specificare di > cosa si tratta. > > Anche i tag 'turistici' sono sparsi, bisognerebbe farci un pensierino :) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/21 David Paleino : > Per il resto è piuttosto semplice: culture (già proposto da Martin), > education, per education qualcosa si trova: http://taginfo.openstreetmap.org/search?q=education#keys > landuse/landcover, ho fatto anche lì una proposta: http://wiki.openstreetmap.org/wiki/Proposed_features/landcover ... Penso che verranno "naturali" una volta spulciati > amenity, highway, landuse e leisure (che mi pare siano i tag più abusati). man_made historic tourism ciao, Martin PS: rimango dal parere che si deve inventare dei tags ex-nuovo, per specificare meglio di cosa si tratta, ma "cambiare" o "deprecare" dei tags usati centomille volte non mi sembra fattibile. Per esempio manca un tag per differenziare osteria, enoteca, tavola calda, trattoria, ristorante Per esempio esiste il tag oven=wood_fired per indicare "forno a legna", non è documentato (credo) e non è molto conosciuto, ma qualcuno lo usa: http://taginfo.openstreetmap.org/keys/oven#values Direi addio al concetto di usare solo 1 o due tags per specificare di cosa si tratta. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/20 sabas88 : > Fare una proposta articolata? > Cioè, si fa una pagina nelle Proposals che elenca il nuovo sistema di tag > (ufficiali) in modo da poterla presentare direttamente alla prova dei fatti. +1 Secondo me è utile fare una bella pagina wiki dove mettere tutte le possibili idee nero su bianco, l'idea di ristrutturare il tagging anche se mi fa paüra mi piace e soprattutto mi sembra una buona cosa. > Ciao, > Stefano Ciao -- Francesco Vezzoli ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
On Wed, 21 Dec 2011 21:13:17 +0100, David Paleino wrote: > On Tue, 20 Dec 2011 19:34:40 +0100, sabas88 wrote: > > > Fare una proposta articolata? > > Cioè, si fa una pagina nelle Proposals che elenca il nuovo sistema di tag > > (ufficiali) in modo da poterla presentare direttamente alla prova dei fatti. > > Certo. > > L'unico "scoglio" che incontro al momento è una chiave per raggruppare tutti > quei posti in cui si mangia/beve. Mi pare assurdo fare un food=* e drink=*, e > eat&drink=* è orrendo. Non avrei neanche un termine adatto in italiano, in > realtà. Ecco, ora ricordo che in chat parlavamo di catering=*. Wordreference mi dice che "catering business" è "attività di ristorazione", quindi secondo me potrebbe andar bene. Ma aspetto altre proposte :) (intanto dovrei cominciare una pagina wiki) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
On Tue, 20 Dec 2011 19:34:40 +0100, sabas88 wrote: > Fare una proposta articolata? > Cioè, si fa una pagina nelle Proposals che elenca il nuovo sistema di tag > (ufficiali) in modo da poterla presentare direttamente alla prova dei fatti. Certo. L'unico "scoglio" che incontro al momento è una chiave per raggruppare tutti quei posti in cui si mangia/beve. Mi pare assurdo fare un food=* e drink=*, e eat&drink=* è orrendo. Non avrei neanche un termine adatto in italiano, in realtà. Per il resto è piuttosto semplice: culture (già proposto da Martin), education, landuse/landcover, ... Penso che verranno "naturali" una volta spulciati amenity, highway, landuse e leisure (che mi pare siano i tag più abusati). Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/20 Carlo Stemberger : >>> > Se diventerà un casino, >>> diventerà? ;-) > Secondo me Martin voleva dire che È GIÀ un casino... si, grazie ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il 20 dicembre 2011 21:55, David Paleino ha scritto: > On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote: > >> 2011/12/19 David Paleino : >> > Se diventerà un casino, >> >> >> diventerà? ;-) > > Sì Martin, il "se" in italiano non è sempre seguito dal congiuntivo ;) Secondo me Martin voleva dire che È GIÀ un casino... Ciao, e in bocca al lupo! Carlo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Non dimentichiamoci di Landuse=Road!!
:P
Il giorno 20 dicembre 2011 21:55, David Paleino ha
scritto:
> On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote:
>
> > 2011/12/19 David Paleino :
> > > Se diventerà un casino,
> >
> >
> > diventerà? ;-)
>
> Sì Martin, il "se" in italiano non è sempre seguito dal congiuntivo ;)
>
> http://it.wikipedia.org/wiki/Periodo_ipotetico
>
> > > si faranno più suddivisioni. Già ora mi capita di
> > > confondermi tra amenity, leisure e highway (non usando i preset, sapete
> > > com'è..) -- e mi accorgo dell'errore solo grazie alla diversa
> > > visualizzazione in JOSM.
> >
> >
> > ametto che anch'io mi confondo (raramente) su certi tags, ma più i
> > tags del tipo: name:en, int_name, official_name
> > oppure step_count contro addr:city. Oppure ancora molto più noioso:
> > "tourism" (c'è di tutto lì, per esempio "arte" e "artwork" che non
> > centra proprio niente con il turismo).
>
> Oh, ecco. Allora sei d'accordo con me.
>
> > > Resto dell'opinione che *qualcosa* si debba fare.
> >
> > resto dell'opinione che non è fattibile al livello internazionale. Tra
> > altro per il sistema di mapnik (osm2pgsql) è meglio avere poche chiavi
> > invece di tanti.
>
> osm2pgsql è tutt'altro che mapnik. Segue lo schema di db che è stato
> deciso con
> l'API 0.6, per cui ogni chiave è una colonna del db. Ma non vedo tutto
> questo
> vantaggio ad avere poche chiavi, basta che uno aggiunga un tag inventato
> che
> subito al db viene aggiunta la relativa colonna.
>
> > >> cmq., un po' di tempo fa' pensavo anch'io come David, tracce si
> > >> trovano per esempio qui:
> > >> http://wiki.openstreetmap.org/wiki/Proposed_features/culture
> > > +1, è esattamente il tipo di razionalizzazione di cui parlavo.
> >
> >
> > ma non cambia molto. Prendi un bar, che offre una tavola calda a
> > pranzo, fa pasticceria e produce anche gelato.
>
> Ok, e?
> Quello che descrivi è il "problema del multivalue", che non c'entra nulla
> --
> quasi -- con la razionalizzazione delle chiavi.
>
> > Oppure un ristorante che fa anche "cafe" (non intendevo la bevanda).
> Anche
> > con più chiavi è impossibile di non creare conflitti. Meglio subtaggare
> > (gelato=si, gelato:produzione-propria=si, ecc.), o specificare
> > amenity=restaurant, restaurant:type=it:osteria
> >
> > Se quella chiave ("principale") poi si chiama "amenity" o "eat&drink"
> > non importa niente.
>
> Certo, ma il mio scopo non era affatto risolvere il multivalue :)
> Piuttosto, è rendere più omogenee le varie chiavi ;)
>
> > > Perché non vengono portate avanti? Mi par di essere l'unico folle qui
> che
> > > vuole un po' migliorare la situazione :)
> >
> >
> > perchè abbiamo centinaie se non migliaia di persone che usano i nostri
> > dati, e si sono adeguati a quello che è. Perchè un mappatore non
> > troppo attivo si deve ogni volta che mappa reimparare il schema di
> > tagging perchè è cambiato? Hai mai analizzato la situazione di
> > highway=footway verso highway=path? In Inghilterra (dicono alle volte
> > in ML) non hanno ancora visto necessità per path.
> >
> > Secondome se uno vuole precisare il tagging (andare nel specifico) è
> > meglio fare dei cambiamenti che sono compatibili con l'attuale tagging
> > (quindi non cambiare il valore della stessa chiave ma aggiungere una
> > sottochiave con un altro valore, oppure aggiungere un'altra chiave
> > (nuova) per non dover cambiare il valore).
>
> Perfetto, allora io propongo amenity=restaurant + eat&drink=restaurant.
> Che c'è
> di male? :)
>
> > > Posso portare avanti io il discorso (tempo permettendo, visto che ho
> > > cominciato a lavorare -- è finita la "bella vita" dello studente), ma
> > > quello che è sicuro è che avrò bisogno di qualcuno che mi appoggi --
> > > lottare contro gli integralisti OSMici non è facile.
> >
> > io sono parzialmente dalla tua parte. Per esempio vorrei ristrutturare
> > landuse - uso del suolo (grass non ci sarà)
> > landcover - copertura del suolo (lì ci sarà evventualmente un grass,
> > un sand, un water, l'altra ipotesi sarebbe quella di usare
> > tipologie di coperture, che ne sò, arid_woodland, o arctic_tundra ---
> > ma non lo farei)
> > natural - da usare solo per i features "geografici" (per esempio bay,
> > beach, spring, wetland...),
>
> +1
>
> David
>
> --
> . ''`. Debian developer | http://wiki.debian.org/DavidPaleino
> : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
> `. `'` GPG: 1392B174 | http://deb.li/dapal
> `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote:
> 2011/12/19 David Paleino :
> > Se diventerà un casino,
>
>
> diventerà? ;-)
Sì Martin, il "se" in italiano non è sempre seguito dal congiuntivo ;)
http://it.wikipedia.org/wiki/Periodo_ipotetico
> > si faranno più suddivisioni. Già ora mi capita di
> > confondermi tra amenity, leisure e highway (non usando i preset, sapete
> > com'è..) -- e mi accorgo dell'errore solo grazie alla diversa
> > visualizzazione in JOSM.
>
>
> ametto che anch'io mi confondo (raramente) su certi tags, ma più i
> tags del tipo: name:en, int_name, official_name
> oppure step_count contro addr:city. Oppure ancora molto più noioso:
> "tourism" (c'è di tutto lì, per esempio "arte" e "artwork" che non
> centra proprio niente con il turismo).
Oh, ecco. Allora sei d'accordo con me.
> > Resto dell'opinione che *qualcosa* si debba fare.
>
> resto dell'opinione che non è fattibile al livello internazionale. Tra
> altro per il sistema di mapnik (osm2pgsql) è meglio avere poche chiavi
> invece di tanti.
osm2pgsql è tutt'altro che mapnik. Segue lo schema di db che è stato deciso con
l'API 0.6, per cui ogni chiave è una colonna del db. Ma non vedo tutto questo
vantaggio ad avere poche chiavi, basta che uno aggiunga un tag inventato che
subito al db viene aggiunta la relativa colonna.
> >> cmq., un po' di tempo fa' pensavo anch'io come David, tracce si
> >> trovano per esempio qui:
> >> http://wiki.openstreetmap.org/wiki/Proposed_features/culture
> > +1, è esattamente il tipo di razionalizzazione di cui parlavo.
>
>
> ma non cambia molto. Prendi un bar, che offre una tavola calda a
> pranzo, fa pasticceria e produce anche gelato.
Ok, e?
Quello che descrivi è il "problema del multivalue", che non c'entra nulla --
quasi -- con la razionalizzazione delle chiavi.
> Oppure un ristorante che fa anche "cafe" (non intendevo la bevanda). Anche
> con più chiavi è impossibile di non creare conflitti. Meglio subtaggare
> (gelato=si, gelato:produzione-propria=si, ecc.), o specificare
> amenity=restaurant, restaurant:type=it:osteria
>
> Se quella chiave ("principale") poi si chiama "amenity" o "eat&drink"
> non importa niente.
Certo, ma il mio scopo non era affatto risolvere il multivalue :)
Piuttosto, è rendere più omogenee le varie chiavi ;)
> > Perché non vengono portate avanti? Mi par di essere l'unico folle qui che
> > vuole un po' migliorare la situazione :)
>
>
> perchè abbiamo centinaie se non migliaia di persone che usano i nostri
> dati, e si sono adeguati a quello che è. Perchè un mappatore non
> troppo attivo si deve ogni volta che mappa reimparare il schema di
> tagging perchè è cambiato? Hai mai analizzato la situazione di
> highway=footway verso highway=path? In Inghilterra (dicono alle volte
> in ML) non hanno ancora visto necessità per path.
>
> Secondome se uno vuole precisare il tagging (andare nel specifico) è
> meglio fare dei cambiamenti che sono compatibili con l'attuale tagging
> (quindi non cambiare il valore della stessa chiave ma aggiungere una
> sottochiave con un altro valore, oppure aggiungere un'altra chiave
> (nuova) per non dover cambiare il valore).
Perfetto, allora io propongo amenity=restaurant + eat&drink=restaurant. Che c'è
di male? :)
> > Posso portare avanti io il discorso (tempo permettendo, visto che ho
> > cominciato a lavorare -- è finita la "bella vita" dello studente), ma
> > quello che è sicuro è che avrò bisogno di qualcuno che mi appoggi --
> > lottare contro gli integralisti OSMici non è facile.
>
> io sono parzialmente dalla tua parte. Per esempio vorrei ristrutturare
> landuse - uso del suolo (grass non ci sarà)
> landcover - copertura del suolo (lì ci sarà evventualmente un grass,
> un sand, un water, l'altra ipotesi sarebbe quella di usare
> tipologie di coperture, che ne sò, arid_woodland, o arctic_tundra ---
> ma non lo farei)
> natural - da usare solo per i features "geografici" (per esempio bay,
> beach, spring, wetland...),
+1
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Fare una proposta articolata? Cioè, si fa una pagina nelle Proposals che elenca il nuovo sistema di tag (ufficiali) in modo da poterla presentare direttamente alla prova dei fatti. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il giorno ven, 16/12/2011 alle 23.47 +0100, David Paleino ha scritto: > vediamo di lanciare una discussione che, ne sono sicuro, scatenerà il più > grande flame della storia di talk-it. :) > > *Secondo me* amenity= e highway= sono sovraffollate, sovrabusate, e > andrebbero, > sempre *secondo me*, sfoltite un po'. ...omissis Mi piacciono le "impossible mission" :-) Sono d'accordo con te che una razionalizzazione dei tag sarebbe una cosa positiva. Per quel che può servire hai il mio appoggio. -- Ciao Gio. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/19 David Paleino :
> Se diventerà un casino,
diventerà? ;-)
> si faranno più suddivisioni. Già ora mi capita di
> confondermi tra amenity, leisure e highway (non usando i preset, sapete
> com'è..) -- e mi accorgo dell'errore solo grazie alla diversa visualizzazione
> in JOSM.
ametto che anch'io mi confondo (raramente) su certi tags, ma più i
tags del tipo: name:en, int_name, official_name
oppure step_count contro addr:city. Oppure ancora molto più noioso:
"tourism" (c'è di tutto lì, per esempio "arte" e "artwork" che non
centra proprio niente con il turismo).
> Resto dell'opinione che *qualcosa* si debba fare.
resto dell'opinione che non è fattibile al livello internazionale. Tra
altro per il sistema di mapnik (osm2pgsql) è meglio avere poche chiavi
invece di tanti.
>> cmq., un po' di tempo fa' pensavo anch'io come David, tracce si
>> trovano per esempio qui:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/culture
> +1, è esattamente il tipo di razionalizzazione di cui parlavo.
ma non cambia molto. Prendi un bar, che offre una tavola calda a
pranzo, fa pasticceria e produce anche gelato. Oppure un ristorante
che fa anche "cafe" (non intendevo la bevanda). Anche con più chiavi è
impossibile di non creare conflitti. Meglio subtaggare (gelato=si,
gelato:produzione-propria=si, ecc.), o specificare amenity=restaurant,
restaurant:type=it:osteria
Se quella chiave ("principale") poi si chiama "amenity" o "eat&drink"
non importa niente.
> Perché non vengono portate avanti? Mi par di essere l'unico folle qui che
> vuole un po' migliorare la situazione :)
perchè abbiamo centinaie se non migliaia di persone che usano i nostri
dati, e si sono adeguati a quello che è. Perchè un mappatore non
troppo attivo si deve ogni volta che mappa reimparare il schema di
tagging perchè è cambiato? Hai mai analizzato la situazione di
highway=footway verso highway=path? In Inghilterra (dicono alle volte
in ML) non hanno ancora visto necessità per path.
Secondome se uno vuole precisare il tagging (andare nel specifico) è
meglio fare dei cambiamenti che sono compatibili con l'attuale tagging
(quindi non cambiare il valore della stessa chiave ma aggiungere una
sottochiave con un altro valore, oppure aggiungere un'altra chiave
(nuova) per non dover cambiare il valore).
> Posso portare avanti io il discorso (tempo permettendo, visto che ho
> cominciato
> a lavorare -- è finita la "bella vita" dello studente), ma quello che è sicuro
> è che avrò bisogno di qualcuno che mi appoggi -- lottare contro gli
> integralisti OSMici non è facile.
io sono parzialmente dalla tua parte. Per esempio vorrei ristrutturare
landuse - uso del suolo (grass non ci sarà)
landcover - copertura del suolo (lì ci sarà evventualmente un grass,
un sand, un water, l'altra ipotesi sarebbe quella di usare
tipologie di coperture, che ne sò, arid_woodland, o arctic_tundra ---
ma non lo farei)
natural - da usare solo per i features "geografici" (per esempio bay,
beach, spring, wetland...),
in grosso modo è già così, ma non è specificato (per esempio natural
dice la voce è per "cose naturali", al meno fino poco tempo fa si
leggeva: "This key is used to describe natural features, mostly in
terms of habitats and geological features." cosa non è molto
pertinente). --- Ho visto adesso che Peter Ito l'ha cambiato proprio
ieri e adesso mi piace ;-)
ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il giorno 19 dicembre 2011 21:24, David Paleino ha scritto: > Premetto che non vedo la risposta di Federico in ML... > > On Mon, 19 Dec 2011 01:16:08 +0100, Martin Koppenhoefer wrote: > > > 2011/12/17 Federico Cozzi : > > > 2011/12/16 David Paleino : > > >> Che ne pensate? > > > > > > Un gran lavoro per poco risultato. > > > Qualsiasi tentativo di classificazione dopo un po' diventa uno schifo, > > > > > > +1 > > E allora? Non facciamo nulla? Lasciamo che amenity e highway diventi la > latrina > dei tag OSMici? > > Se diventerà un casino, si faranno più suddivisioni. Già ora mi capita di > confondermi tra amenity, leisure e highway (non usando i preset, sapete > com'è..) -- e mi accorgo dell'errore solo grazie alla diversa > visualizzazione > in JOSM. > > Se questo crea problemi (ogni tanto, non sempre, ovvio) ad un mapper > esperto > (qual io mi ritengo), figuriamoci ad un novellino, provate a spiegargli > perché > una prigione è amenity, mentre una piscina è leisure. > > Resto dell'opinione che *qualcosa* si debba fare. > > > cmq., un po' di tempo fa' pensavo anch'io come David, tracce si > > trovano per esempio qui: > > http://wiki.openstreetmap.org/wiki/Proposed_features/culture > > +1, è esattamente il tipo di razionalizzazione di cui parlavo. > > > un altra "idea" era di avere una categoria "accomodation" (per > > alberghi e simile, "food" ...) > > Esatto (magari "food" mi pare un po' restrittivo, perché un amenity=bar > non è > propriamente food, ma più un "drink=*"). > Perché non vengono portate avanti? Mi par di essere l'unico folle qui che > vuole un po' migliorare la situazione :) > > Posso portare avanti io il discorso (tempo permettendo, visto che ho > cominciato > a lavorare -- è finita la "bella vita" dello studente), ma quello che è > sicuro > è che avrò bisogno di qualcuno che mi appoggi -- lottare contro gli > integralisti OSMici non è facile. > > Ciao, > David > In tagging di sicuro ci siamo io, Martin e Volker della 'pattuglia italiana'. Io ti spalleggio ;) Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Premetto che non vedo la risposta di Federico in ML... On Mon, 19 Dec 2011 01:16:08 +0100, Martin Koppenhoefer wrote: > 2011/12/17 Federico Cozzi : > > 2011/12/16 David Paleino : > >> Che ne pensate? > > > > Un gran lavoro per poco risultato. > > Qualsiasi tentativo di classificazione dopo un po' diventa uno schifo, > > > +1 E allora? Non facciamo nulla? Lasciamo che amenity e highway diventi la latrina dei tag OSMici? Se diventerà un casino, si faranno più suddivisioni. Già ora mi capita di confondermi tra amenity, leisure e highway (non usando i preset, sapete com'è..) -- e mi accorgo dell'errore solo grazie alla diversa visualizzazione in JOSM. Se questo crea problemi (ogni tanto, non sempre, ovvio) ad un mapper esperto (qual io mi ritengo), figuriamoci ad un novellino, provate a spiegargli perché una prigione è amenity, mentre una piscina è leisure. Resto dell'opinione che *qualcosa* si debba fare. > cmq., un po' di tempo fa' pensavo anch'io come David, tracce si > trovano per esempio qui: > http://wiki.openstreetmap.org/wiki/Proposed_features/culture +1, è esattamente il tipo di razionalizzazione di cui parlavo. > un altra "idea" era di avere una categoria "accomodation" (per > alberghi e simile, "food" ...) Esatto (magari "food" mi pare un po' restrittivo, perché un amenity=bar non è propriamente food, ma più un "drink=*"). Perché non vengono portate avanti? Mi par di essere l'unico folle qui che vuole un po' migliorare la situazione :) Posso portare avanti io il discorso (tempo permettendo, visto che ho cominciato a lavorare -- è finita la "bella vita" dello studente), ma quello che è sicuro è che avrò bisogno di qualcuno che mi appoggi -- lottare contro gli integralisti OSMici non è facile. Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/17 Federico Cozzi : > 2011/12/16 David Paleino : >> Che ne pensate? > > Un gran lavoro per poco risultato. > Qualsiasi tentativo di classificazione dopo un po' diventa uno schifo, +1 cmq., un po' di tempo fa' pensavo anch'io come David, tracce si trovano per esempio qui: http://wiki.openstreetmap.org/wiki/Proposed_features/culture un altra "idea" era di avere una categoria "accomodation" (per alberghi e simile, "food" ...) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il 16/12/2011 23:47, David Paleino ha scritto: Buonasera a tutti, vediamo di lanciare una discussione che, ne sono sicuro, scatenerà il più grande flame della storia di talk-it. :) *Secondo me* amenity= e highway= sono sovraffollate, sovrabusate, e andrebbero, sempre *secondo me*, sfoltite un po'. In amenity abbiamo le cose più svariate tra di loro: si va dalla prison, al ristorante, alla scuola, ai parcheggi, e così via. Secondo me bisognerebbe introdurre nuove chiavi, e usare queste come valori di amenity. Per esempio: amenity |-- education | |-- school | |-- university | \-- ... |-- transportation | |-- fuel | |-- parking | \-- ... | ... Come interpretare lo schemino di sopra: amenity=school diventerebbe amenity=education + education=school. *Eventualmente* potremmo anche pensare di omettere "amenity=*" in questi casi (e rendere quindi education=*, transportation=*, health= e altri delle "chiavi di primo livello). In questo modo in amenity= resterebbero quelle che sono *vere* "amenity", diventerebbe un doppione di leisure= in pratica (e quindi si potrebbero accorpare, magari). Stesso discorso vale per highway: abbiamo la motorway, ma anche highway=stop, bus_stop, speed_camera, street_lamp. Queste sono cose, secondo me, che andrebbero in chiavi separate, anche da creare ex-novo. Ad esempio, per stop e give_way starebbe benissimo il traffic_sign che viene usato già per maxspeed e city_limit; street_lamp potrebbe stare in una chiave tipo "arredo urbano", e così via. Così in highway= resterebbero solamente le strade, e le loro classificazioni (motorway→...→path). Che ne pensate? So che è un'idea che scombussola un po' lo _status quo_ di OSM, e creerebbe problemi sul breve termine a tutti (renderer, router, mapper), però meglio ora che quando avremo milioni di utenti sparsi nel mondo. In realtà si sarebbe dovuto fare all'inizio del progetto, ma o non è importato a nessuno oppure tutti i tentativi sono falliti :) Partendo da un discorso più ampio che mi sembra sia emerso anche in qualche altra discussione, è evidente come il fatto di non porre limiti ai tag diventi poi una limitazione di OSM, sia per chi vuole usarlo (rendering, tool di editing, ecc..) sia per chi vuole contribuire (che tag metto?). Detto questo i tentativi come il tuo di tentare di dare un ordine più razionale alle key sono di certo apprezzabili ma poco lungimiranti. Secondo me bisognerebbe ragionare su tutti e quali dati possono essere inseriti in OSM e fare una classificazione estensibile ma che copra tutti i casi più disparati. Mi chiedo inoltre se per certi argomenti non esistano già delle classificazioni riconosciute a livello internazionale che potrebbero essere utilizzate per la categorizzazione degli oggetti in OSM... Evitiamo di reinventare la ruota e usiamo gli standard, insomma. Altro quesito correlato che mi è venuto in mente è: quanto difficile sarebbe prendere tutti i dati del database e uniformarli secondo uno schema preimpostato? Esempio: un ipotetico software di routing per evitare di gestire troppi tag potrebbe unificare con uno script tutti i dati simili, dove highway=stop, traffic_sign=stop, ecc... potrebbero tutti diventare anche un 5=12. Mi sa che non sono stato pienamente in topic... paolopoz ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
2011/12/16 David Paleino : > Che ne pensate? Un gran lavoro per poco risultato. Qualsiasi tentativo di classificazione dopo un po' diventa uno schifo, perché sotto education ti troverai education=university, education=reading_club, education=swapping_book_site (qualcuno prima o poi inventerà i tag per mappare i posti dove si lasciano i libri affinché altri li prendano) ecc. e bisognerà ulteriormente razionalizzare in formal_education=university, informal_education=swapping_book_site ecc. A mio parere in OSM le key dovrebbero sparire; dovrebbero rimanere solo i value... (con le dovute eccezioni: maxspeed=, width= ecc.) Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
In data venerdì 16 dicembre 2011 23:47:34, David Paleino ha scritto: > Che ne pensate? È una lucida follia. Sono molto pessimista sulla riuscita dell'operazione ma anch'io ne sento la necessità. Hai il mio appoggio. Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] "Svuotamento" di amenity= e highway=
Il giorno 16 dicembre 2011 23:47, David Paleino ha scritto: > Buonasera a tutti, > > vediamo di lanciare una discussione che, ne sono sicuro, scatenerà il più > grande flame della storia di talk-it. :) > > *Secondo me* amenity= e highway= sono sovraffollate, sovrabusate, e > andrebbero, > sempre *secondo me*, sfoltite un po'. > > In amenity abbiamo le cose più svariate tra di loro: si va dalla prison, al > ristorante, alla scuola, ai parcheggi, e così via. Secondo me bisognerebbe > introdurre nuove chiavi, e usare queste come valori di amenity. Per > esempio: > > amenity > |-- education > | |-- school > | |-- university > | \-- ... > |-- transportation > | |-- fuel > | |-- parking > | \-- ... > | > ... > > Come interpretare lo schemino di sopra: > > amenity=school diventerebbe amenity=education + education=school. > *Eventualmente* potremmo anche pensare di omettere "amenity=*" in questi > casi (e > rendere quindi education=*, transportation=*, health= e altri delle > "chiavi di > primo livello). > In questo modo in amenity= resterebbero quelle che sono *vere* "amenity", > diventerebbe un doppione di leisure= in pratica (e quindi si potrebbero > accorpare, magari). > > Stesso discorso vale per highway: abbiamo la motorway, ma anche > highway=stop, > bus_stop, speed_camera, street_lamp. Queste sono cose, secondo me, che > andrebbero in chiavi separate, anche da creare ex-novo. Ad esempio, per > stop e > give_way starebbe benissimo il traffic_sign che viene usato già per > maxspeed e > city_limit; street_lamp potrebbe stare in una chiave tipo "arredo urbano", > e > così via. Così in highway= resterebbero solamente le strade, e le loro > classificazioni (motorway→...→path). > > Che ne pensate? So che è un'idea che scombussola un po' lo _status quo_ di > OSM, > e creerebbe problemi sul breve termine a tutti (renderer, router, mapper), > però > meglio ora che quando avremo milioni di utenti sparsi nel mondo. > In realtà si sarebbe dovuto fare all'inizio del progetto, ma o non è > importato > a nessuno oppure tutti i tentativi sono falliti :) > > Ciao, > David > > -- > . ''`. Debian developer | http://wiki.debian.org/DavidPaleino > : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ > `. `'` GPG: 1392B174 | http://deb.li/dapal > `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 > > ___ > Talk-it mailing list > Talk-it@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-it > > Butta la discussione direttamente nella ML tagging se vuoi fare un flame serio :P Io ti spalleggio, sono per la razionalizzazione :) Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
