[gdal-dev] OGR Field Types?

[Stefan Keller]

Hi even

We've finished the GeoCSV spec. and we're almost ready to publish the
Editable GeoCSV plugin fpr QGIS.

So, I have following enhancement requests for the OGR CSV reader,
regarding CSVT:
1. Accept "WKT" (case insensitive) indicating WKT geometry field.
2. Accept "CoordX" and "CoordX" (in any order, case insensitive)
indicating easting/northing of a point geometry.
3. While opening the CSV file, look for .prj as coordinate reference
system/CRS (same CRS format like Shapefiles).

What do you think? Can I open an enhancement request for this?

Cheers, S.

2015-05-22 1:07 GMT+02:00 Stefan Keller <sfkeller at gmail.com>:
> 2015-05-22 0:53 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
> ...
>>> * "Easting","Northing"
>> X,Y or Geometry(X), Geometry(Y) or Point(X),Point(Y) would perhaps be easier
>> to get. I don't know.
>
> So let's propose Point(X),Point(Y) or PointX,PointY.
>
> -S.
>
>
> 2015-05-22 0:53 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
>> Le vendredi 22 mai 2015 00:33:43, Stefan Keller a écrit :
>>> 2015-05-21 23:34 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
>>> ...
>>>
>>> >> 4. "Geometry(Easting)","Geometry(Northing)"
>>> >
>>> > For points only I guess?
>>>
>>> Yes.
>>>
>>> >> 5. "Geometry" -- encoded in WKT; having subtype values WKT (default),
>>> >> Point, LineString, Polygon.
>>> >
>>> > "WKT" is not really consistant with Point,LineString,Polygon since the
>>> > later would be expressed as WKT I guess. So perhaps WKT, WKT(Point),
>>> > WKT(LineString), WKT(Polygon) ?
>>>
>>> Right, d'accord. So, let's introduce following two geometry types:
>>> * "Easting","Northing"
>> X,Y or Geometry(X), Geometry(Y) or Point(X),Point(Y) would perhaps be easier
>> to get. I don't know.
>>> * WKT, WKT(Point), WKT(LineString), WKT(Polygon)
>>>
>>> There are additional restricions to these geometry types:
>>> * "Easting","Northing" must co-occur and should be neighboring columns
>>> (in either order).
>> I guess most people would do that, but I don't see a strong rationale to
>> impose neighboring coumns
>>> * if WKT is given, all rows are expected to contain the same geometry type.
>> For generic WKT, all geometry types should be possible (as currently). Only
>> for WKT(xxxx), geometries should be restricted to the specified type.
>>> * There's only one geometry column per .csvt, namely either
>>> <<"Easting","Northing">> or <<WKT>>.
>> Kind of makes sense for Easting,Northing. But for WKT columns I don't see a
>> reason for such a restriction. Actually there's already a
>> secret/undocumented/debug mode in the CSV driver to read multiple geometry
>> columns (I won't reveal it unless I'm tortured, but you can look at the code).
>> This was mostly useful at the first stages when developing RFC 41.
>>
>>>
>>> OK?
>>
>> Not sure what kind of committment would be expected if I say "OK", so I'll
>> abstain ;-)
>>
>>>
>>> --S.
>>>
>>> 2015-05-21 23:34 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
>>> > Le jeudi 21 mai 2015 23:17:26, Stefan Keller a écrit :
>>> >> Hi Even
>>> >>
>>> >> I just see some type mod and subtype definitions for .csvt files in
>>> >> the CSV docs [1] :
>>> >> <<
>>> >> In a single line the types for each column have to be listed with
>>> >> double quotes and be comma separated (e.g., "Integer","String"). It is
>>> >> also possible to specify explicitly the width and precision of each
>>> >> column, e.g. "Integer(5)","Real(10.7)","String(15)". The driver will
>>> >> then use these types as specified for the csv columns. Starting with
>>> >> GDAL 2.0, subtypes can be passed between parenthesis, such as
>>> >> "Integer(Boolean)", "Integer(Int16)" and "Real(Float32)"
>>> >> <<
>>> >>
>>> >> Following questions and suggestions about .csvt:
>>> >> 1. Do type names really have to be in double quotes?
>>> >
>>> > No
>>> >
>>> >> 2. Is the separator always comma or can it also be a semicolon?
>>> >
>>> > Yes, always comma
>>> >
>>> >> 3. What about a Geometry type with subtypes? I suggest to add
>>> >> 4. "Geometry(Easting)","Geometry(Northing)"
>>> >
>>> > For points only I guess? Well you can build points with a OGR VRT from 2
>>> > CSV columns. I might perhaps add in some time an open option to specify
>>> > the columns for the easting/longitude and northing/latitude.
>>> >
>>> >> 5. "Geometry" -- encoded in WKT; having subtype values WKT (default),
>>> >> Point, LineString, Polygon.
>>> >
>>> > "WKT" is not really consistant with Point,LineString,Polygon since the
>>> > later would be expressed as WKT I guess. So perhaps WKT, WKT(Point),
>>> > WKT(LineString), WKT(Polygon) ?
>>> >
>>> >> What do you think?
>>> >> This could also make QGIS "Add Delimited Text Layer..." even better.
>>> >>
>>> >> --S.
>>> >>
>>> >> [1] http://www.gdal.org/drv_csv.html
>>> >>
>>> >> 2015-04-29 22:57 GMT+02:00 Stefan Keller <sfkeller at gmail.com>:
>>> >> > Salut Even,
>>> >> >
>>> >> > Merci!
>>> >> >
>>> >> > 2015-04-29 20:35 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
>>> >> >> Stefan
>>> >> >>
>>> >> >>> Questions:
>>> >> >>> 1. How is 'binary' encoded? E.g. when defining binary in a CSV file,
>>> >> >>> how is it encoded? Hex?
>>> >> >>
>>> >> >> There's no support in the CSV driver for binary data
>>> >> >>
>>> >> >>> 2. Can a field in a CSV input files have a IntegerList or a Binary?
>>> >> >>
>>> >> >> No. Well on writing, the IntegerList will be serialized as a string.
>>> >> >> But not recognized as IntegerList on reading
>>> >> >>
>>> >> >>> 3. What is the value delimiter in a field of type IntegerList,
>>> >> >>> Integer64List, RealList, StringList?
>>> >> >>
>>> >> >> The default serializatoin will be
>>> >> >> (number_of_elements:val1,val2,...,valn), but currently it is
>>> >> >> truncated to 80 chracters
>>> >> >>
>>> >> >>> 4. "Boolean, Int16, Float32" are mentioned as subtypes. Are there
>>> >> >>> more subtypes?
>>> >> >>
>>> >> >> Not currently. See
>>> >> >> https://trac.osgeo.org/gdal/wiki/rfc50_ogr_field_subtype
>>> >> >>
>>> >> >> Even
>>> >> >>
>>> >> >> --
>>> >> >> Spatialys - Geospatial professional services
>>> >> >> http://www.spatialys.com
>>> >
>>> > --
>>> > Spatialys - Geospatial professional services
>>> > http://www.spatialys.com
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com