That was my thought too -- CSV is a rather wimpy file format. It's also
true that there's no "standard" for CSV. Sometimes there's a header
line, sometimes not. The delimiter between columns can be something
other than comma (despite the C in CSV). There's no standard for null
values, although it is easy to write an empty value - just two
consecutive commas. Also, the CSVReader/Writer that we're using
(http://javacsv.sourceforge.net/) supports a few options, such as
ESCAPE_MODE_DOUBLED vs ESCAPE_MODE_BACKSLASH -- we should probably allow
the client to indicate these options in a connection parameter. Details,
details.
Lee
On 5/11/2011 12:18 AM, Jody Garnett wrote:
All good questions; I think everything is coming out as a string (it
is only a csv file after all). If the user does a comparison against a
date with CQL then the string will do its best to convert to a date.
The goal with these things is to support what the file format
supports; as far as I know the CSV standard does not allow any
additional hints as part of the first row of values?
--
Jody Garnett
On Wednesday, 11 May 2011 at 3:20 PM, Ben Caradoc-Davies wrote:
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 bee parsed
as WKT
I think that would make it general purpose?
--
Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au
<mailto: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
