#125: quote around char attributes in ascii files may generate problems with
v.in.ascii
------------------------------------------------------------------------------+
Reporter: ct529 | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.0
Component: default | Version: 6.2.3
Keywords: quotes, inverted commas, v.in.ascii, text file, csv file, import |
------------------------------------------------------------------------------+
Supposed you have an ASCII file (comma separated), where the first column
is a character column, and is automatically generated by either R,
openoffice calc, kspread, MS W Escle, or any gis package using text
export. The data in each cell will be surrounded by quotes (") aka
inverted commas.
If you try to load the file using the v.in.ascii command, it returns the
error "ERROR: x column is not of number type" whatever the type of the x
column.
To fix the problem, you have to remove the quotes around the values in the
first column. Quotes around values in other columns do not seem to be
important.
It should be fixed because all of the above packages correctly export
character column with quotes around the values.
#125: quote around char attributes in ascii files may generate problems with
v.in.ascii
--------------------------+-------------------------------------------------
Reporter: ct529 | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: 6.2.3
Resolution: | Keywords: quotes, inverted commas, v.in.ascii, text file, csv file, import
--------------------------+-------------------------------------------------
Changes (by hamish):
* priority: major => minor
* type: defect => enhancement
* milestone: 6.3.0 => 6.4.0
Comment:
Using a comma as the delimiter is problematic as text phrases often
contain them, eg "Spearfish, SD".
Stripping the quotes should not be the default mode because a text string
could include " as a valid last char.
so if this is to happen, it should be done as an optional flag.
Alternatively we could add advice to the v.in.ascii help page explaining
the problem and asking the user to export using a less common delimiter,
like "|". (not always possible if the data came from somewhere else or
lacking software)