Hi gvSIG-team using the spatial join function of gvSIG 1.9 can create some problems regarding the attribute table field definition. In my case one original layer contains integer values in the attribute table (like house-number). When doing a spatial join the resulting layer will have decimal places which does not really make sense and is a problem for address data (for example). Below you see the output of ogrinfo for the original and the resulting layer. I"ll report this as a bug in the bugtracker. BTW it is strange that ogrinfo says Real and gvSIG describes the same column as integer. Tested on LiMux with gvSIG 1.9 build 1253 and 1253-IV00 Original file ogrinfo-output INFO Open of mnt wolfgang.qual sun5310.rgu.muenchen.de uis muc shapes geodatenpool aktuell vagrund hausnr feb2009.shp" using driver ESRI Shapefile" successful. Layer name vagrund hausnr feb2009 Geometry Point Feature Count 147514 Extent (4453141.502585 5325338.164620) - (4478908.212025 5345491.606355) Layer SRS WKT (unknown) ROWID String (1.0) OGR FID Real (18.0) OBJEKT ID String (7.0) NR String (8.0) LAND Real (18.0) REGIERUNGS Real (18.0) KREIS Real (18.0) GEMEINDE Real (18.0) STRASSE Real (18.0) STRANAM String (254.0) HAUSNR Real (18.0) ... resulting layer of the spatial join INFO Open of tmp spatial test.shp" using driver ESRI Shapefile" successful. Layer name spatial test Geometry Point Feature Count 12990 Extent (4456831.519996 5332176.685383) - (4461744.250227 5336611.573443) Layer SRS WKT (unknown) ROWID String (254.0) OGR FID Real (18.5) OBJEKT ID String (254.0) NR String (254.0) LAND Real (18.5) REGIERUNGS Real (18.5) KREIS Real (18.5) GEMEINDE Real (18.5) STRASSE Real (18.5) STRANAM String (254.0) HAUSNR Real (18.5) ...
| OperatingSystem | None |
| BuildNumber | Cog A |
| Keywords | None |
| Resolution | None |
| Severity | None |
| SubprojectName | gvSIG |
| Component | gvSIG - Geoprocessing |
| Version | gvSIG - 1.9.0 |
| SubprojectVersion | gvSIG - 1.9.0 |
| SubprojectResolveVersion | None |
| Has patch | None |
Comments
Logged In: YES user_id=1799 Se corresponde con el ticket del iti 2917 Reported by wqual in date 2010-03-04
Logged In: YES user_id=1799 2010-03-05 changed by vagazzi build set to 1253 -------------------------------------------- 2010-03-05 changed by vagazzi Hi Wolfgang I"ve changed some of the parameters for this ticket and also for another one yesterday. I tell you why so you"ll be able to undestand what am I doing. When you find a bug on both official gvSIG binary and the one from Iver please fill in the build number (not subproject build number) as 1253 directly. The subprojects fields (subproject build number subproject version etc) are thought to be filled in ehwn we are detecting bugs on what we regularly call extension so if you are testing main gvSIG and the bugs came from main gvSIG please fill the build number field version field and component field. For more info better explained go to 1 1 https gvsig.org web production docs procedures procedimientos testing tipos-de-testeo estabilizacion descripcion-del-proceso depuracion-iterativa tickets-creation-protocol view set language en -------------------------------------------- 2010-03-05 changed by vagazzi keywords changed from geoprocess field definition needless decimal places to geoprocess field definition needless decimal places 1253-IV00 -------------------------------------------- 2010-03-05 changed by vagazzi subproject build changed from 1253-IV00 to -------------------------------------------- 2010-03-05 changed by vagazzi version changed from Sin determinar to 1.9.0 --------------------------------------------