Re: [GRASS-user] Uploading bounding box of vectors to database?
Hi, 2010/1/5 Christian Kaiser : > 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.select -r ? Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Uploading bounding box of vectors to database?
On 5 janv. 2010, at 22:38, Hamish wrote: > Christian Kaiser wrote: >> 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? > > > '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... ;-) Any idea? Christian___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Uploading bounding box of vectors to database?
Christian Kaiser wrote: > 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? '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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] georectify probleme
Hi
I tried georectify a historical map, but under the wxpython gui I run
into this message when I tried zooming the historical map:
Execution failed: 'd.rast map=racalmas@permanent --q'
Details:
Error: region for current mapset run
"g.region"
and
this message turn up under the tcl/tk gui when I tried click on
georeferenced map:
can't read "b1coords": no such variable
while executing
"$geoentry insert 0 $b1coords"
invoked from within
"if { [info exists geoentry] } {
$geoentry insert 0 $b1coords
}"
(command bound to event)
Can somebody help me?:)
Thanks: Balazs
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Uploading bounding box of vectors to database?
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" Sent: Tuesday, January 05, 2010 6:28 PM To: 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...) Thank you for any suggestion. Christian Kaiser ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stream.order error
Hi All during updating svn I made an error so there is old, corrupted version of r.stream.order. Tomorow (about 12AM CET) I will update it in svn repository. If someone need good version now, I suggest change change line 305 of io.c: from: sprintf(out_table,"%s",in_table) to: out_table=in_table; it shall help I apologies for problems. Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[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...) Thank you for any suggestion. Christian Kaiser ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Major update of r.stream.order and r.stream.basins. New module: r.stream.pos
Great updates to already great modules. Thanks for the contribution. I will likely be compiling these in the upcoming week(s). Mark 2010/1/5 Jarosław Jasiewicz : > Hi all! > > A have made major update with r.stream.order and r.stream.basins: > > r.stream.order new functionality: > > - it can now create table to store drainage network topology. This table can > be added to r.stream.extract vector file. For more details see > description.html > > r.stream.basins new functionality: > > - much easier stream selection: now we can type only stream categories to > create basins. No map algebra is necessary > - r.water.outlet functionality added to r.stream.basins (define outlet by > coordinates) > - definition of outlets by vector point file > > > r.stream.pos > > this is a helper module for linear geostatistics and local stream properties > analysis. Nothing exciting > > PS. > > I have a problems with svn repository. If there are some problems with > downloading or compiling please let me know, I will try to update as soon as > possible. > > greetings > Jarek > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map Advice
If you really need to have full control on your "virtual printer" output, have a look at gs arguments : http://www.ghostscript.com/doc/7.07/Use.htm > you might calculate what resolution gives you 300dpi by measuring the > width of the printed map box in inches and multiplying by the desired > dpi. any thing more than that is wasted disk space, > Hamish Well, in the context of high quality press output it's a bit more delicate ; depends on what image you produce (b&w, grayscale, color), what printing device it is (inkjet printer, laser printer, offset press... each having different lineature values and different frame types), and paper quality. Then, as you say, 300 dpi : * is most often enough for common color map printing * should be increased to 600 dpi for b&w images e.g. text+thin black contour lines on a white bg to be sent on a laser printer, andbut should be considered the least acceptable resolution for high quality paper production. I agree that it's useless beyond 600 dpi. Yours, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: header
Rich wrote: > The man page tells me that the header section of the input file > will print the map title and location (if known) centered above the > map if there is no file specified. When I specify a file the header is > printed left-justified. correct. > Is there a way to have the header centered when the > text file is specified? use the spacebar a lot? ;) or use the 'text' instruction instead with y% as -5% or 105% or so.. looking in the ps.map/do_header.c source code there is in fact a lot of rather interesting & undocumented formatting magic available. (I looked because there's often a lot of old p.map goodies lurking about in there waiting to be discovered) %% - literal % %n - ??? newline %_ - horizontal bar %d - date %l - location name %L - Location's text description %c - "<%s> in mapset <%s>" %m - mapset name %u - user name %x - mask info %- - proceed to this char column number (? see example) and example is given in the GRASS 5 source code: grass-5.4.1/src/paint/Programs/p.map/cmd/HEADER %_ LOCATION: %-27l DATE: %d MAPSET: %-27m USER: %u RASTER MAP: %c MASK: %x %_ Produced by: US Army CERL, Champaign Illinois Software:GRASS %_ I've now added this to the ps.map help page. if anyone has a better idea how %n and %- should work, please post. I expect for %-#x you will want to use a fixed-width font.. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] g.parser's Module/header options
Hey you all I'm reading g.parser description from GRASS website and I'm reading a description of "typical header definitions" and notes. What I wanted to know is where I can find a description of all parameters (e.g. key, type, description, multiple, ...) that are available and that is possible to know. Thanks Luis L. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Major update of r.stream.order and r.stream.basins. New module: r.stream.pos
Hi all! A have made major update with r.stream.order and r.stream.basins: r.stream.order new functionality: - it can now create table to store drainage network topology. This table can be added to r.stream.extract vector file. For more details see description.html r.stream.basins new functionality: - much easier stream selection: now we can type only stream categories to create basins. No map algebra is necessary - r.water.outlet functionality added to r.stream.basins (define outlet by coordinates) - definition of outlets by vector point file r.stream.pos this is a helper module for linear geostatistics and local stream properties analysis. Nothing exciting PS. I have a problems with svn repository. If there are some problems with downloading or compiling please let me know, I will try to update as soon as possible. greetings Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: labels
Rich: > The file proj_pnt.lab contains the v.label command specifying map, > attribute column, and x/y offsets. as in the shell command to make the label file? ps.map expects the processed file, not the command to the program that creates it. (among other things this allows you to tweak the generated label file by hand. ie the name you passed to v.label's label= option. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: labels
Rich wrote: > I understand v.label and v.label.sa, but I don't understand how > to use the former within a ps.map input file. I have: > > labels proj_pnt.lab > font Times-Roman > end > > but ps.map tells me it cannot find that file. The file proj_pnt.lab > contains the v.label command specifying map, attribute column, and > x/y offsets. > > What have I missed here? I don't know. does your label file show up with "g.list labels" ? this works for me: #spearfish v.label lab=arch.lbl map=archsites column=str1 fontsize=8 ref=lower g.region rast=elevation.dem ps.map out=test.ps << EOF raster elevation.dem vpoints archsites end labels rush.lbl end labels arch.lbl font Times-Roman end end EOF I notice that v.label.sa has a little bug in that it does not like PostScript font names, its parser only expects to take installed TTFs. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map Advice
Rich: > I suppose that for printed output purposes (separate from analytical > purposes), I can make the resolution even more coarse. > > Sure enough. 20m resolution makes a 0.5M pdf and the page looks just as > good as it did before. ... > Running 'g.region -m' revealed that the resolutions were much too fine: > about 2m each direction. I changed that to 10m for both nsres and ewres and > the final .pdf is about 2.8M. I suppose that for printed output purposes > (separate from analytical purposes), I can make the resolution even more > coarse. you might calculate what resolution gives you 300dpi by measuring the width of the printed map box in inches and multiplying by the desired dpi. any thing more than that is wasted disk space, anything less causes a cruddier printout. be aware that many ps->pdf converters silently convert your image to a 72dpi jpeg or so; if you want higher quality you have to pass ghostscript/whatever some extra flags: http://grass.osgeo.org/wiki/Ps.map_scripts#Converting_PostScript_to_PDF > Once I get the system down I'll output to .eps for inclusion in LaTeX. beware that if you use .eps instead of .ps that any SCALE 1:xx,xxx written on your map will become invalid. (with .ps we can guarantee that 1" is 1" when printed) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.shade.relief: Results Not As Expected
> Run r.slope.aspect on the interpolated map, and check for grid-like > artifacts. e.g. in the spearfish dataset if you set the "slope" map's colors with r.colors slope color=bcyr you can see the effect in the elevation.dem map. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while using Wxpython vector digitizer
Hi, 2010/1/5 Franz Schiller : > I have : > SWIG Version 1.3.40 > Compiled with g++ [x86_64-unknown-linux-gnu] > It's a later version that 1.3.36. Is there any thing that is not compatible > with swig 1.3.40 but only with 1.3.36? yes, see http://trac.osgeo.org/grass/ticket/782 Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Temporary files in GRASS Script
Nikos Dumakis wrote: > Following a few questions/emails from Glynn and Antonio regarding GRASS > Scripting I have the following question: > What is the main difference between Temporary files creation mentioned in > Glynn emails: > > *tmp=tmp.myscript.$$* > > * > * > > *And the one used in r.centroid script:* > > TMP=$$ > > TMPFILE=`g.tempfile pid=$TMP` The former creates a name with a given format ($$ is the PID of the shell process running the script). g.tempfile creates a temporary file at: ///.tmp//. where is chosen such that the name is unique (for g.tempfile, it will usually be zero; if a process calls G_tempfile() multiple times, will increment). Use the former (or something like it) if you want a name for a temporary map, region, etc. Use the latter if you need a file. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.shade.relief: Results Not As Expected
Rich Shepard wrote: > > Run r.slope.aspect on the interpolated map, and check for grid-like > > artifacts. > > Glynn, > >Did this. Yes, there is a grid-like appearance to the resulting map. > > > How good is the underlying data? If it's noisy, it may need to be > > filtered before interpolating. > >How do I check for noisy data? I have all the basic information about the > source data and derived maps. One trick is to create a filtered map with e.g. r.neighbors method=average or r.mfilter.fp, and subtracting the original map from the resulting map. This will help to highlight any artifacts introduced by processing of the source data. Any such processes should be performed at the map's native resolution, to ensure that artifacts aren't introduced by nearest-neighbour resampling. One thing which can introduce grid-like artifacts is nearest-neighbour resampling (including re-projection) at near-unity scale factors. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Temporary files in GRASS Script
Greetings all Following a few questions/emails from Glynn and Antonio regarding GRASS Scripting I have the following question: What is the main difference between Temporary files creation mentioned in Glynn emails: *tmp=tmp.myscript.$$* * * *And the one used in r.centroid script:* TMP=$$ TMPFILE=`g.tempfile pid=$TMP` Thanks Best regards, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.shade.relief: Results Not As Expected
Have you tried a different azimuth? Sometimes certain values can cause features to look inverted for given terrain conditions. Mark On Jan 4, 2010, at 8:32 PM, Rich Shepard wrote: On Tue, 5 Jan 2010, Glynn Clements wrote: Run r.slope.aspect on the interpolated map, and check for grid-like artifacts. Glynn, Did this. Yes, there is a grid-like appearance to the resulting map. How good is the underlying data? If it's noisy, it may need to be filtered before interpolating. How do I check for noisy data? I have all the basic information about the source data and derived maps. Also: which version of GRASS are you using? 6.5svn. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.shade.relief: Results Not As Expected
On Tue, Jan 5, 2010 at 2:32 AM, Rich Shepard wrote: > On Tue, 5 Jan 2010, Glynn Clements wrote: > >> Run r.slope.aspect on the interpolated map, and check for grid-like >> artifacts. > > Glynn, > > Did this. Yes, there is a grid-like appearance to the resulting map. this sounds like a resolution mismatch. If you want to significantly change the resolution of a raster DEM, use - r.resamp.interp - Resamples raster map layers to a finer grid using interpolation. - r.resamp.stats - Resamples raster map layers to a coarser grid using aggregation. >> How good is the underlying data? If it's noisy, it may need to be >> filtered before interpolating. > > How do I check for noisy data? I have all the basic information about the > source data and derived maps. Using r.shaded.relief gives a good visual impression. Or create a polar diagram of the aspect map: r.slope.aspect mydem aspect=myaspect d.polar myaspect >> Also: which version of GRASS are you using? > > 6.5svn. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM Issues
Rich, On Tue, Jan 5, 2010 at 1:56 AM, Rich Shepard wrote: > I don't know if this is best done off the list or on it, but I cannot > create shaded relief, slope, aspect, pcurve, or other maps from my project > area DEM. There must be something elemental that I'm missing despite reading > the GRASS book (2nd ed.) and man pages. If there's anything on the Wiki I > missed it. what's happening? In general: g.region rast=dem_1m -p r.slope.aspect dem_1m slope=slope_1m aspect=aspect_1m r.shaded.relief dem_1m > I have all the projection, resolution, and other data for the original DEM > (from the accompanying metadata), the imported raster map, and the resampled > 1m map (the last from r.info) and will provide those if it helps. Perhaps just post the errors for now? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
