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 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
