2012/5/19 sabas88 <[email protected]>: > Il giorno 19 maggio 2012 17:28, Simone Cortesi <[email protected]> ha > scritto: > >> 2012/5/19 sabas88 <[email protected]>: >> > Mi ricorda anche il caso delle key usate in Lombardia, della cui >> > lunghezza >> > si era discusso tempo addietro (Martin mi pare avesse iniziato il >> > discorso).
non mi riccordo bene, ma è probabile che ho iniziato un discorso riguardando dei import. Cosa mi riccordo per esempio erano dei landuse=farm con tantissimi nodi (decine-centinaia) per un singolo campo (che ne anche si sovraponeva con le foto aerei) e dovuto alla conversione da curve a poligoni lineari. La lunghezza dei tags non è un problema grosso IMHO, non credo che era il motivo per incriminare un import (forse il problema era, che si erano usato tags riferiti ad un dataset esterno, dove noi abbiamo tags propri (esempio (non reale): gis-lombardia-name invece di name, o delle aree in tags (l'area di un poligono non dovremmo mettere dentro un tag secondome, perchè è contenuta nella geometria). Anche tanti chiavi "paralleli" come spesso occorono nel ambito di imports non sono necessari (più tags per associare un dataset ad osm invece di _un_ tag foreign-id). >> > Per quanto riguarda gfoss_id, trasformarlo in ref:gfoss ? -1 non vedo nessun vantaggio, ma lo svsantaggio di creare operazioni inutili (si creano change actions senza beneficio). >> Che vantaggi materiali traiamo da queste modifiche automatiche? +1 > Vantaggi? Un po' di pulizia e più ordine imho. imho sforzo inutile che appensatisce il db. ciao, Martin _______________________________________________ Talk-it mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-it
