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 <sfkel...@gmail.com>: > 2015-05-22 0:53 GMT+02:00 Even Rouault <even.roua...@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.roua...@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.roua...@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.roua...@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 <sfkel...@gmail.com>: >>> >> > Salut Even, >>> >> > >>> >> > Merci! >>> >> > >>> >> > 2015-04-29 20:35 GMT+02:00 Even Rouault <even.roua...@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev