I would like to do a very simple thing:
upload the bounding box for each geometry (areas, boundaries, lines) to the attribute table.
v.to.db does not seem to provide this functionality. Is there an elegant way for doing this?
Of course, I could write out the map using v.out.ascii in standard format, parse this file using Python and extract the bounding box for each geometry this way. Is probably not very elegant, but could lead to a working Python module.
Or would it be more useful to implement this functionality in v.to.db? (I did never program in C with GRASS, but maybe, I could try with some help...)
Just a quick idea, when an underlying postgres/postgis database is available:
- use v.out.ogr to import vector data to your postgis database, to testtable
- now db.connect and db.login
- when connected, something like "echo 'UPDATE testtable SET wkb_geometry=envelope(wkb_geometry)' | db.execute" should work
- but not yet in the attribute table... (?)
...maybe too difficult.
Christian.
--------------------------------------------------
From: "Christian Kaiser" <Christian.Kaiser@unil.ch>
Sent: Tuesday, January 05, 2010 6:28 PM
To: <grass-users@lists.osgeo.org>
Subject: [GRASS-user] Uploading bounding box of vectors to database?
Hi everybody,
I would like to do a very simple thing:
upload the bounding box for each geometry (areas, boundaries, lines) to the attribute table.
v.to.db does not seem to provide this functionality. Is there an elegant way for doing this?
Of course, I could write out the map using v.out.ascii in standard format, parse this file using Python and extract the bounding box for each geometry this way. Is probably not very elegant, but could lead to a working Python module.
Or would it be more useful to implement this functionality in v.to.db? (I did never program in C with GRASS, but maybe, I could try with some help...)
v.to.db does not seem to provide this functionality. Is
there an elegant way for doing this?
‘v.info -g’ will give you the bounding box, easy peasy.
MAP=your_map_name
v.db.addcol $MAP column=“north DOUBLE PRECISION,
south DOUBLE PRECISION, east DOUBLE PRECISION, west DOUBLE PRECISION”
eval v.info -g $MAP
echo “UPDATE $MAP SET north = $north, south = $south,
east = $east, west = $west” | db.execute
Hamish
Hamish,
Thank you for your answer. It seems to me that v.info -g prints out the region for all the map. What I would need is the bounding box of EACH geometry (area for instance) in the map, and not the map as a whole. Probably my question was not clear…
2010/1/5 Christian Kaiser <Christian.Kaiser@unil.ch>:
Thank you for your answer. It seems to me that v.info -g prints out the
region for all the map. What I would need is the bounding box of EACH
geometry (area for instance) in the map, and not the map as a whole.
Probably my question was not clear...
Thank you for the hint. I was not aware of the -r switch. I think I can create a small script doing what I want using the v.db.select -r. Thanks again to everybody who helped!
Christian
On 5 janv. 2010, at 23:14, Martin Landa wrote:
Hi,
2010/1/5 Christian Kaiser <Christian.Kaiser@unil.ch>:
Thank you for your answer. It seems to me that v.info -g prints out the
region for all the map. What I would need is the bounding box of EACH
geometry (area for instance) in the map, and not the map as a whole.
Probably my question was not clear...
v.db.addcol $MAP column="north DOUBLE PRECISION, \
south DOUBLE PRECISION, east DOUBLE PRECISION, west DOUBLE PRECISION"
eval `v.info -g $MAP`
echo "UPDATE $MAP SET north = $north, south = $south, \
east = $east, west = $west" | db.execute
With the latest efforts to offer a cross-platform solution:
How would a windows user solve this or apply your solution?
I am not interested in the actual solution but would rather point at the
fact that many scripts & tricks that process the results from various
GRASS commands such as the statistic modules rely on shel scripting.
How would a windows user solve this or apply your solution?
v.db.addcol, v.info, and v.db.update selected from the menus.
They'd have to figure out the SQL use from the examples in the help
pages (same as I do).
Martin's new fancy help search tool will tell you where in the
menus those modules can be found.
I am not interested in the actual solution but would rather
point at the fact that many scripts & tricks that process the
results from various GRASS commands such as the statistic
modules rely on shel scripting.
MSWindows users are going to have to rely on a lot of slow pointing
and clicking and cutting and pasting. it's the nature of it. as it's
impossible to describe that without spending a lot of time and
screenshots/screencasts, I've got to rely on the quickest and most
efficient way of expressing the method.
I understand your point, but I don't know a better way and I don't
scale all that well. Hopefully if the shell script stuff is foreign
to them they can at least take away the module names from it and study
the help pages, and maybe learn a little crazy unix magic in the
process.
