|
Dear list, 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. Mwah. __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) [...] --
| ||||||
_______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
