Il 19/10/2012 9.50, Sgambati Alessandro ha scritto:
caro Antonio, questa mattina ho provato a riprodurre l'errore. W7, gvSIG 1.11 portable. produco un nuovo shp di punti con un unico campo integer di 10 caratteri in EPSG 3004. digito 8 nuovi punti e li chiamo 11111, 22222, 33333,..... chiudo e salvo lo shp. riproietto il file in 32633 con "geoprocessi; conversione dei dati; riproiezione" con le griglie NTv2. ottengo uno shp di 8 record i cui punti si chiamano 11111.0 22222.0 33333.0 ... insomma gvSIG gli ha regalato un ".0" controllo la struttura della tabella e quello che era un campo integer di 10 caratteri è diventato un double lunghezza 18 (!!!) e precisione decimale 6. Credo che questo "bachetto" doveva essere risolto alcuni anni fa. Noi ci abbiamo convissuto per anni.
Buongiorno Alessandro, questo bug comunque e' facilmente aggirabile, editando le tabelle degli attributi: definendo un campo integer e copiandovi il contenuto del campo double oppure editando l'intestazione del campo nel dbf con Calc.
Pensa poi che adesso è in corso la trasformazione di tutte le banche dati da 3004 a etrf2000 (a proposito, si sono inventati il relativo codice EPSG?)
Questa operazione non la farei mai in un desktop GIS, per quanto possa essere affidabile. Definirei una procedura batch con GDAL/OGR. Per i codici EPSG userei quelli di cui parlammo tempo addietro [1]. ciao Antonio [1] https://gvsig.org/lists/pipermail/gvsig_italian/2012-March/002897.html -- Antonio Falciano http://www.linkedin.com/in/antoniofalciano _______________________________________________ [email protected] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012
