Non dimentichiamoci di Landuse=Road!!!!!!<div>:P<br><br><div class="gmail_quote">Il giorno 20 dicembre 2011 21:55, David Paleino <span dir="ltr"><<a href="mailto:dapal@debian.org">dapal@debian.org</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 20 Dec 2011 17:51:22 +0100, Martin Koppenhoefer wrote:<br>
<br>
> 2011/12/19 David Paleino <<a href="mailto:dapal@debian.org">dapal@debian.org</a>>:<br>
> > Se diventerà un casino,<br>
><br>
><br>
> diventerà? ;-)<br>
<br>
</div>Sì Martin, il "se" in italiano non è sempre seguito dal congiuntivo ;)<br>
<br>
<a href="http://it.wikipedia.org/wiki/Periodo_ipotetico" target="_blank">http://it.wikipedia.org/wiki/Periodo_ipotetico</a><br>
<div class="im"><br>
> > si faranno più suddivisioni. Già ora mi capita di<br>
> > confondermi tra amenity, leisure e highway (non usando i preset, sapete<br>
> > com'è..) -- e mi accorgo dell'errore solo grazie alla diversa<br>
> > visualizzazione in JOSM.<br>
><br>
><br>
> ametto che anch'io mi confondo (raramente) su certi tags, ma più i<br>
> tags del tipo: name:en, int_name, official_name<br>
> oppure step_count contro addr:city. Oppure ancora molto più noioso:<br>
> "tourism" (c'è di tutto lì, per esempio "arte" e "artwork" che non<br>
> centra proprio niente con il turismo).<br>
<br>
</div>Oh, ecco. Allora sei d'accordo con me.<br>
<div class="im"><br>
> > Resto dell'opinione che *qualcosa* si debba fare.<br>
><br>
> resto dell'opinione che non è fattibile al livello internazionale. Tra<br>
> altro per il sistema di mapnik (osm2pgsql) è meglio avere poche chiavi<br>
> invece di tanti.<br>
<br>
</div>osm2pgsql è tutt'altro che mapnik. Segue lo schema di db che è stato deciso con<br>
l'API 0.6, per cui ogni chiave è una colonna del db. Ma non vedo tutto questo<br>
vantaggio ad avere poche chiavi, basta che uno aggiunga un tag inventato che<br>
subito al db viene aggiunta la relativa colonna.<br>
<div class="im"><br>
> >> cmq., un po' di tempo fa' pensavo anch'io come David, tracce si<br>
> >> trovano per esempio qui:<br>
> >> <a href="http://wiki.openstreetmap.org/wiki/Proposed_features/culture" target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/culture</a><br>
> > +1, è esattamente il tipo di razionalizzazione di cui parlavo.<br>
><br>
><br>
> ma non cambia molto. Prendi un bar, che offre una tavola calda a<br>
> pranzo, fa pasticceria e produce anche gelato.<br>
<br>
</div>Ok, e?<br>
Quello che descrivi è il "problema del multivalue", che non c'entra nulla --<br>
quasi -- con la razionalizzazione delle chiavi.<br>
<div class="im"><br>
> Oppure un ristorante che fa anche "cafe" (non intendevo la bevanda). Anche<br>
> con più chiavi è impossibile di non creare conflitti. Meglio subtaggare<br>
> (gelato=si, gelato:produzione-propria=si, ecc.), o specificare<br>
> amenity=restaurant, restaurant:type=it:osteria<br>
><br>
> Se quella chiave ("principale") poi si chiama "amenity" o "eat&drink"<br>
> non importa niente.<br>
<br>
</div>Certo, ma il mio scopo non era affatto risolvere il multivalue :)<br>
Piuttosto, è rendere più omogenee le varie chiavi ;)<br>
<div class="im"><br>
> > Perché non vengono portate avanti? Mi par di essere l'unico folle qui che<br>
> > vuole un po' migliorare la situazione :)<br>
><br>
><br>
> perchè abbiamo centinaie se non migliaia di persone che usano i nostri<br>
> dati, e si sono adeguati a quello che è. Perchè un mappatore non<br>
> troppo attivo si deve ogni volta che mappa reimparare il schema di<br>
> tagging perchè è cambiato? Hai mai analizzato la situazione di<br>
> highway=footway verso highway=path? In Inghilterra (dicono alle volte<br>
> in ML) non hanno ancora visto necessità per path.<br>
><br>
> Secondome se uno vuole precisare il tagging (andare nel specifico) è<br>
> meglio fare dei cambiamenti che sono compatibili con l'attuale tagging<br>
> (quindi non cambiare il valore della stessa chiave ma aggiungere una<br>
> sottochiave con un altro valore, oppure aggiungere un'altra chiave<br>
> (nuova) per non dover cambiare il valore).<br>
<br>
</div>Perfetto, allora io propongo amenity=restaurant + eat&drink=restaurant. Che c'è<br>
di male? :)<br>
<div class="im"><br>
> > Posso portare avanti io il discorso (tempo permettendo, visto che ho<br>
> > cominciato a lavorare -- è finita la "bella vita" dello studente), ma<br>
> > quello che è sicuro è che avrò bisogno di qualcuno che mi appoggi --<br>
> > lottare contro gli integralisti OSMici non è facile.<br>
><br>
> io sono parzialmente dalla tua parte. Per esempio vorrei ristrutturare<br>
> landuse - uso del suolo (grass non ci sarà)<br>
> landcover - copertura del suolo (lì ci sarà evventualmente un grass,<br>
> un sand, un water, ---- l'altra ipotesi sarebbe quella di usare<br>
> tipologie di coperture, che ne sò, arid_woodland, o arctic_tundra ---<br>
> ma non lo farei)<br>
> natural - da usare solo per i features "geografici" (per esempio bay,<br>
> beach, spring, wetland...),<br>
<br>
</div>+1<br>
<div class="HOEnZb"><div class="h5"><br>
David<br>
<br>
--<br>
. ''`. Debian developer | <a href="http://wiki.debian.org/DavidPaleino" target="_blank">http://wiki.debian.org/DavidPaleino</a><br>
: :' : Linuxer #334216 --|-- <a href="http://www.hanskalabs.net/" target="_blank">http://www.hanskalabs.net/</a><br>
`. `'` GPG: 1392B174 ----|---- <a href="http://deb.li/dapal" target="_blank">http://deb.li/dapal</a><br>
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174<br>
</div></div><br>_______________________________________________<br>
Talk-it mailing list<br>
<a href="mailto:Talk-it@openstreetmap.org">Talk-it@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-it" target="_blank">http://lists.openstreetmap.org/listinfo/talk-it</a><br>
<br></blockquote></div><br></div>