Non dimentichiamoci di Landuse=Road!!!!!! :P Il giorno 20 dicembre 2011 21:55, David Paleino <da...@debian.org> ha scritto:
> On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote: > > > 2011/12/19 David Paleino <da...@debian.org>: > > > 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
