[GRASS-user] v.in.ascii with undefined columns?

[patrick s.]

Thanks, Markus- Coming back on your answer(s) after my vacation:

Apparently my question was a bit unclear, so I will clarify the problem 
even if you answered it. Maybe this can help other users:
I often find myself with tables in form of txt-files/csv-files that have 
two columns defining coordinates. These files have multiple additional 
columns with labels and datatypes (content) that are not known. Such 
tables can easily be loaded in many programs as OpenOffice, QGIS 
(csv-importer) and R, so I was searching for a simple way to import them 
to GRASS.
However, as I understand now, these other programs include routines to 
estimate the data-type and query the column-names, while GRASS 
explicitly demands a definition on labels and type of the user (BTW- 
similar to PostgreSQL). In consequence the (maybe not best but) fastest  
approach to load such data, is to transform them outside GRASS into a 
spatial format that can directly be loaded as spatial points by GRASS. 
Shapefile used to be such a format in the past, but has important 
drawbacks, e.g. the abbreviation of column-labels. The recommended 
approach is SQLITE, instead.

As Alternative the db.in.ogr-command allows to load csv-files into 
GRASS, but misses the option to create spatial points out of the 
coordinates. Furthermore this might need guidance on the data-type 
through a .csvt-file (see manual db.in.ogr).

Patrick



On 11.08.2015 23:13, Markus Neteler wrote:
> On Thu, Aug 6, 2015 at 10:04 AM, patrick s. <patrick_gis at gmx.net> wrote:
>> Dear all
>>
>> I want to import multiple csv-files with coordinates (points) that come from
>> Excel/SPSS, having first row as header. These have undefined labels of
>> columns
> Can you please explain a bit more "undefined labels of columns"?
> Is it that you don't know the column type? Or the name of them?
>
> If the former, you can use a .csvt file in case you import from CSV.
> For an example, see
> https://grass.osgeo.org/grass70/manuals/db.in.ogr.html#import-csv-file
>
>> that need to be available in grass and that might change in future.
>> Running grass on dbf-backend,
> As mentioned earlier: when it comes to real attribute data processing,
> better use the SQLite backend:
> faster, long column names etc.
>
>> I used to create shapefiles in R and import
>> these with v.in.ogr. However, this does not seem to be appropriate, when
>> running grass on sqlite (abbreviation of columnnames).
> Note that the SHAPE format already abbreviated it!
>
> You may consider the Spatialite format for exchange. I just proposed
> it as best option for the Rgrass7 interface (in the grass-stats
> mailing list).
>
>> There seem to be
>> different solutions, but I am what is the recommended approach. Hopefully
>> you can give me a hint.
>>
>> Thanks,
>> Patrick
>>
>> ##Current ideas:
>> #Version 0
>> create shapefile in R
>> (http://gis.stackexchange.com/questions/30785/how-to-stop-writeogr-from-abbreviating-field-names-when-using-esri-shapefile-d)
>> import shapefile with v.in.ogr
> --> since this goes "through" DBF then, the column name cutting has happened.
>
>> #Version1
>> query csv and create file "coldef" with Column definition in SQL style (in
>> shell or R?)
> ...even in shell, see the db.in.ogr manual page for an example or the
> CSV driver page of OGR.
>
>> import in grass with v.in.ascii format=point skip=1 columns=coldef
> Yes.
>
>> #Version2
>> create sqlite-file in R/OGR with SPATIALITE-extension (see
>> https://stat.ethz.ch/pipermail/r-sig-geo/2014-July/021313.html)
>> import in grass with v.in.ogr
> Yes, best solution I think.
>
>> (this post mentions problems
>> http://gis.stackexchange.com/questions/1733/how-to-import-spatialite-data-into-grass)
> ... that posting is from 2010 - a lot has happened since then :-)
>
> Markus