[Talk-it] Razionalizzazione di alcuni tag

Martin Koppenhoefer dieterdreist a gmail.com
Dom 20 Maggio 2012 15:22:55 BST


2012/5/19 sabas88 <sabas88 at gmail.com>:
> Il giorno 19 maggio 2012 17:28, Simone Cortesi <simone at cortesi.com> ha
> scritto:
>
>> 2012/5/19 sabas88 <sabas88 at gmail.com>:
>> > 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



Maggiori informazioni sulla lista Talk-it