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.roua...@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 <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 > > -- > 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
