gvSIG e i campi integer che diventano double

[Sgambati Alessandro]

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.

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?)

 

Con immutata stima, un caro saluto.

 

 

Spec. tec. Alessandro SGAMBATI

Ispettorato agricoltura e foreste di Gorizia e Trieste

via Monte San Gabriele, 35

I-34134  TRIESTE

Tel: [phone]      fax: [phone]

[hidden email]

 

_______________________________________________
[hidden email]
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

[Antonio Falciano]

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
_______________________________________________
[hidden email]
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