To test it: - Create a numeric field in a postgis layer using pgAdmin III. - Add some values with decimals, for example 0.5 - Add this layer to gvSIG - Open the attribute table. Without this patch, the table will show a bad value (50000) instead of 0.5. With this correction, it works fine.
| OperatingSystem | None |
| SubprojectResolveBuildNumber | v1.1 |
| Keywords | None |
| Resolution | Validated |
| Severity | minor |
| SubprojectName | gvSIG |
| Component | gvSIG - PostGIS |
| Version | gvSIG - 1.10.0 |
| SubprojectVersion | gvSIG - 1.10.0 |
| SubprojectResolveVersion | gvSIG - 1.11.0 |
| Has patch | Yes |
Category
Bugs
Login or
create an account to comment.
Comments
fixed and commited changeset: [gvsig-desktop 34259] En cualquier caso, no creo que sea buena política que la gente use numeric fields. Es mejor usar float o double. Eso sí, con el nuevo asistente que trae PostgreSQL 9, al importar shp crea campos numeric automáticamente, así que es mejor corregirlo cuanto antes.
El commit arregla el tema del numeric pero añade además una modificación el el método setEncoding de la clase PostGIS que no parece que tenga nada que ver con lo del numeric. ¿ Que arregla esa modificacion y como se puede testear ?
Tested for gvSIG 1.11 bn 1300 on Linux and Windows XP. Numeric fields show correct values.
Lo del encoding es porque los datos alfanuméricos se tiene que pasar al encoding de la base de datos, pero en Postgis se define la cadena como UTF-8, y en java como UTF8. Eso hace que se pierdan acentos y cosas de esas al importar una capa desde shp. Para probarlo, se puede tomar un shp en UTF8 con acentos, e importarlo a una base de datos Postgis con codificación UTF-8.