DataStores like PropertyFileDataStore and the JDBC stores automatically convert most columns into simple feature attributes. The ones listed by Jody are those that will need special treatment to be handled as spatial data. But you are right: the desired type of a column will not always be able to be inferred from its content. PropertyFile has a magic first row to configure these. So my question is: should column type definition be in the CSV file or in your data store configuration?
Also, how do you represent nulls and empty strings in a CSV file? (Jody recently resolved this ambiguity for property files.) This is the right list for discussions of module features and behaviour. On 11/05/11 12:36, lee-verizon wrote: > Hm, again I'm not sure I understand. But this time it's mostly because > I'm such a novice on GIS topics. I thought that a feature could consist > of any arbitrary attributes, not just coordinate info. Your idea would > handle the coordinate-related columns, but what about the rest? (And > sorry if I'm using the -devel list for -user type questions). > > Lee > > On 5/10/2011 6:53 PM, Jody Garnett wrote: >>> Which reminds me of another question: These CSV classes we're writing >>> are not generic, cannot handle 'any' kind of feature. Rather they are >>> sort of hard-wired to this simple LAT/LON/CITY/NUMBER feature. >>> Right? Is the (longer-term) intent to make them more generic? >> I think that would be a good idea; we could make a connection >> parameter allowing people to indicate the following... >> ( I am just making this up so if it is a bad idea let me know): >> >> - x: String (optional); name of column to treat as a point "x" value; >> the column will not be returned as part of the feature type >> attributes. Default value will recognise common names: lon, longitude, x >> - y: String (optional); name of column to treat as point "y" value; >> the column will not be returned as part of the feature type. Default >> value will recognise common names: lat, latitude, y >> - srs: String (optional); srsName to use; default value is >> DefaultGeographic.WGS84 >> - geometry: String; name of geometry attribute (using x& y above); if >> the name identifies an existing column the values will be parsed as WKT >> >> I think that would make it general purpose? > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
