On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote: > 2011/12/19 David Paleino <[email protected]>: > > 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 [email protected] http://lists.openstreetmap.org/listinfo/talk-it
