On 04/08/17 11:56, Markus Neteler wrote:
On Fri, Aug 4, 2017 at 11:51 AM, Moritz Lennert
<[email protected]> wrote:
On 29/07/17 17:59, Michael Barton wrote:
The db.out.ogr manual states for the input argument:
input=name [required]
GRASS table name
Or data source for direct OGR access
How do you specify the name of a table in the GRASS sqlite.db that is not
linked to vector objects?
Probably the manual could do with an update to reflect the fact that it only
works for existing maps. Maybe the input parameter should be renamed to
'map' ?
IMHO no - it refers to a *table*, not a map (the db.* commands have
generally no idea about maps but only about tables).
But internally, it uses v.out.ogr with input=input, and input in
v.out.ogr is defined as
options->input = G_define_standard_option(G_OPT_V_INPUT);
So it is a map. This is why you get:
g.copy vect=schools_wake,schools
v.distance -a from=schools to=schools table=distances_between_schools
up=cat,dist col=tocat,dist output=lines
db.out.ogr distances_between_schools output=distances_between_schools.csv
ERROR: Vector map <distances_between_schools> not found
ERROR: Module <v.out.ogr> failed
If we want to make db.out.ogr into a module to export any table to any
ogr compatible formats, we would probably have to use ogr2ogr within the
script (or the gdal python API).
I don't know how often people really need to transform tables into
something else than csv files. Personally, I find db.select more than
enough to move data from one database to another:
db.select table=distances_between_schools sep=,
out=distances_between_schools.csv
(or with the sql parameter if you want to select specific columns only).
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
