[gdal-dev] OGR Field Types?

Sun Jun 7 04:46:30 PDT 2015

Salut Even

You're right again. It should be "OGC WMS-format Coordinate Reference
Systems" not ESRI WKT!
I've updated the GeoCSV spec. [1] - and the Editable GeoCSV plugin
(per next week).
And I've entered finally an OGR issue for this enhancement [2].

Cheers, S.

[1] http://giswiki.hsr.ch/GeoCSV#PRJ_file_format_specification
[2] https://trac.osgeo.org/gdal/ticket/5989

2015-06-05 9:50 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
> Hi Stefan,
>
>>
>> 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).
> Hum, ESRI WKT so ? I would have rather recommanded the OGC WKT format (the one
> natively spoken by GDAL, based on OGC 01-009
> http://www.opengeospatial.org/standards/ct), that has the advantage of
> including EPSG codes explicitely. If you'd want to be up-to-date, there's also
> the WKT 2 / ISO TC 211 format (
> http://docs.opengeospatial.org/is/12-063r5/12-063r5.html ), but GDAL doesn't
> handle it yet.
>
>>
>> What do you think? Can I open an enhancement request for this?
>
> Yes, I might have a look at that while doing something related in the CSV
> driver.
>
> Even
>
>>
>> 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
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com