Hi,
There are two little issues that recently popped up in GRASS 7
- I performed a pairwise network analysis with v.net.allpairs.
The attribute table to the output map “map” that is produced is called “map_1” (note: _1 !!). Thus when I then try to export the attribute table to a csv using v.out.ogr I get following warning (which is of course net a problem):
db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
WARNING: Vector map <map_1> not found -->right, because there is no map_1, the map is called “map”
Is that an intended behaviour that the corresponding attribute table for v.net.allpairs gets a ending of “_1”?
- It seems that the option for the output in db.out.ogr is maybe set wrong (http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it really necessary that the outputfile already exists because the GUI asks to select a file rather than allow specifying the path to the file? I want to create a new csv with that module, so maybe the following needs to be changed from “old” to “new”:
#%option G_OPT_F_INPUT
#% key: dsn
#% gisprompt: old,bin,file
#% description: Table file to be exported or DB connection string
#% required : yes
#%end
best regards,
Johannes
On Wed, Apr 24, 2013 at 3:01 PM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi,
There are two little issues that recently popped up in GRASS 7
1) I performed a pairwise network analysis with v.net.allpairs.
The attribute table to the output map "map" that is produced is called
"map_1" (note: _1 !!).
This is because if a table with node attributes exists in the input
vector, this table is also copied to the output vector and should have
the name map_2.
Thus when I then try to export the attribute table to
a csv using v.out.ogr I get following warning (which is of course net a
problem):
db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
WARNING: Vector map <map_1> not found -->right, because there is no map_1,
the map is called "map"
Is that an intended behaviour that the corresponding attribute table for
v.net.allpairs gets a ending of "_1"?
2) It seems that the option for the output in db.out.ogr is maybe set wrong
(http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it really
necessary that the outputfile already exists because the GUI asks to select
a file rather than allow specifying the path to the file? I want to create a
new csv with that module, so maybe the following needs to be changed from
"old" to "new":
#%option G_OPT_F_INPUT
#% key: dsn
#% gisprompt: old,bin,file
#% description: Table file to be exported or DB connection string
#% required : yes
#%end
or simpler
#%option G_OPT_F_OUTPUT
#% key: dsn
#% description: Table file to be exported or DB connection string
#%end
Fixed in r55983.
Markus M
Hi,
@Markus M: Thank you for the fix.
However, somehow I am not able to export the attribute table that is created by v.net.allpairs.
There is nothing special with the v.net.allpairs operation, just 13 points along the network. The result
looks okay and the attribute table is as it should be. When I try db.out.ogr nothing is produced (db.out.ogr
works with other tables):
db.out.ogr input=map_1 dsn=/home/radinger/Analysis/test format=CSV
I get the warning above that the vector map <map_1> can not be found and there is no output created at
all. Can anyone reproduce that problem with a net.allpairs-attribute table?
/Johannes
···
On Wed, Apr 24, 2013 at 7:30 PM, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Wed, Apr 24, 2013 at 3:01 PM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi,
There are two little issues that recently popped up in GRASS 7
- I performed a pairwise network analysis with v.net.allpairs.
The attribute table to the output map “map” that is produced is called
“map_1” (note: _1 !!).
This is because if a table with node attributes exists in the input
vector, this table is also copied to the output vector and should have
the name map_2.
Thus when I then try to export the attribute table to
a csv using v.out.ogr I get following warning (which is of course net a
problem):
db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
WARNING: Vector map <map_1> not found -->right, because there is no map_1,
the map is called “map”
Is that an intended behaviour that the corresponding attribute table for
v.net.allpairs gets a ending of “_1”?
- It seems that the option for the output in db.out.ogr is maybe set wrong
(http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it really
necessary that the outputfile already exists because the GUI asks to select
a file rather than allow specifying the path to the file? I want to create a
new csv with that module, so maybe the following needs to be changed from
“old” to “new”:
#%option G_OPT_F_INPUT
#% key: dsn
#% gisprompt: old,bin,file
#% description: Table file to be exported or DB connection string
#% required : yes
#%end
or simpler
#%option G_OPT_F_OUTPUT
#% key: dsn
#% description: Table file to be exported or DB connection string
#%end
Fixed in r55983.
Markus M
On Thu, Apr 25, 2013 at 10:33 AM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi,
@Markus M: Thank you for the fix.
However, somehow I am not able to export the attribute table that is created
by v.net.allpairs.
There is nothing special with the v.net.allpairs operation, just 13 points
along the network. The result
looks okay and the attribute table is as it should be. When I try db.out.ogr
nothing is produced (db.out.ogr
works with other tables):
db.out.ogr input=map_1 dsn=/home/radinger/Analysis/test format=CSV
I get the warning above that the vector map <map_1> can not be found and
there is no output created at
all. Can anyone reproduce that problem with a net.allpairs-attribute table?
Yes, fixed in r55991. The db.out.ogr module was asking for an input
table and then used that name as vector name, that does not work.
Markus M
/Johannes
On Wed, Apr 24, 2013 at 7:30 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:
On Wed, Apr 24, 2013 at 3:01 PM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
> Hi,
>
>
> There are two little issues that recently popped up in GRASS 7
>
> 1) I performed a pairwise network analysis with v.net.allpairs.
> The attribute table to the output map "map" that is produced is called
> "map_1" (note: _1 !!).
This is because if a table with node attributes exists in the input
vector, this table is also copied to the output vector and should have
the name map_2.
Thus when I then try to export the attribute table to
> a csv using v.out.ogr I get following warning (which is of course net a
> problem):
> db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
> WARNING: Vector map <map_1> not found -->right, because there is no
> map_1,
> the map is called "map"
> Is that an intended behaviour that the corresponding attribute table for
> v.net.allpairs gets a ending of "_1"?
>
> 2) It seems that the option for the output in db.out.ogr is maybe set
> wrong
> (http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it
> really
> necessary that the outputfile already exists because the GUI asks to
> select
> a file rather than allow specifying the path to the file? I want to
> create a
> new csv with that module, so maybe the following needs to be changed
> from
> "old" to "new":
>
> #%option G_OPT_F_INPUT
> #% key: dsn
> #% gisprompt: old,bin,file
> #% description: Table file to be exported or DB connection string
> #% required : yes
> #%end
or simpler
#%option G_OPT_F_OUTPUT
#% key: dsn
#% description: Table file to be exported or DB connection string
#%end
Fixed in r55983.
Markus M
Hi Markus,
that is working now for me fine!! Thank you.
Just out of curiousity:
Could there be the case that there is a table that is not (anymore, yet) connected to a vector? In such
a case it is not possible to export the table as the input is defined by a vector map and the layer number?!
/Johannes
···
On Thu, Apr 25, 2013 at 11:17 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:
On Thu, Apr 25, 2013 at 10:33 AM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi,
@Markus M: Thank you for the fix.
However, somehow I am not able to export the attribute table that is created
by v.net.allpairs.
There is nothing special with the v.net.allpairs operation, just 13 points
along the network. The result
looks okay and the attribute table is as it should be. When I try db.out.ogr
nothing is produced (db.out.ogr
works with other tables):
db.out.ogr input=map_1 dsn=/home/radinger/Analysis/test format=CSV
I get the warning above that the vector map <map_1> can not be found and
there is no output created at
all. Can anyone reproduce that problem with a net.allpairs-attribute table?
Yes, fixed in r55991. The db.out.ogr module was asking for an input
table and then used that name as vector name, that does not work.
Markus M
/Johannes
On Wed, Apr 24, 2013 at 7:30 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:
On Wed, Apr 24, 2013 at 3:01 PM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi,
There are two little issues that recently popped up in GRASS 7
- I performed a pairwise network analysis with v.net.allpairs.
The attribute table to the output map “map” that is produced is called
“map_1” (note: _1 !!).
This is because if a table with node attributes exists in the input
vector, this table is also copied to the output vector and should have
the name map_2.
Thus when I then try to export the attribute table to
a csv using v.out.ogr I get following warning (which is of course net a
problem):
db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
WARNING: Vector map <map_1> not found -->right, because there is no
map_1,
the map is called “map”
Is that an intended behaviour that the corresponding attribute table for
v.net.allpairs gets a ending of “_1”?
- It seems that the option for the output in db.out.ogr is maybe set
wrong
(http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it
really
necessary that the outputfile already exists because the GUI asks to
select
a file rather than allow specifying the path to the file? I want to
create a
new csv with that module, so maybe the following needs to be changed
from
“old” to “new”:
#%option G_OPT_F_INPUT
#% key: dsn
#% gisprompt: old,bin,file
#% description: Table file to be exported or DB connection string
#% required : yes
#%end
or simpler
#%option G_OPT_F_OUTPUT
#% key: dsn
#% description: Table file to be exported or DB connection string
#%end
Fixed in r55983.
Markus M
On Thu, Apr 25, 2013 at 11:52 AM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
Hi Markus,
that is working now for me fine!! Thank you.
Just out of curiousity:
Could there be the case that there is a table that is not (anymore, yet)
connected to a vector? In such
a case it is not possible to export the table as the input is defined by a
vector map and the layer number?!
db.out.ogr uses internally v.out.ogr which is a bit against the logic
of db.* modules which should work with tables, not vectors.
You can still export any table with either db.select dumping to a text
file or with db.copy, adjusting from_database, from_driver,
from_table, to_database, to_driver, to_table.
Markus M
/Johannes
On Thu, Apr 25, 2013 at 11:17 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Thu, Apr 25, 2013 at 10:33 AM, Johannes Radinger
<johannesradinger@gmail.com> wrote:
> Hi,
>
> @Markus M: Thank you for the fix.
>
> However, somehow I am not able to export the attribute table that is
> created
> by v.net.allpairs.
> There is nothing special with the v.net.allpairs operation, just 13
> points
> along the network. The result
> looks okay and the attribute table is as it should be. When I try
> db.out.ogr
> nothing is produced (db.out.ogr
> works with other tables):
>
> db.out.ogr input=map_1 dsn=/home/radinger/Analysis/test format=CSV
> I get the warning above that the vector map <map_1> can not be found and
> there is no output created at
> all. Can anyone reproduce that problem with a net.allpairs-attribute
> table?
Yes, fixed in r55991. The db.out.ogr module was asking for an input
table and then used that name as vector name, that does not work.
Markus M
>
> /Johannes
>
>
>
>
> On Wed, Apr 24, 2013 at 7:30 PM, Markus Metz
> <markus.metz.giswork@gmail.com>
> wrote:
>>
>> On Wed, Apr 24, 2013 at 3:01 PM, Johannes Radinger
>> <johannesradinger@gmail.com> wrote:
>> > Hi,
>> >
>> >
>> > There are two little issues that recently popped up in GRASS 7
>> >
>> > 1) I performed a pairwise network analysis with v.net.allpairs.
>> > The attribute table to the output map "map" that is produced is
>> > called
>> > "map_1" (note: _1 !!).
>>
>> This is because if a table with node attributes exists in the input
>> vector, this table is also copied to the output vector and should have
>> the name map_2.
>>
>> Thus when I then try to export the attribute table to
>> > a csv using v.out.ogr I get following warning (which is of course net
>> > a
>> > problem):
>> > db.out.ogr input=map_1 dsn=path/to/csv/file.csv format=CSV
>> > WARNING: Vector map <map_1> not found -->right, because there is no
>> > map_1,
>> > the map is called "map"
>> > Is that an intended behaviour that the corresponding attribute table
>> > for
>> > v.net.allpairs gets a ending of "_1"?
>> >
>> > 2) It seems that the option for the output in db.out.ogr is maybe set
>> > wrong
>> > (http://svn.osgeo.org/grass/grass/trunk/scripts/db.out.ogr/). Is it
>> > really
>> > necessary that the outputfile already exists because the GUI asks to
>> > select
>> > a file rather than allow specifying the path to the file? I want to
>> > create a
>> > new csv with that module, so maybe the following needs to be changed
>> > from
>> > "old" to "new":
>> >
>> > #%option G_OPT_F_INPUT
>> > #% key: dsn
>> > #% gisprompt: old,bin,file
>> > #% description: Table file to be exported or DB connection string
>> > #% required : yes
>> > #%end
>>
>> or simpler
>>
>> #%option G_OPT_F_OUTPUT
>> #% key: dsn
>> #% description: Table file to be exported or DB connection string
>> #%end
>>
>> Fixed in r55983.
>>
>> Markus M
>
>
On Thu, Apr 25, 2013 at 12:18 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
...
db.out.ogr uses internally v.out.ogr which is a bit against the logic
of db.* modules which should work with tables, not vectors.
Note: db.out.ogr was born as "quick fix" shell script in GRASS 6.
Given the new possibilities of Python programming in GRASS 7, both
scripts db.out.ogr and db.in.ogr should be rewritten to avoid that the
v.*.ogr modules are called any longer.
markusN