Re: [GRASS-user] Open source GIS cataloging software?
Jonathan Greenberg wrote: Sorry for the cross-posting. I was wondering if anyone has a unix (preferably) or windows program that can spider a directory, recursively searching for raster and vector data, and create bounding box polygons for each raster/vector it finds, with attributes indicating the path-to-file. Thanks! I suppose you could put something together with `find + xargs`, and then try gdalinfo and ogrinfo against everything you find, then collect and collate the results. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] troubles with i.landsat.rgb and d.rgb
Renae Mackas wrote: I have used r.ing.dal to import different Landsat TIFF images, and am now trying to superimpose red, green, and blue spectral bandsto get real colour images. I am under the impression that I need to use i.landsat.rgb to auto-balance the colours of the LANDSAT images I am using. you do not need to use i.landsat.rgb, it just helps brighten things up if the image comes out rather dark. example: http://bambi.otago.ac.nz/hamish/grass/landsat/ I am using a PC, does that mean you are running MS Windows? native or cygwin version? (sorry to be overly pedantic, but consider that many run linux on a PC, and that historically many/most? GRASS users use some flavour of Linux) and when I run the command: i.landsat.rgb red=020.020.2000.055_B30 green=020.020.2000.055_B20 blue=020.020.2000.055_B10 a microsoft windows window pops up that informs me r.univar.exe has stopped working- a problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is vailable. As long as I continue to run the i.landsat.rgb command, this window continues to pop up. can you run r.univar 020.020.2000.055_B10 from the command prompt? Have I made a mistake somewhere?? don't really know. might be an install problem. can you view the scene ok in QGIS? (www.qgis.org) Also, once (if?) I do get i.landsat.rgb to work, will the map display window automatically show me the superimposed images?? no. if you are currently viewing the layers you have to do a hard redraw as the GUI isn't aware that the colors have changed behind its back and the existing view may be partially cached. Also, I have tried just running d.rgb on the same images: d.rgb red=020.020.2000.103_B30 blue=020.020.2000.103_B20 green=020.020.2000.103_B10 if this is the native build d.rgb shouldn't work from the command prompt, as there are no xmon to draw to (d.mon + UNIX's X-Windows). Instead use the 'Add RGB or HIS layer' button from the GIS manager. the cygwin version uses X-Windows (aka X11) and so allows xmons. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net.iso usage - including speed as factor
Darren Cope wrote: I'm trying to calculate drive time 'zones' using v.net.iso. I've worked through the examples using spearfish data, and seem to get suitable results using only the line 'distance' as the factor. However, I'd like to include the speed limit as another factor in the calculation, and can't seem to find any examples of how to do this. look in the help page for v.net.path for a speed limit example. (cost is inverse) good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] sample bash script for multiple mapsets
maning sambale wrote: In a single script I would like to: open a mapset and do vector processing, then, open another mapset, import vectors from previous mapset continue processing. Any psuedoscript to do this? is it all in the same location? if so you can use g.mapset (no s) to change the current mapset, then refer to other mapset maps as mapn...@othermapset. (imagery modules need work here) no need to import anything. if not you could still use g.mapset to change the location, but it is probably safer/more sane to use GRASS_BATCH_JOB to drive the process to leave restart GRASS in the new location and run v.proj, maybe with another script to drive the overall job. will the g.gui GUI be needed? that might complicate things for g.mapset. TODO: finish script to create a new location with command line params from outside of GRASS (See thread from ~2 weeks ago) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] mossy grass seeds
Hi, Inspired by Benjamin's rather nice OS/archaeology presentation[1] I was reading a piece[2] by Carl Reed (CTO of the OGC) about his work on MOSS GIS from the late 70s - early 80s while at the US FWS. MOSS was a vector GIS [and Carl claims the first interactive user GIS] early GRASS [several years later, but there was some overlap] was primarily a raster GIS so I don't think there would be much code overlap*. None the less, the two names demonstrate a clear influence in the tradition of pine/elm, pico/nano, less/more and certain ideas+terminology seem to be inherited such as mapsets. [1] ftp://88.208.250.116/ducke-frankfurt-foss-gis-arch.pdf [2] http://www.scribd.com/cnreed [*] but v.out.moss in GRASS 5 was written by MOSS developers, maybe some SDTS stuff too? just curious: was GRASS just cheeky naming by a competing US Gov't GIS team or was there tangled roots in the early days? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] how to get instantaneous heading of a line at a pt?
Hi, I have used v.to.points to create a series of points that fall along a line. Now I want to upload to a DB column in the points map the instantaneous heading of the original line at that sample point. any ideas? thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.generalize for area boundaries?
Hi, I am following the v.generalize tutorial at http://users.ox.ac.uk/~orie1848/tutorial.html (we should move that to the wiki before it disappears) but it doesn't say much about working with areas beyond removing small ones. I have a vector area which has a very steppy boundary, like from r.to.vect with a sawtooth pattern at the cell edges. I want to run a smoothing filter over it to get rid of the jaggy bits. No matter what method I try my output map is always the same as the input map, no vertices are created or destroyed. any ideas how to do this? I know about 'v.clean tool=prune' and Markus Metz's topology-preserving v.simplify (psst- add it to wiki addons) but I'd like to learn more about how to use v.generalize. thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Jan Hartmann wrote:
With that in mind, if the algorithm you propose would be indeed an
approximation to weighted Voronoi polygons, *and* it wouldn't be
all to hard to implement (I have no idea about that), would it make
sense to propose this as a new RFC for GRASS?
Glynn wrote:
I mean only that it cannot be done using the approach which
r.grow.distance uses, using memory proportional to the number of
columns (it uses a number of row buffers, i.e. one-dimensional arrays,
with one element per column).
[In any case, weighted distances won't produce polygons; at least, not
for Euclidean distances. The boundary will only be a straight line if
the weights are equal.]
However, that doesn't meant that other algorithms wouldn't be
feasible, particularly if you're only interested in typical behaviour
rather than worst-case behaviour.
Also, it may be possible to use the r.grow.distance approach with
something other than scaling. An offset would work, optionally
combined with a monotonic function of the distance (provided that it's
the same for every point).
Hi,
just some brainstorming ideas for a weighted Voronoi module:
input: vector points with weight column
output: raster map with weighted Voronoi polygons (or r.to.vect built in)
the module would create 2 raster maps:
- one with each vector point expanded to a 2.5D hemisphere of influence
bubbles centered over it, map value being the bubble height, similar to
r.cost or when you lose in the old Missile Command arcade game.
- the second map being a categorical raster containing the vector cat
which has contributed the maximum bubble at each cell.
e.g.
canvas_map = all zeros;
loop over vector_pts
{
bubble_height_at_cell = some_calc();
if ( bubble_height_at_cell canvas_map(row,col) ) {
canvas_map(row,col) = bubble_height_at_cell;
id_map(row,col) = current_vect_cat;
}
}
when done the 2.5D map can be discarded. [low weight points have no area]
id_map contains the vector point of note for that area.
other ideas:
- use r.param.scale to create a feature map and extract all saddle-point
boundaries between the bubbles as the voronoi boundaries,
(or r.slope.aspect and find areas where slope1 deg then r.thin, r.to.vect)
- use some mountain peak prominence algorithm* on the 2.5D map starting at
each input vector pt.
[*] http://article.gmane.org/gmane.comp.gis.grass.user/19467/
- see v.surf.icw script in addons for other radial basis function ideas
for the bubbles beyond the usual IDW 1/distance^2.
well, ideas are somewhat abstract/vague, but perhaps something in it.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Jan wrote: Wouldn't this work with cost surfaces too? Starting from several points (the Thiessen centers) with a grid cell cost information raster containing only the value one, you get a raster representation of a classic Thiessen structure. Manipulating the cost information raster , you should get something like a weighted Thiessen structure. The last step would be to extract the boundaries between the polygons in vector format, with the methods above. Starting from each center point, the cost surface will rise, until it meets the rising surface from an adjacent point. At this location, slope becomes zero. These zero slope areas are effectively the Thiessen polygons, and can be vectorized. For normal Thiessen polygons, this should be no problem, but I am not sure what happens with really complex weighted cases. Does anyone have any experience with this? right, the idea is to apply the wealth of landscape analysis modules to the cost surface (or whatever) instead of a real DEM. Lots of power there just waiting to be harnessed. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.generalize for area boundaries?
Wolf wrote: I'll see if I can whip up an example for you. Okay here is what I did: r.to.vect input=geology output=test v.generalize method=snakes input=test output=snakes It produces nice straight lines and with method=douglas threshold=30 you can get it even better (note that the cell size was 30m) Also note that the method=snakes I used simply the default values for alpha and beta. same here. [added feature=area for r.to.vect] proposed example for the help pages based on that: # spearfish g.region rast=geology r.reclass in=geology out=geology.claysand EOF 8 = 8 claysand EOF r.to.vect in=geology.claysand out=geology_claysand feature=area v.generalize in=geology_claysand out=geology_claysand_smooth method=snakes ah, I see the problem now, I need to run v.build.polylines first, then it works ok. Problematic vector attached. Hamish: http://users.ox.ac.uk/~orie1848/tutorial.html (we should move that to the wiki before it disappears) Wolf: That page and the images exists in the svn too. where in svn? How does one go about adding extra manual pages? what kind of man page did you have in mind? Or perhaps we could integrate it into the manual page itself? the module man page is already quite large. There are so many options, I'd prefer a wiki page with an explanation example (incl screenshots) of each method. The tutorial at users.ox.ac.uk is a great start for that. It is extensive enough that I think retaining a separate tutorial is justified. Helena: I would strongly suggest to integrate at least the most important info into the man page. Nobody maintains tutorials and other extra docs and they become quickly obsolete. Also many people use man pages so there is a better change of fixing / enhancing explanations if necessary, 2c: I believe the wiki is alive enough that it gets maintained. It is not as integrated strictly updated, but not collecting dust like the GDP in the web pages either. Also images are not seen by `man`, add significantly to the bulk of the source distribution, and integrate nicely in MediaWiki. for v.generalize the bare description.html file is already 250 lines long, so presumably already contains most important info. (although no examples) thanks, Hamish blocky.vasc.gz Description: GNU Zip compressed data ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unable to install Grass
Jimmy wrote: I m trying to install Grass on my PC. I recieived a Cygwin Setup window which says: Unable to get setup.ini from http://geni.ath.cx/grass in the instructions at http://grass.osgeo.org/grass62/binary/mswindows/ you will see setup.ini at the top of that page, and it says: At step #3 use http://grass.ibiblio.org/grass62/binary/mswindows/ (or a local mirror) instead of http://geni.ath.cx/grass.; good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to get instantaneous heading of a line at a pt?
Hamish: I have used v.to.points to create a series of points that fall along a line. Now I want to upload to a DB column in the points map the instantaneous heading of the original line at that sample point. Markus: This functionality might be added to v.to.db - perhaps using Vect_get_node_line_angle(): http://download.osgeo.org/grass/grass6_progman/level__two_8c.html#a16 hmmm. at a node there are two lines, the fn wants to know which one. I have a point somewhere along the line (between two vertices) and want to #1 find the polyline, #2 extract the current linear feature (between two nearest connected vertices), and #3 calc the angle of that line. I see now the corner case of if the point falls exactly on a vertex or a node you will have to average to angles of the lines on either side. I don't think v.to.db could help other than the overall bearing from the polyline's start node to end node. Remember a single line cat can only hold a single value. 'v.distance upload=to_angle' might be something... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: FW: [GRASS-user] unable to install Grass
Jimmy wrote: I m really struggling to install Grass on my PC!!! I've tried leads provided below but it still won't work. Error msg reads: Unable to get setup.ini from http://download.osgweo.org/osgeo4w probably you are very close, there is simply a typo in the above http://download.osgweo.org/osgeo4w should have osgeo.org, not osgweo.org. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] library problem with i.landsat.toar
Christine Sandmeier wrote: I wanted to install the i.landsat.toar - addon, following the instruction in the README-file (make MODULE_TOPDIR=$HOME/grass64/), I also made ./configure before and also was grass already built, or are you adding to a packaged binary version? make lib, which says Nothing to do for target »lib«! that should be make libs not make lib but when I try to start the i.landsat.toar addon, it says Incompatible library version for module. I recompiled grass, but this didn't help. you might have to remove any other version of grass to keep it from getting confused (generally this isn't needed, but may help if the local system has gotten mixed up). another way if you fully build grass from source is to copy the i.landsat.toar/ directory into the imagery/ dir in the main grass source code, and after grass has built cd imagery/i.landsat.toar/ and run make with no arguments. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: FW: [GRASS-user] unable to install Grass
Jimmy wrote: Still no luck!! what does the (exact) error message say now? same but without typo? does your proxy server require a username and the installer doesn't give you an option to enter that? for what it's worth, there does appear to be a setup.ini file in: http://download.osgeo.org/osgeo4w/ I haven't tried to run the OSGeo4W installer myself yet, so I'm just guessing... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpolation on a Grid
Frank Aragona wrote:
I'd like to do an interpolation of xyz data points that
I have, and put the interpolated data on 100' x 100'
grid. So that each 100' x 100' square has an
associated elevation value. Any suggestions as to how best
to do this?
Hamish:
depending on how many input points you have either:
v.in.ascii, g.region res=100, v.surf.rst
or for massive datasets (1-3 million points):
g.region res=100, r.in.xyz, r.to.vect, v.surf.rst
choice of method and {r|v}.surf.* interpolation module are subject to
nature of data personal preference. see also r.surf.nnbathy in wiki
addons. the modules' manual pages should help you decide.
Frank wrote:
But I'd like the interpolated surface to be a set of
100' x 100' vector grids, each 100 x 100 square with
a discrete elevation value. Is this possible?
after import binning as a raster use v.mkgrid to make your 100x100 grid,
then use v.what.rast or v.rast.stats to give each square an elevation
value. or maybe r.to.vect is easier?
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display output question
Michael wrote: If you want to replicate a complex display with overlaying maps it is more complicated than this even. The maps need to be composited. We use g.pnmcomp. The input is a series of PNM maps and optionally their transparency masks; the output is a single, composite PNM file. which can be Save As..'d from the menu. if there path to that file was known, the user could also copy it away (probably passing it through pnmtopng) to save a few mouse clicks. but I don't think batch workspace file - image is possible without some custom hacking of the python code by the user. (probably not too hard) me, I like xwd | xwdtopnm | pnmtopng screenshot.png Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
mitch wrote: How do I actually save a color composite image as a raster? I couldn't find r.composite :working:..too much work. GRASS cd $GISBASE/etc/gm/ GRASS less gmmenu.tcl /composite [Enter] up up up it's in Raster - Manage map colors - Create RGB there was a wish a while ago to build a menu tree for the commands, not sure if it went anywhere. Maybe something could be built into tools/module_synopsis.sh (add a line of text under each module descr with italicized a-b-c menu location?) [note to self: update the synopsis PDF for 6.4.0] The other question is something that has been getting me crazy for a couple of days: classifications. (GUI: Imagery → Classify Image → Clustering input for unsupervised classification) output Reading image ... Iteration 1: % Convergence: 80.00 (0s elapsed, 0s left) Iteration 2: % Convergence: 100.00 (0s elapsed, 0s left) (Pretty short output, innit?) perhaps the computational region is different than the map's? config - region - change region - set region to match this raster map ??? Moritz: There were issues in 6.3 with the GUI appending @MAPSET to names whereas the i.* commands couldn't deal with such names. This was corrected since (but probably after 6.3 came out). I would say mitigated not corrected. The imagery modules generally still don't like to look at maps in @othermapsets, and generally don't like @currentmapset tacked on map names either. But hopefully it breaks less now and exits with an understandable error message. The imagery libs need some TLC. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass 6.4.0 module list
Hi, the GRASS 6.4.0 module synopsis is now ready: http://grass.osgeo.org/gdp/grassmanuals/grass64_module_list.pdf It includes the names a short description of the 418 official modules which will be in the new release. (not counting alias wrappers) enjoy, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] to link two raster maps
FAROUX STEPHANIE wrote: Is it possible to link two raster maps in order to be able to get both pixels values by clicking on points with the mouse? d.mon x0 d.rast map1 d.rast -o map2 d.what.rast (won't work for MS Windows native builds) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] to define a region which is not rectangular
FAROUX STEPHANIE wrote: In my raster map sea pixels and missing data have the same null value. I'd like to separate the two but i don't have a sea/land mask. Missing data are concentrated in some areas. How can i do it? I thought to define regions in which missing data would be gathered but if i only use the zoom to do it, it will take a long time. Maybe using vectors? depending on how fine a coastline you need, you might try importing the GSHHS dataset with the v.in.gshhs module from the GRASS wiki addons page. convert lines to areas with v.type + v.centroids, then vector areas to raster MASK with v.to.rast. you can use r.mapcalc to invert the MASK to create both land and sea MASKs. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit
stephanie.faroux wrote: i do submit and i have the error: Cannot update table: DBMI-DBF driver error: SQL parser error in statement: update australia set where cat = 4 Error in db_execute_immediate() update australia set where cat = 4 is missing something between set and where. set what? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: improve v.rast.stats speed?
Giovanni wrote: Yesterday I needed to use v.rast.stats on a 1793 areas covering a 4415x6632 raster (with resolution 50m/pixel). I've used it without extended statistics but the processing time was, with an euphemism, very very long. I've tried to investigate what was going wrong, the bottleneck, but at the end I suppose that it's a problem of the script itself (the looping chain of r.mapcalc and r.univar, the creation and deletion of the MASK in each loop). right, it's very inefficient. FWIW, I had done something similar to v.rast.stats a while back. To speed it up I used g.region to zoom in on the area of interest so the r.mapcalc/r.univar step didn't have to run over the mostly NULL map*. It helped a lot. [*] IIUC if the entire row is NULL grass knows to skip the entire row quickly and not test each cell, which makes processing maps with lots of NULLs rather fast. You can look at g.region.point and v.what.rast.buffer in the wiki addons for some cleaned up version of my zoom-to-region-of-interest solution. I was mostly interesting in calculating statistics for 100m buffers around sampling sites, and extracting irregularly shaped vector blobs is not as easy (v.extract + g.region zoom=??), e.g. if you have two small vector blobs in opposite corners of the map with the same cat. In a C version you might have access to the feature's bounding box, which could be used to temporarily reset the region to speed up raster processing. (??) Markus Metz: 1) Use r.reclass instead of r.mapcalc to create new masks. That should speed up at least the MASK creation and deletion certainly worth a try, it is hugely less intensive for the MASK creation. Giovanni: Anyway as I can see Glynn has rewritten the same method (r.mapcalc and r.univar). I confirm that v.to.rast - (r.mapcalc to multiply/round FCEDD/DCELL to CELL) - r.statistics - (r.mapcalc to FCELL/DCELL again) - r.to.vect - join original vector to the output one is absolutely the faster way. are the results identical? Markus Metz: if v.rast.stats is faster in grass7, then probably because of improved raster libs. A speed increase from 5 hours to 40 seconds is unlikely since grass.mapcalc is still called 1793 times (assuming each area has a unique category) for a region with 4415x6632 cells... If sticking with the MASK + r.univar method, the moving window region- zoom/reset trick could help. Giovanni: The bottleneck is the r.univar limitation to CELL. ?did you mean r.statistics not r.univar? Markus Metz: r.univar2.zonal does zonal statistics pssst- svn copy not svn add. It works between -addons and trunk. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
[finding r.composite] mitch_TX wrote: it's in Raster - Manage map colors - Create RGB there was a wish a while ago to build a menu tree for the commands, not sure if it went anywhere. Maybe something could be built into tools/module_synopsis.sh (add a line of text under each module descr with italicized a-b-c menu location?) todo. hmmm... MODULE=r.composite xml2 gui/wxpython/xml/menudata.xml | grep -B5000 $MODULE | \ sed -e 's+^/menudata/menubar/menu/++' | tac | \ grep '/label=\|^label=' | grep -B1000 '^label=' -m 1 | ... ? may have to call in awk.. ..thanks, Moritz told me where to find it...my bad! if you know it's there but can't find it, what hope does a new user have of learning that it exists? It indicates a non-intuitive placement or where the label could be improved. This sort of feedback is rather valuable IMO. Hamish: I would say mitigated not corrected. The imagery modules generally still don't like to look at maps in @othermapsets, and generally don't like @currentmapset tacked on map names either. But hopefully it breaks less now and exits with an understandable error message. The imagery libs need some TLC. Are you saying that it's not a matter of version? no. it should be better in 6.4. Just that even with the new fixes the imagery modules (library) are still not as solid as the raster modules in this regard. Would I have the same problem with the 6.4? I don't know. Hopefully it is fixed, but it might not be. (feedback from users is really the only way to know) I'm sure it doesn't work when I copy the images in the user mapset... would that work working in PERMANENT? try with the imagery maps in the same mapset. perhaps with the maps in PERMANENT you don't need @mapset (it's in the search path), so it would be ok. shrug. I did try to include the images in the group using the graphic way but deleting (in the box) @mapset...no luck. you can look in the $MAPSET/groups/ files too, they are just plain text. But still, how about the Supervised? Wouldn't that work and tell me that THERE IS a sub-group since I used it (the one created via command) for the Usupervised? (I tried to create another group -- via command -- and run the i.class but when I have to define the subgroup...nothing!..it doesn't find it. I don't work with any of the classification stuff, so am not really familiar with them, but if you can recreate the problem(s) from the command line, using the North Carolina or Spearfish sample datasets, please post the commands to trigger it to the bug tracker and we can try and reproduce it at our end. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass startup problem
Jimmy wrote: Error: mapset is not set. have a look at Lorenzo's new user tutorial at http://grass.bologna.enea.it/tutorial/ Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map question concerning rtid numbers
Rainer wrote: I am using ps.map with a raster and a grid and showing numbers. This works fine, only that background of the numbers of the grid is white, and not transparent - consequently, one can not see the raster (see attached png). I am using the code below. My question is, if it would be possible to set the background of the numbers to transparent. generally no. but: perhaps with the new ps.map patch in the tracker by Jorge? (#487) or, you can edit the postscript file by hand. Open in vi (or some other industrial strength text editor), search for the coordinate text near the end of the file, maybe in (12345) parentheses. then ~3rd line after text change 1 1 1 C to another color (R G B, 0.0-1.0) or just remove that line?? I think I've tried it before and it didn't look very nice because the previously masked grid line continued through the text. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.generalize for area boundaries?
Eric: FWIW, I've cleaned up the existing v.generalize html page by rewriting parts where I thought the meaning could be explained better, as well as spelling corrections and other misc. formatting I'm not familiar at all with the functionality of the module, so examples will take a bit longer to work up. I've imported the tutorial into the wiki: http://grass.osgeo.org/wiki/V.generalize_tutorial a number of examples are given there. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
mitch wrote: GUI: I got stuck at the i.cluster window. How do I set the sampling interval values? I'm not allow to use any kind of character but numbers...how do I differentiate row and column value? http://n2.nabble.com/file/n2369388/sampling.png If I leave 1 value I get this error: ERROR: option sample must be provided in multiples of 2 You provided 1 items: 50 that's a bug, it should let you give two values. --help says: [sample=row_interval,col_interval] I've notice that i.group window has been changed: shouldn't “Name of imagery sub-group” and “Name of the raster map(s) to include in group” be under the Required tab rather than Optional? 'group=name' is the only required option. you can list maps in the group without adding any, so the subgroup and input raster maps are not needed sometimes. also subgroup really is optional. btw (for better or worse) those required/optional groupings happen automatically based on module requirements. I'm not really a fan of that but others think it's a useful feature. shrug (don't get me wrong, I don't want to criticize in a “bad” way, it's because maybe you receive a lot of feedbacks about other parts and this module is not so usedI haven't seen so many Remote Sensing questions lately...that's why). polite and researched feedback is always welcome! once you are comfortable that an issue is really a bug, please file a ticket, one for each issue. if just left in the mailing list it'll more easily be forgotten in the noise. -Supervised- I couldn't figure out how to make it work. ...but nothing more than that. Shouldn't I be prompted to a display where I can draw my region of interest? (I don't know, maybe I'm expecting something that it's not supposed to be). for sure old xmon based interactive monitors are gone for wxPy on Windows. not sure about what to expect from these modules, but supervised says to me some sort of map interaction is required... GUI: Imagery → Classify image → Interactive input for supervised classification (requires Xterm) it doesn't just need an terminal window for the text based menu data entry, in needs an Xmonitor as well, which is unavailable in the native MS Windows build. a blank Monitor display and a new shell appear and nothing else. we need a better sorry, won't work on MS Windows (so far) error message there. Are all of the GUI issues due to this http://grass.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#Imagery_tools (Status: development not started yet) perhaps better stated as redevelopment not started in earnest yet, Some behind-the-scenes code has been prepared, but not much. Volunteers welcome! Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem in projection of shape files
Zahid Parvez wrote: I have a shape file which I have to import in GRASS. Shape file is consists of a shape file, a dbf file and a prj file. The prj file has following information. I will be very grateful if anyone could help me to find the ESPG code and any other way to re-project the shape file and import into GRASS. on the grass (tcl/tk) start-up screen use the Define new location with ... [Georeferenced file] button, then to reproject run v.proj from the location you wish to reproject into. Knowing the EPSG code is not critical. You can also use the nice EPSG browse/search tool from the Define new location with ... [EPSG codes] window to track it down. (or search through the epsg file itself with your favorite text editor/viewer. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.info doesn't print out all category values
William Hudspeth wrote: I have used to r.average to calculate mean pixel values by county. This involved converting the county vector layer to a raster, then using the county raster layer as the base in r.average. So far so, good. The r.average routine does what I want, but the resultant output raster map shows the following output with r.info: [r.info? are you sure? what's the exact command line params you used for each command?] ... 207740:207740:0.4507908000 207741:207741:0.563316 207742:207742:0.5043974000 207743:207743:0.432117 ... There are 52 categories, but the r.info output only shows about 45 of them, leaving the rest unreported. If I redirect to file, the same thing. If I look at the cats file under the cats subdirectory, it also fails to show all of the categories. How do I show everything that is generated by r.average??? can you reproduce the problem using the Spearfish or North Carolina sample datasets? then we can try to reproduce the effect. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem with r.surf.idw
Alberto Pettazzi wrote: I want to interpolate a raster map that contains real values. I KNOW the values are real because I output the raster values with r.out.ascii command and the file shows real values. The problem is when I interpolate the raster with the r.surf.idw function and output the interpolated raster value, the file only contains integer (probably truncated) values. r.surf.idw and r.surf.idw2 only produce CELL (integer) maps. try using (r.to.vect +) v.surf.idw or v.surf.rst instead. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mapset cell size grouping
Is it logical to use mapsets for different raster modeling cell sizes? sure, use whatever works. you can use g.mapset (no s) to change mapsets on the fly, but it might help to change the path (PS1= enviro var) to include the mapset name instead of the location name in the prompt. that's set in etc/init.sh at startup, so maybe need to edit $GISBASE/etc/prompt.sh to have that change automatically when g.mapset changes? e.g. after each g.mapset change: eval `g.gisenv` export PS1='GRASS ($MAPSET):\W ' all-in-one: g.mapset user1 eval `g.gisenv` export PS1='GRASS ($MAPSET):\W ' probably add the shell history recommendations from g.mapset to that, and perhaps source it in a little . source.sh command. (you can make an alias to avoid the . file.sh each time) sumthin' like that... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem using i.cluster on GRASS GIS 6.4.0RC3
sindile.bidla wrote: I get the following error when using i.cluster: ERROR: Unable to create report file (null) This is how I wrote the commands i.group group=lsat1 subgroup=lsat1 in=L71171078_07820001007_B10,L71171078_07820001007_B20,L71171078_07820001007_B30,L71171078_07820001007_B40,L71171078_07820001007_B50,L72171078_07820001007_B70 i.cluster group=lsat1 subgroup=lsat1 sig=sig.cluster classes=15 sep=1.5 Windows XP - GRASS GIS 6.4.0RC3 I have seen the following tickets http://trac.osgeo.org/grass/ticket/174 and http://trac.osgeo.org/grass/ticket/70 which seem to suggest that the problem has been solved / there is a work around. nope, not fixed yet. i.cluster/main.c has: if ((reportfile = parm.report_file-answer) == NULL) report = fopen(/dev/null, w); there is no /dev/null on Windows, so it fails to open the file. work-around: specify reportfile=something.txt others that need fixing: raster/r.out.mpeg/main.c raster/r.topmodel/misc.c Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Calculating eigen values and % variance explained after PCA analysis
Nikos wrote: There is still m.eigensystem with which one can manually build Principal Components and get all values. But I am not sure how to compile it (anymore) works for me. cd grass-addons/misc/m.eigensystem make MODULE_TOPDIR=/usr/local/src/grass-svn/releasebranch_6_4 is f77 installed? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
Hamish: i.class map=spot.comp group=spotspear subgroup=spot.test outsig=test.txt hmmm, if I try the same from gis.m in grass65 I get: = [...] required: NO Enter the name of an existing input file Hit RETURN to cancel request [$GISBASE]/etc/grass-run.sh: line 29: 20596 Segmentation fault $@ ERROR: i.class exited abnormally. Press enter to continue. = and the xterm closes. Ok, it's a bug: the menu item wasn't opening an xmon for you, and wasn't disabling GRASS_RENDER_IMMEDIATE for i.class. For the Tcl/Tk GIS.m GUI now fixed in svn, rev 36103. cd gui/tcltk/ svn up make Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] categories in raster map
stephanie.faroux wrote: I see the function r.cats which allows to read categories of a raster map, but how can i define these attributes? r.cats has been replaced by r.category in grass 6.3+, the new version can both read and write attribute labels. Should i pass by a vector map? In the database menu, it doesn't seem possible to add a table for a raster map. actually v.to.rast's labelcol= option is slightly broken right now, see bug #175: http://trac.osgeo.org/grass/ticket/175 (work-around given in the bug report) it's not nearly as rich as vector attribute management (DB). see also http://grass.osgeo.org/wiki/Tips_for_Arc_users#Import_ArcASCII_raster_grid_and_connect_to_database Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] categories in raster map
Moritz wrote: I do see that the man page might not be particularly clear on its usage (the Description part only mentions printing, not managing labels fixed in svn. and the part on dynamic labels is a bit cryptic). as the result of a bit of cut paste reorder so things are used before they are introduced. If anyone is keen, feel free to improve that. I am note sure about the status of floating point ranges, the man page says: 5.5:5:9 label description but I'm not sure I understand that without looking in the code. (range or discrete values? range would be nice) I seem to remember that d.legend used to be able to show cat labels for floating point maps, but also seem to recall that wasn't working the last time I tried. Probably need to check to see if it works in grass5.4 and go from there. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] categories in raster map
But with r.reclass i achieved. Ok, you could also look at r.support for interactive editing of the labels. or just edit the $MAPSET/cats/ file directly. It's fairly simple, look for an example in the spearfish dataset files. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Long post - Remote Sensing - Classifications
Hamish: hmmm, if I try the same from gis.m in grass65 I get: = [...] required: NO Enter the name of an existing input file Hit RETURN to cancel request [$GISBASE]/etc/grass-run.sh: line 29: 20596 Segmentation fault $@ ERROR: i.class exited abnormally. Press enter to continue. = and the xterm closes. (fixed in svn) Yes, this is what I was talking about in one of my previous post while using the wxPython GUI I get this http://n2.nabble.com/file/n2390051/x0.png x0.png anything in the terminal window? or does that launch an xterm for you? but we already said that was under development. that's what we're doing now. :) Ok, it's a bug: the menu item wasn't opening an xmon for you, and wasn't disabling GRASS_RENDER_IMMEDIATE for i.class. For the Tcl/Tk GIS.m GUI now fixed in svn, rev 36103. cd gui/tcltk/ svn up make I'm sorry Hamish, could you be a bit more for dummies for me ? :-) I'm still not so familiar with this. Do I have to go in the tcltk directory and run svn up - make? Or do I have to download something somewhere. Again, I got the 6.4 version from Sid but now I switched back on Lenny... argh sorry forgot that. the instructions are cutpaste from the command line from the svn checkout source code dir. would that work the same? you could try to paste the files in, but it's a bit sloppy. Besides, are you suggesting to switch back to the tcltk GUI to make it work?..I kind of liked the wxPython one. well it should now work from the tcltk gui (latest unreleased svn), no idea from the wx GUI. (I still haven't updated from etch here so no official wx2.8 or gui for me except from winGrass or Mac packages) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass wiki on RST troubleshooting
Mark wrote: http://grass.osgeo.org/wiki/RST_Spline_Surfaces#Troubleshooting I'm not sure I understand where this is to make the change for MAXPOINTS? Moritz: This is in the source code and you have to recompile v.surf.rst. wiki updated. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass wiki on RST troubleshooting
Maris wrote: Sorry for interuption, but I could not find place where in v.surf.rst MAXPOINTS is used for anything else than printing a warning. URL to line in SVN? If I'm correct, no need to recompile anything. I think you are right for v.surf.rst. but v.vol.rst seems to use it. Markus: You see that MAXPOINTS is assigned to KMAX2 and then used. but that part of the source is commented out and the KMAX2 setting is the same on both sides of the if/else. Here at Trento, we are currently trying to see how to - either dynamically define MAXPOINTS/KMAX2 - or minimize the overhead while maximising MAXPOINTS. great! Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to make a conversion of ERSI Grid ASCII==USGS DEM?
Illidan wrote: I'm trying a conversion of from ERSI Grid ASCII(e00) to legacy USGS DEM that one old piece of software I'm using supports. I searched the web and only got results about the reverse conversion, i.e. USGS DEM== e00. So I ask for help here. I appreciate any feasible work flow or hint on an existing conversion software. $ gdalinfo --formats | grep USGS DOQ1 (ro): USGS DOQ (Old Style) DOQ2 (ro): USGS DOQ (New Style) ISIS3 (ro): USGS Astrogeology ISIS cube (Version 3) ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2) USGSDEM (rw): USGS Optional ASCII DEM (and CDED) (see gdal.org) hopefully you want USGSDEM? if so import to GRASS with v.in.e00 and do what you have to do to get into raster format before running r.out.gdal format=USGSDEM. what is the nature of the e00 file? contour lines? TIN? points? ascii-grid of some sort? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Calculating eigen values and % varianceexplainedafter PCA analysis
Nikos wrote: It should be the case with i.pca as well since eigen_VALUES_ (=represent the variances of the original dimensions that are kept in each component) are important for the interpretation of what exactly are each of the components. But, i.pca just does not report the eigen_VALUES_. At some point some C-expert needs to have a look in the code (i.pca) and correct the bug which does not let the eigen_VALUES_ from being printed. done in devbr6 (6.5svn) please test, I'm not a multivariate stats guru and may have done something dumb so didn't port to other branches yet. I changed the i.pca output to be like: Eigen (vectors) and values: PC1 ( -0.63 -0.65 -0.43 ) 88.07 PC2 ( 0.23 0.37 -0.90 ) 11.48 PC3 ( 0.75 -0.66 -0.08 ) 0.45 As it was previously sent to stderr via G_message() I don't feel bad about breaking output text compatibility. I wanted to add % to the values but due to the sprintf()+strcat() method in the code that was a pain, so I didn't. If this is the case then both methods still differ significantly. Is this possible, and which should I use. Please have a look at my comments/questions in link [2]. i.pca follows the SVD method. You performed the non-standartised PCA using the covariance matrix. Note that you can use also the standartised method by using the correlation matrix. does the r.mapcalc command at the end of the m.eigensystem help page* do that conversion, or ...? ie how can we test these against each other? how to do the standardized method? [*] (is \- there a typo or some old mapcalc syntax?) also ISTR somebody (Dylan?) doing a comparison with the R-stats interface. It would be nice to run tests using the Spearfish imagery dataset. After my own tests I noticed it matched what was used in the m.eigensystem help page. my results follow. Hamish #Spearfish imagery sample dataset g.region rast=spot.ms.1 # 'by-hand-method' G65 echo 3 test_m.eigensystem# number of input maps G65 r.covar map=spot.ms.1,spot.ms.2,spot.ms.3 test_m.eigensystem G65 cat test_m.eigensystem 3 462.876649 480.411218 281.758307 480.411218 513.015646 278.914813 281.758307 278.914813 336.326645 G65 m.eigensystem test_m.eigensystem - C The output is N sets of values. One E line and N V W lines C C E real imaginary percent-importance C V real imaginary C N real imaginary C W real imaginary C ... C C where E is the eigen value (and it relative importance) C and V are the eigenvector for this eigenvalue. C N are the normalized eigenvector for this eigenvalue. C W are the N vector multiplied by the square root of the C magnitude of the eigen value (E). - E 1159.7452017844 0.0088.38 V 0.6910021591 0.00 V 0.7205280412 0.00 V 0.4805108400 0.00 N 0.6236808478 0.00 N 0.6503301526 0.00 N 0.4336967751 0.00 W21.2394712045 0.00 W22.1470141296 0.00 W14.7695575384 0.00 E 5.9705414972 0.00 0.45 V 0.7119385973 0.00 V-0.6358200627 0.00 V-0.0703936743 0.00 N 0.7438340890 0.00 N-0.6643053754 0.00 N-0.0735473745 0.00 W 1.8175356507 0.00 W-1.6232096923 0.00 W-0.1797107407 0.00 E 146.5031967184 0.0011.16 V 0.2265837636 0.00 V 0.3474697082 0.00 V-0.8468727535 0.00 N 0.2402770238 0.00 N 0.3684685345 0.00 N-0.8980522763 0.00 W 2.9082771721 0.00 W 4.4598880523 0.00 W -10.8698904856 0.00 # 'all-in-one method' using r.covar+m.eigensystem: G65 (echo 3; r.covar spot.ms.1,spot.ms.2,spot.ms.3 ) | m.eigensystem Then, using the W vector, new maps are created: r.mapcalc 'pc.1 = 21.2395*map.1 + 22.1470*map.2 + 14.7696*map.3' r.mapcalc 'pc.2 = 2.9083*map.1 + 4.4599*map.2 - 10.8699*map.3' r.mapcalc 'pc.3 = 1.8175*map.1 - 1.6232*map.2 \- 0.1797*map.3' (is \- above a typo or some old mapcalc syntax?) which look highly similar (but not identical) to i.pca output maps. (after 'r.colors color=grey') # 'automatic method' imagery60:G6.5svn i.pca in=spot.ms.1,spot.ms.2,spot.ms.3 out=spot_pca Eigen (vectors) and values: PC1 ( -0.63 -0.65 -0.43 ) 88.07 PC2 ( 0.23 0.37 -0.90 ) 11.48 PC3 ( 0.75 -0.66 -0.08 ) 0.45 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Calculating eigen values and % varianceexplainedafter PCA analysis
Hamish wrote: # 'automatic method' imagery60:G6.5svn i.pca in=spot.ms.1,spot.ms.2,spot.ms.3 out=spot_pca Eigen (vectors) and values: PC1 ( -0.63 -0.65 -0.43 ) 88.07 PC2 ( 0.23 0.37 -0.90 ) 11.48 PC3 ( 0.75 -0.66 -0.08 ) 0.45 changed to: Eigen values, (vectors), and [percent importance]: Eigenvalue 1: 1170.12 ( -0.63 -0.65 -0.43 ) [88.07%] Eigenvalue 2: 152.49 ( 0.23 0.37 -0.90 ) [11.48%] Eigenvalue 3: 6.01 ( 0.75 -0.66 -0.08 ) [0.45%] comments welcome. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Calculating eigen values and % varianceexplainedafter PCA analysis
Nikos: * Present first the variance (=eigenvalues) because it's the first thing you will look at to know how much variance of the original data is _expressed_ in each new component. * The importance, since it refers to the eigenvalue, it's better to come right after it. to me it picks your eye more quickly if it is not buried in the middle. shrug. the important thing is that the numbers are correct not confusing. * Present the loadings (eigenvectors) for each new component. we are doing that already, right? * Column-wise or row-wise? The results can be either presented column-wise, that is one column for each new component _or_ row-wise, as they are currently printed. I think row-wise just looks better :-) maybe, but row-wise is slightly easier to code. Some examples... (only 2 for column-wise and all the rest row-wise... playing around). fancy tables are hard for the module output because it uses G_message() and G_message() condenses any whitespace (multiple spaces, tabs,..) to a single space. thus formatting is lost. and i.pca's main output is maps, not eigen data so I guess it makes sense to keep that text optional instead of sending to stdout. Perhaps a New flag to print summary report to stdout? (mmph, just cutpaste from history) for map history it's a bit better, but I can't end with a %. now 'r.info -h' output looks like: Eigen values, (vectors), and [percent importance]: PC1 1170.12 ( -0.63 -0.65 -0.43 ) [ 88.07% ] PC2152.49 ( 0.23 0.37 -0.90 ) [ 11.48% ] PC3 6.01 ( 0.75 -0.66 -0.08 ) [ 0.45% ] module output is same but not as pretty due to G_message() issue. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] output tables
Matthew Mulbrandon wrote: I just want to output all my data in file tenn_county_all into a comma delimited file with all variables. I have done v.out.ascii format=standard it works but I only get x,y coord and the ID but I need all variables. -84.28851567|35.99395611|1 -84.25999586|36.01053534|2 -84.25146063|35.95974559|3 -84.24508926|36.01258551|4 -84.20325976|36.00941242|5 try v.out.ascii.db from wiki addons or v.out.ascii's new column= option in GRASS 6.4. also v.db.select or db.select might help. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to make a conversion of ERSI Grid ASCII==USGS DEM?
Illidan wrote:
By now I'm successful with importing the ESRI ASC by r.in.arc
r.in.arc input=srtm_60_04.asc output=beijing
CREATING SUPPORT FILES FOR beijing
However, when I try
r.out.gdal input=beijing output=beijing.dem format=USGSDEM
it replies with Error: value USGSDEM out of
range for parameter format
Legal range:
AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,
NITF,PAux,PNG,PNM,VRT,XPM
''
In fact when I run it with -l option as
r.out.gdal input=beijing
output=beijing.dem -l'', it responses with a
listing including
'USGSDEM' that looks like:
FIT: FIT Image
RMF: Raster Matrix Format
RST: Idrisi Raster A.1
INGR: Intergraph Raster
GSAG: Golden Software ASCII Grid (.grd)
GSBG: Golden Software Binary Grid (.grd)
USGSDEM: USGS Optional ASCII DEM (and CDED)
ADRG: ARC Digitized Raster Graphics
So I'm confused whether USGSDEM is valid or not.
mmph. problem with r.out.gdal. there is a switch somewhere called
__ALLOW_DYNAMIC_OPTIONS__. For me it is true and my format= list of
supported format is the full one. If that wasn't set when the program
was compiled it just falls back on a short list someone put in there
some time ago.
The '-l' flag talks to gdal unconditionally so you always get the full
list.
with new versions of GDAL, more and more formats are supported but
r.in.gdal's fail-over format= list hasn't been updated.
for me using modern gdal 1.5.2 from DebianGIS I get a lot more formats
than the fail-over list:
$ gdalinfo --formats | grep '\(rw\)' |cut -f1 -d'(' | sed -e '1d' | \
awk '{print $1}' | sort -f | tr '\n' ','
AAIGrid,ADRG,BMP,BT,DTED,EHdr,ELAS,ENVI,ERS,FIT,GIF,GMT,GSAG,GSBG,
GTiff,HDF4Image,HFA,IDA,ILWIS,INGR,JPEG,JPEG2000,Leveller,MEM,MFF,
MFF2,netCDF,NITF,PAux,PCIDSK,PCRaster,PNG,PNM,RMF,RST,SRTMHGT,
Terragen,USGSDEM,XPM
So: if you have the source code just //comment out the
format-options = gdal_formats;
line in main.c and rebuild. if you are working from an installer package
you will have to bug the person who made the package to enable the
__ALLOW_DYNAMIC_OPTIONS__ switch or use gdal_translate (see below).
dev: probably if dynamic options is not set it should be left blank
instead of using a hard-coded list which will always out of date or
refer to someone else's gdal.
Another option as this is raster-raster is to bypass GRASS altogether
and use the gdal_translate utility program to convert directly from Arc
ASCII GRID to USGSDEM.
something like:
gdal_translate -of USGSDEM map_arc.grid map_usgs.dem
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to make a conversion of ERSI Grid ASCII==USGS DEM?
Illidan wrote: I wonder if my data is not valid, does it look ok in grass after import with r.in.arc? After an r.in.arc, I'm able to open it in GRASS. However, when I add a raster layer for it and perform Display active layers in Map Display 1, Map Display 1 is just blank. When I place the mouse over Map Display 1, it displays a kind of (X, Y) on mini status bar on the the left bottom of the window. When I try to view its profile by create profile of raster map, it returns 0 after I draw a transect.If I query a point, it replies with sth. like 638510.228216|220781.556017||*. I'm only successful with a measure that returns a valid distance. So I guess it's just invalid. hmmm, everything seems to work in GRASS here. you need to set type=CELL with r.in.arc. 1) download and unzip .arc file from srtm.csi.cgiar.org 2) start grass in a lat/lon wgs84 location 3) r.in.arc in=/tmp/srtm_23_16.asc type=CELL out=srtm_23_16 4) r.colors srtm_23_16 color=srtm 5) g.region rast=srtm_23_16 6) d.mon x0; d.rast srtm_23_16 gdal_translate -of USGSDEM srtm_23_16.asc srtm_23_16.dem worked ok as well. ?, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.rast Converted points/lines: 0 of 47763
achim wrote: today another question. My problem: I converted boundaries from an area vmap to lines via v.type v.type input=git...@achim output=gitter_lines type=boundary,line --o Now I want to convert these lines to raster-cells via: v.to.rast --overwrite input=gitter_li...@achim output=gitter_lines use=cat type=line but nothing converts! Loading data... Pass 1 of 2: Reading features... Schreibe Rasterkarte... Pass 2 of 2: Schreibe Rasterkarte... Converted areas: 0 of 0 Converted points/lines: 0 of 47763 v.to.rast komplett. What am I doing wrong? boundaries typically do not have a category value (e.g. a boundary between two fields: which farmer owns the boundary?), but sometimes can (e.g. if boundary is also a road) only items with category are processed by most vector modules (they loop from the first cat to the last cat). So run v.category to add cats to your lines and then it should work. there is a (short) word about this in the vectorintro help file. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Testing i.pca ~ prcomp(), m.eigensystem ~ princomp()
Nikos: Finally all is clear _but_ one thing: the only unknown variable (to me) is still the Eigenvalue provided by i.pca. I can't nail this one: *** how is it calculated? *** Looks like it is some _weighted_ variance... !?? Hamish, if you have the time (or anyone , could you please translate the code in grass6_dev/imagery/i.pca/main.c, concerning the eigval variable, in some pseudocode. It is really the last thing to clarify ( I think ). I don't really have the time, I am just about to leave the office for a few weeks. but quickly: for i.pca they are calculated by the eigen() function in lib/gmath/eigen.c see also lib/gmath/eigen_tools.c unfortunately the programmer decided to use all one letter variables there and no comments.. but maybe the math is clear enough to tell which method is used. it will be really good to finally have all this documented. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.composite problem
Moritz wrote: Use r.region rast=OneBandOfYourMap before running r.composite. (typo: g.region not r.region) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some question about r.in.xyz and r.surf.idw
Alberto wrote: I had the same problem. As Hamish told me some weeks ago, r.surf.idw and r.surf.idw2 only produce CELL (integer) maps. I solved my problem multiplying the input raster by 100 (r_bio in your case), then I interpolated with r.surf.idw and finally divided once again by 100. [depending on your needs] r.to.vect + v.surf.rst or r.surf.nnbathy (from wiki addons) will create a /much/ nicer surface than IDW methods. this explains why r.surf.idw module development is rather neglected. see also R-stats/grass interface kriging tools and v.surf.idw. I am not sure if v.surf.idw handles floating-point data or just integers, but as a total guess I'd say it would create FP output due to the vector modules generally being more recently written. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] delete, drop rows in table
Stefanie Obmann wrote: I want to exclude all NULL values (999.99) from my temperature column to do the v.surf.idw command. I don’t know where to set a WHERE clause that the calculation just takes the real values (except 999.99). try using v.extract to do the WHERE clause first. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-stats] Re: [GRASS-user] Testing i.pca ~ prcomp(), m.eigensystem ~ princomp()
Nikos: http://grass.osgeo.org/wiki/Principal_Component_Analysis Roger: Good, thanks. There you say that you are using some MODIS surface reflectance products. I guess it will be easier to check things if the data (GRASS location) are available, so that others can try the same calculations. Would it be possible to make one or more test sets available, and link them from thw Wiki? better yet, use the standard Spearfish SPOT imagery sample dataset for the examples. (as m.eigensystem and now i.pca help page examples do, probably others) is there a way to change text color in MediaWiki? it might be easier to highlight m.eigensystem output rows by color instead of '#'s. idea for possible google summer of code 2009 project: overhaul i.* modules/lib for grass7. US$4.5k bounty :) cheers, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Modelling 1:n and m:n relationships in GIS
Moritz Lennert wrote: I don't have a copy of grass64 on my machine at the moment. Could someone merge this into 64 for me ? fyi in SVN you can not checkout a single file from the repo to update (like you can in CVS), but you can check out a single directory non-recursively then edit the file. see the trac wiki page about SVN downloads. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Better looking resampling from i.rectify
Martin Ceperley wrote: It appears that nearest neighbor is the only resampling method in i.rectify, are there any methods or tricks for getting better looking results rectifying bitmaps? Or other programs or tools that do this? yeah, check out i.warp from grass's wiki addons, which is a front- end to gdalwarp which will let you chose the method, and is faster too. the i.warp script embeds GCPs from GRASS's POINTS file into a geotiff metadata with gdal_translate then does the work with gdalwarp. (IIRC) see gdalwarp help page at www.gdal.org nearest-neighbor is required if input map was paletted instead of RGB. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] new user
Ricardo wrote: i need to change the no data to 5 on the other values can remain the same. use the r.null module. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] (not) getting started
Wim de Vries wrote: (v.5 on suse 10.3 as well as v.6.2 on debian lenny). I came to the point of defining a new location, but then the list for projections does not show Lambert conformal or mercator. it's there. lcc, merc, etc. Next, I cannot get out of the list. Had to hit CTRL-C to completely drop out of the app. q this is something which to me is rather annoying in the debian package. they/we change the default pager (press any key for next page) to be the 'less' program instead of grass's default which is 'more'. the result is that you have to be used to it and know to press 'q' to get out of the list. with 'more' all you have to do is bash the spacebar and enter enough times and you get out automatically. sorry for the inconvenience. you can change it back to 'more' or whatever by setting the GRASS_PAGER variable, see the grass variables help page. for lenny you should get the latest grass, gdal, and proj packages from debian's www.backports.org. then you can have a pretty recent version to play with without much more than an apt-get call. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.colors- transparent, HSB color
Glynn: OTOH, you can obtain this functionality by pre-processing the rules with a script. see the r.cpt2grass addon script in the grass wiki (for converting GMT color tables to grass's r.colors format) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.tif
apachemaven wrote: start the grass, and enter r.in.tif in the output window, then clidk run gui, then I get the message can not to run commond r.in.tif why? try r.in.tiff (two 'f's) or r.in.gdal Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-stats] Re: [GRASS-user] Testing i.pca ~ prcomp(), m.eigensystem ~ princomp()
Markus Neteler wrote:
Remember that you have to rescale these data first:
https://lpdaac.usgs.gov/lpdaac/products/modis_products_table
- MOD09Q1 Terra
Surface Reflectance Bands 1–2
Tile 250m
8 Day
https://lpdaac.usgs.gov/lpdaac/products/modis_products_table/surface_reflectance/8_day_l3_global_250m/v5/terra
- layers
... MULTIPLY BY SCALE FACTOR ...
Nikos wrote:
Yep, I know that. But why is it wrong to just use them as they are?
FWIW, the MODIS/Aqua Chlorophyll-a product requires more than simple
linear rescaling:
r.mapcalc ${map}.chlor_A = 10^(($Slope * $map) + $Intercept)
http://grass.osgeo.org/wiki/MODIS#Processing_2
so you may need to take care if working directly with raw 0-65535 data.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Map Collars
Hi, some time ago, Chris wrote: The first issue to tackle is to remove the collars of the NOAA charts. I've searched the archives and there are only two dated posts and both recommend shapefiles. Well there are no shapefiles for the Atlantic or other water bodies so this method cannot work. I'm not sure how that's supposed to work, but FWIW you might try the NOAA coastline extractor or the v.in.gshhs addon module to get the Atlantic coastline as a vector map. If anyone has any suggestions or ideas it would be greatly appreciated on how to remove map collars of NOAA charts. the attached script is probably very far from the fastest way to do it, but it works on the test map I tried (NOAA #12200). maybe the salmon color needs to be a bit more fuzzy to cover different maps? probably some maps have more than single pixel specks to be removed, so r.neighbors window size could be upped. the idea: 1) download RNC maps from NOAA's website 2) Convert BSB format to GeoTIFF with gdalwarp 3) Import GeoTiff into GRASS 4) remove any single pixel specks from the map 5) temporarily mask out white, black, salmon colored metacontent which occurs in the collars 6) zoom to the extent of the color-masked map 7) save a copy of the original chart using the smaller bounds to GeoTIFF 8) ... tile GeoTIFF as needed for MapServer/WMS or GpsDrive application 9) go sailing Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Map Collars (missing attachment)
some time ago, Chris wrote: The first issue to tackle is to remove the collars of the NOAA charts. I've searched the archives and there are only two dated posts and both recommend shapefiles. Well there are no shapefiles for the Atlantic or other water bodies so this method cannot work. Hamish: I'm not sure how that's supposed to work, but FWIW you might try the NOAA coastline extractor or the v.in.gshhs addon module to get the Atlantic coastline as a vector map. If anyone has any suggestions or ideas it would be greatly appreciated on how to remove map collars of NOAA charts. the attached script is probably very far from the fastest way to do it, but it works on the test map I tried (NOAA #12200). maybe the salmon color needs to be a bit more fuzzy to cover different maps? probably some maps have more than single pixel specks to be removed, so r.neighbors window size could be upped. (or make the resolution 2x as coarse, which would speed up processing as well, at the cost of the edge pixels) the idea: 1) download RNC maps from NOAA's website 2) Convert BSB format to GeoTIFF with gdalwarp 3) Import GeoTiff into GRASS 4) remove any single pixel specks from the map 5) temporarily mask out white, black, salmon colored metacontent which occurs in the collars 6) zoom to the extent of the color-masked map 7) save a copy of the original chart using the smaller bounds to GeoTIFF 8) ... tile GeoTIFF as needed for MapServer/WMS or GpsDrive application 9) go sailing -Inline Attachment Follows- hmmm, the shell script attachment seems to have been removed at some point. Did the listserv settings change? Chris, did you get it via the cc? cutpasted: (hopefully yahoo's completely fubar'd mail servers of late do not randomly line wrap it too badly) decollar_noaa_charts.sh --- r.in.gdal in=./BSB_ROOT/12200/12200_1_merc.tif out=noaa_12200 MAP=noaa_12200 g.region rast=$MAP # check that we are dealing with a paletted map eval `r.info -t $MAP` if [ $datatype != CELL ] ; then echo ERROR: only categorical maps can be processed fi # find cats in map CATS=`r.category $MAP` # find black and white category numbers unset BLACK WHITE SALMON for CAT in $CATS ; do RULE=`r.what.color in=$MAP value=$CAT` echo $RULE COLOR=`echo $RULE | cut -f2 -d' '` if [ $COLOR = 0:0:0 ] ; then BLACK=$CAT elif [ $COLOR = 255:255:255 ] ; then WHITE=$CAT elif [ $COLOR = 219:73:150 ] ; then SALMON=$CAT fi done echo black is $BLACK, white is $WHITE, salmon is $SALMON REMAINING=`echo $CATS | tr ' ' '\n' | grep -vw $BLACK\|$WHITE\|$SALMON` setup temporary file TMP=`g.tempfile pid=$$` if [ $? -ne 0 ] || [ -z $TMP ] ; then g.message -e Unable to create temporary files #exit 1 fi echo $BLACK = NULL $TMP echo $WHITE = NULL $TMP echo $SALMON = NULL $TMP for CAT in $REMAINING ; do echo $CAT = $CAT $TMP done # remove stray single dots r.neighbors in=$MAP out=$MAP.despeckle method=mode # make a reclass map, setting black and white to NULL r.reclass in=$MAP.despeckle out=$MAP.filtered rules=$TMP g.region zoom=$MAP.filtered r.mapcalc $MAP.cropped = $MAP r.mapcalc $MAP.cropped = $MAP.filtered ## debug method for finding residuals #r.mapcalc $MAP.cover = 1 #g.region rast=$MAP #r.mapcalc $MAP.residual = if($MAP.cover == 1, null(), $MAP) #r.stats -c $MAP.residual ## single 6,8 dot #d.zoom to collar which should be empty #r.univar $MAP #r.out.xyz $MAP #echo symbol basic/star 20 -72.35262972 38.8881031 black blue | d.graph -m #echo symbol basic/star 20 -74.51749113 39.27423606 black aqua | d.graph -m r.out.gdal in=$MAP out=$MAP_decollared.tif type=Byte #... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] concurrent versions of grass
[/usr/bin/gem6] (does it need to be in the main PATH at all? even if it is meanto to be used outside of a grass session) Markus wrote: If the others agree I'll start to add the second version number starting with GRASS 6.5. sounds good. Then behaviour doesn't change for 6.4. rename to gem[MAJOR][MINOR] with a symlink back to gem6? is backwards compatibility needed here? if new is gem64 it will not collide with earlier versions. ? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] meaning of r.param.scale features colours?
I cannot find the meaning of the colours (values) produced by r.param.scale features; G r.category elev.features 0 1 Planar 2 Pit 3 Channel 4 Pass (saddle) 5 Ridge 6 Peak and G d.legend elev.features Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Off Topic: Importing GRASS tiffs to GMT
Eric wrote: I'll post here before checking on the GMT list; hopefully I can get some answers from a GRASS/GMT guru... Moritz wrote: I can't help you on your precise questions, but have you seen Dylan's article: http://casoilresource.lawr.ucdavis.edu/drupal/node/561 (see link to pdf on that page) ? and of course the GRASS Wiki: http://grass.osgeo.org/wiki/GMT (which of course forever needs updating) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Off Topic: Importing GRASS tiffs to GMT
John Stevenson wrote: I've also used r.his to make coloured shaded relief maps, and plotted them in GMT using the same method. I don't think that it is the optimal method, but at least it preserved my colour rules. you might try 'd.out.file format=geotiff' for that Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Off Topic: Importing GRASS tiffs to GMT
Eric: I found a posting by Allen Cogbill on the GMT mailing list last night, and with a lot of clunky tweaking, worked for me: 1. Convert the .tif file to a Sun Rasterfile (I use ImageMagick). [ 2. Use Unix tools to read the .tfw file that accompanies the .tif file and calculate the real-world coordinate extrema. 3. Using g.region or imagemagick's identify, list the number of rows and columns, and along with the image resolution, calculate the N-S-E-W extents. 4. Once real-world extents are known, ] gdalinfo will do all that for you from the geotiff, or from g.region at time of export. beware the dreaded cell-center vs grid-center convention issues. use your psbasemap mapping scale to calculate image width and height on paper. 5. Pass this information to psimage -W. As long as the region defined in psbasemap's -R flag is identical to the region of the generated tiff from GRASS, the image will plot correctly. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] exporting areas to shapefiles without filling holes
Hi, I've got a grass vector map containing some areas with holes. It's a polygon of a river containing some islands; it looks nice in grass, centroids with cat in the wet parts, no centroids in the islands. There is no DB table. after exporting with 'v.out.ogr type=area' to a shapefile, when I load the shp file into QGIS 0.8.1 I see that all the holes have been filled in. The boundaries are still intact. using qgis's editing tools I can cut them out, but it takes a bit of manual labour to fix them all. what am I doing wrong? thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help with i.pca output
Markus: It is available from GRASS Addons SVN: http://grass.osgeo.org/wiki/GRASS_AddOns#m.eigensystem Since it is increasingly used, maybe we need to add it to 6.5/7? note that it requires a fortran complier. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Moving GISBASE box2box
Moritz wrote: Are you sure that the gis-database is correclty defined ? Have you tried accessing the mapsets directly on the command line without going through the GUI ? ls -l /media/removable_usbdrive/ is the user ID running grass the same as the one who owns the mapset? they must match. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [SOLVED] was Moving GISBASE box2box
Cassiel wrote: Moving from the old machine on the removable drive and from the latter to the newer machine changed the case of the VAR and WIND file inside the location dirs. What sounds very strange to me is why only those two files plus a MYNAME one... Moritz: Did you have other upper-case names which remained upper-case ? Maybe an issue with a fat filesystem on the removable drive ? Cassiel: Yes, DEFAULT_WIND, PROJ_INFO, PROJ_UNITS remained upper case while (I checked the rest of locations) all wind and var files were converted to lower case. The removable drive is fat32 and file permissions are all 755 on the older linux box... the above 3 don't fit into DOS's 8.3 filename restriction, so all get stored as PROJ_I~1 etc. with the real name stored elsewhere. VAR and WIND are less then 8 letters so just get stored as normal DOS names, which are case insensitive. If you look in the man page for 'mount' I think you will find a few options (-o ...) for choosing how to deal with uppercase letters while visiting fat-land. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [SOLVED] was Moving GISBASE box2box
Hamish wrote: If you look in the man page for 'mount' I think you will find a few options (-o ...) for choosing how to deal with uppercase letters while visiting fat-land. specifically search for shortname= Raffaele: Ok, I would have never guess that, as you can see there are no names containing ~ char looking the output below. it's internal these days, unless you're unlucky to still work in DOS. I wonder if some mkfs.vfat option can override this behaviour, clearly I remember that during the last year I did backup regularly from work to home without having troubles. yes, as above, see the man page for mount. put the options in your /etc/fstab file to make it automatic. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] latest i.pca does not compile?
Nikos wrote: n...@vertical:/geo/osgeo/src/grass6_devel/imagery/i.pca$ make gcc -I/geo/osgeo/src/grass6_devel/dist.x86_64-unknown-linux-gnu/include -g -Wall -DPACKAGE=\grassmods\ -I/geo/osgeo/src/grass6_devel/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/support.o -c support.c support.c: In function ‘write_history’: support.c:62: error: expected expression before ‘’ token support.c:65: error: expected expression before ‘==’ token support.c:68: error: expected expression before ‘’ token support.c:71: warning: format not a string literal and no format arguments make: *** [OBJ.x86_64-unknown-linux-gnu/support.o] Error 1 that is most likely a result of a svn merge conflict. (look for lines starting with C during svn up) if you look in the code you'll see like: .mine abc === abd .r12345 fix those in the code then do svn resolved filename.c Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] exporting areas to shapefiles without filling holes
Markus wrote: So please consider following patch: svn diff vector/v.out.ogr Index: vector/v.out.ogr/main.c === --- vector/v.out.ogr/main.c (revision 36267) +++ vector/v.out.ogr/main.c (working copy) @@ -214,6 +214,9 @@ Vect_set_open_level(2); Vect_open_old(In, in_opt-answer, mapset); + if (Vect_get_num_islands(In) 0 !cat_flag-answer) + G_warning(_(The map contains islands. To preserve them in the output map, use the -c flag)); + /* fetch PROJ info */ G_get_default_window(cellhd); if (cellhd.proj == PROJECTION_XY) v.out.ogr italy_country dsn=italy.shp type=area WARNING: The map contains islands. To preserve them, use the -c flag Exporting 26 areas (may take some time)... 100% 31 features written WARNING: 5 features without category were written Makes sense? perhaps use G_message() so that the user can turn if off if the message is annoying in a loop? the default does the unexpected, so some form of message is useful there. and I support to reverse the flag in grass7 (and no message) iff this doesn't have side effects for other OGR formats that we haven't considered while only thinking about shapefiles. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] netCDF import via r.in.gdal
Luigi wrote: I don't seem to be able to import netCDF via r.in.gdal in grass-6.4.0RC3 osgeo4w version running on XP sp3. GRASS 6.4.0RC3 (UTM32):C:\ r.in.gdal input=SRF_1958.AVG.NC output=SRF_1958.AVG location=ERA40_SRF Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Location ERA40_SRF created ERROR: Selected band (1) does not exist Is this something that I should be able to manage to do? yes GRASS complains about bands -- the file includes georeferenced daily climate variables. The file opens OK in viewers such as Panoply http://www.giss.nasa.gov/tools/panoply/. what does the output of gdalinfo look like? you might try to use gdal_translate extract a single band from the file and convert it into a GeoTiff. Then import the geotiff into grass. But anything gdal_translate can read r.in.gdal should be able to read too (with the right options). see http://grass.osgeo.org/wiki/MODIS#SST_.28Level_3.29 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mapset access - grass-6.4.0RC4
Luís wrote: [Errno 2] No such file or directory: '/media/WORKSPACE_2/Workspace/L7ETM204033/\n20090225_GAP' /media/WORKSPACE_2/Workspace/L7ETM204033/\n20090225_GAP is a wrong path. Location: L7ETM204033 Mapset: 20090225_GAP an extra newline character (\n) snuck in there somehow. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] m.eigensystem segfaults under Jaunty (beta)
Nikos Alexandris wrote: m.eigensystem, compiled against latest grass6_dev _AND_ grass -6.4.0RC4 source code, segfaults under Ubuntu-J 64-bit Beta. It works fine with Ubuntu Intrepid! So, something in Jaunty doesn't like m.eigensystem (fortran code?)! any chance of debugging? (gdb, etc) how far does it get? (if no idea you might try to cut and paste in some print strings from elsewhere in the code with little made it to line 110) comments then recompile. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] netCDF import via r.in.gdal
Luigi wrote: GRASS complains about bands -- the file includes georeferenced daily climate variables. The file opens OK in viewers such as Panoply http://www.giss.nasa.gov/tools/panoply/. Hamish: what does the output of gdalinfo look like? This is what gdalinfo says: C:\Documents and Settings\Luigi\Desktopgdalinfo C:\giotto\giotto_data\SRF_195 AVG.NC Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Driver: netCDF/Network Common Data Format Files: C:\giotto\giotto_data\SRF_1958.AVG.NC Size is 512, 512 Coordinate System is `' ^^^ not georeferenced (in a way gdal knows about), but Metadata: NC_GLOBAL#domxmin=-1.262909e+001 NC_GLOBAL#domxmax=4.295537e+001 NC_GLOBAL#domymin=2.129965e+001 NC_GLOBAL#domymax=6.144880e+001 NC_GLOBAL#domzmin=1.05e+003 NC_GLOBAL#domzmax=1.05e+003 do those make sense as lat/lon bounds? (12.63W, 42.96E; 21.29N, 61.44N) Subdatasets: SUBDATASET_1_NAME=NETCDF:C:\giotto\giotto_data\SRF_1958.AVG.NC:lon SUBDATASET_1_DESC=[148x158] lon (32-bit floating-point) SUBDATASET_2_NAME=NETCDF:C:\giotto\giotto_data\SRF_1958.AVG.NC:lat SUBDATASET_2_DESC=[148x158] lat (32-bit floating-point) here in the first two subdatasets you have lat and lon maps. import them, then use the values in them to set grass map bounds with r.region, instead of the starting 0,512 x 0x512 pixel coords. if you are good at shell scripting you could automate the import of all the bands and post the script to the NetCDF wiki page for others who find similar data files.. :) SUBDATASET_3_NAME=NETCDF:C:\giotto\giotto_data\SRF_1958.AVG.NC:ua SUBDATASET_4_NAME=NETCDF:C:\giotto\giotto_data\SRF_1958.AVG.NC:va SUBDATASET_5_NAME=NETCDF:C:\giotto\giotto_data\SRF_1958.AVG.NC:drag I assume these move into the actual data (wind velocities?) Hamish: you might try to use gdal_translate extract a single band from the file and convert it into a GeoTiff. Then import the geotiff into grass. But anything gdal_translate can read r.in.gdal should be able to read too (with the right options). Luigi: Found out that it is a multi-dataset file: Got info on subdatasets following directions at http://www.gdal.org/frmt_netcdf.html There is one subdataset per climate variable. Each subdataset has one band per day (365 bands). So I translated to geotiff as you suggested. C:\giotto\giotto_datagdal_translate -of GTiff -b 1 NETCDF:SRF_1958.AVG.NC:tamax SRF_1958.AVG.tiff I then tried to import in grass the geotiff. It imports and display fine when creating a new location, but no projection info is carried along so no way to use it with other layers/locations in my grass dataset. good to see the data makes it in. so the process would look like: 0. gdalinfo to find band names 1. r.in.gdal with magic netcdf input string with filename and data name (or gdal_translate to geotiff + r.in.gdal) 2. examine lat and lon subdatasets; instead of importing perhaps try to use 'gdalinfo -stats' to read max/min of lat,lon layers. 3. apply georeferencing info with r.region or gdal_translate for geotiffs using the -a_srs and -a_ullr options. (by the way r.in.gdal in wxpython gui does not work grass6.4.0-rc3: I used the tcltk gui). (look/file in the bug tracker please) Imports fine but still unable to get projection info, so the data is useless. If Panoply http://www.giss.nasa.gov/tools/panoply/ is able to plot the data on a global coastline, the proj info should be somewhere in the netCDF file: is there a special name for this flavour of netcdf file? ie is it standardized way of geocoding them or some single nasa in-house method not seen anywhere else? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] traveling salesman problem in air
Martina Schäfer wrote: Interesting discussion!! I've created the centroids but unfortunately, the visibility network module repeatedly crashed (I am using GRASS 6.4 on Mac OS, but tried on Windows XP as well) with the message out of memory. I am new to GRASS, any advice how to deal with that? http://grass.osgeo.org/wiki/Bugs Moritz wrote: And for the possible need to check possibilities of reduction of memory usage in v.net.visibility. It shouldn't run out of memory, maybe it is some run away loop or incorrect malloc call? if this were raster maps I'd ask how big the region settings were. how much system RAM? how many centroids are we talking about? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Rotate a map display
Vincent wrote: If you need to warp a map for a strict display purpose, IMHO it's not to be performed from within grass given that this operation makes no sense geographically. I agree, Don't know what the context is, but if you just have to rotate an image output of a map maybe you'd better look towards image manipulation tools (e.g. imagemagick and the -rotate option, which can easily be integrated in a script process). pnmrotate is another that I've used with d.out.gpsdrive and GpsDrive's gdal_slice.sh script, together with 'g.region -n' to get the convergence angle. (angle between local projection north vs true north) render map with PNG driver in GRASS, read course-over-ground from Gpsd (gpsd.berlios.de) in watcher mode, pnmrotate and pnmcrop, and then use an image viewer which will update the display when the image changes. (see grass 7 discussions about that). Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit mouse click emulation on macbook
gsi wrote: I can run v.digit (grass64) on my macbook but I cannot use it because I cannot find how to emulate the right and middle click correctly. Rigth click (two fingers on the touchpad + click) behaves like a middle click, and I cannot find any combination to emulate the right click. John wrote: I believe that control-click and option-click emulate the other buttons in X11, but you will need to experiment. Did you try any modifier keys? on the bottom left of the mac keyboard there are 3 modifier keys- from left to right: control, option, and command clicking while holding down the control button on the left emulates a left click (a no-op), clicking while holding down the middle of those keys (option) emulates a middle click, and clicking while holding down the right of those keys (command/ old 'apple' key?) emulates a right-click. hth, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Label crash
Glynn: Yes. It's basically a symptom of MacOSX is sort of Unix, but not quite. Adam wrote: Actually MacOSX is Unix and Linux is almost Unix. there is only One True Unix, and it's either the Berkeley flavour or the Bell Labs one, but I thought those wars were long past. (just trying to nose-dive this discussion as quickly as possible) H ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] m.eigensystem segfaults under Jaunty (beta)
Nikos wrote: I have recompiled latest grass6_devel using the configuration copy-pasted in [2]. [2] CFLAGS=-g -Wall -O0 LDFLAGS=-s ./configure \ LDFLAGS=-s strips out the debugging messages from the final code to make smaller binaries. Not wanted here. also you can proably just leave out -O0. --enable-debug \ I don't see anything about that listed in ./configure --help | less so I don't think it actually does anything. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] new module: r.surf.volcano
Hi, I just added a new module to the wiki addons page: r.surf.volcano It creates an artificial surface resembling a seamount or cone volcano. The user can alter the size and shape of the mountain and optionally roughen its surface. http://grass.osgeo.org/wiki/GRASS_AddOns#r.surf.volcano http://trac.osgeo.org/grass/browser/grass-addons/raster/r.surf.volcano It's a shell script and requires GRASS 6.3.0 or newer. I'm using it for testing hydrodynamic flow models and r.sun. =-= GRASS r.surf.volcano --help Description: Creates an artificial surface resembling a seamount or cone volcano. Keywords: raster Usage: r.surf.volcano [-r] output=name [peak=value] [friction=value] [sigma=value] [--overwrite] [--verbose] [--quiet] Flags: -r Roughen the surface --o Allow output files to overwrite existing files --v Verbose module output --q Quiet module output Parameters: output Name for output raster map peak Height of cone default: 1000 friction Friction of distance, (the 'n' in 1/d^n) options: 1-25 default: 6 sigma Surface roughness factor default: 1.0 =-= enjoy, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] vector to raster: ERROR: G_calloc: unable
Martin Wegmann wrote: I solved it by using a different GIS and just copying the column to a new one with the type:INTEGER, however I would like to know how to do it with GRASS for the next time. Hamish: what does 'g.region -p' say? are the rows x columns some huge number? (ie bigger than 15000x15000 or so?) rows: 96256 cols: 128204 cells: 12340404224 that is the problem, you have asked for the raster to be too huge. do you really need that fine a resolution? e.g. it is not meaningful to measure the edge of a forest to the nearest mm. how much memory does you system have? 4GB Memory Debian unstable if relevant as MarkusM pointed out, reduce the number of rows in memory at one time and it should work. if you have it set to use 4096 rows in memory for each pass, that's: 4096 * 128204 cells/row * 8 bytes/cell = 4200988672 bytes of memory needed per pass = 4102mb = 4.1gb RAM + overhead. Does it mean that DOUBLE PRECISION with the 4GB memory does not work? How can I change the column then to INTEGER inside GRASS? it works if you have the resources or ask for a smaller task. BTW, when I did it with the new vector file: same v.info -t output - just one additional column, the v.to.rast excecuted without any problems and the raster looks fine, but if returned this output: v.to.rast input=in_new output=out column=LS_LEGEN_1 type=area Pass 24 of 24: Reading areas... 100% Writing raster map... 100% Cannot allocate memory: can't create fork what does it mean, not enough memory? Yes, but I'm not sure why it's trying to fork the process while closing the map. Not sure if that happened while it was writing the map's meta data or upon module tear-down. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clipping LiDAR data
Jack Lonsdale wrote: Is there an easy way to clip a LiDAR data file? Nikos wrote: Hi Jack. Did you try the -r switch? Something like g.region or d.zoom to some sub-region, then v.in.ascii -r in=... out=... ? tip now added to the wiki LIDAR page, http://grass.osgeo.org/wiki/LIDAR Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ' v.in.db ' question
Bulent Arikan wrote: I am trying to import an OpenOffice dbf into a wgs84 PERMANENT Location. I did this several times in the past with older versions of GRASS. I enter all the necessary information (input table, column names for x, y, z and CAT#). The Connection tab shows dbf for the driver name and database name reads $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ I get this message: DBMI-DBF driver error: Table 'Iron_II_KNOWN_Sites' doesn't exist Missing column CAT in table Iron_II_KNOWN_Sites I will greatly appreciate any suggestions. maybe it is case sensitive? try key=cat instead of key=CAT. ??? [SQL defines column names to be case insensitive, yes?? Did we ever find that in a spec somewhere?] # if you have `dbview` installed, what does this say: dbview -e filename.dbf | head Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installing grass trunk to jaunty
sudo make distclean there is no reason to run as root for anything but make install. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Resampling with percent cover
Ned Horning wrote: Hi � I am still working on creating a percent shrub cover map using GRASS and R and have a question regarding resampling. I have shrub/non-shrub/cloud maps at 1m resolution and I want to resample those to 30m pixels using the following logic. The value of each output 30m pixel will be the percentage of shrub pixels that make up the corresponding 30 x 30 pixel area from the shrub/non-shrub/cloud map and if any of the pixels in the 30 x 30 pixel area has a cloud value the value of the resulting 30m pixel will be NULL. Is there a way to do this in GRASS? R.resamp.stats seems like it is close but that might be too difficult for me to modify. Glynn wrote: There shouldn't be any need to modify it. Create a reclass of the input such that shrub=1, non-shrub=0 and cloud=null, then resample that with r.stats -n method=average (... that should read 'r.resamp.stats' not 'r.stats') The value of each output cell will be the proportion of shrub cells in the corresponding 30x30 block of input cells, in the range 0.0 to 1.0 (if you want 0-100, use r.rescale or r.mapcalc). With the -n flag, if one or more of the input cells in a 30x30 block are null, the corresponding output cell will be null. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] QGIS GRASS for online use
jgarcia wrote: What is the way you would advise to operate online (for any user with Internet Access) against a common GIS server with the full (or at least a good deal of) capabilities of GRASS? perhaps PyWPS or OpenLayers could help? http://pywps.wald.intevation.org/ http://grass.osgeo.org/screenshots/web.php Is it necessary to use mapserver, or is it possible to use a GRASS a a geodata server, and directly access them through QGIS remote clients? If mapserver is still required, do you know if there are some future plans to directly access GRASS as a server from remote GRASS or QGIS clients? both GRASS and QGIS have WMS input ability, now GDAL does as well. additionally QGIS has an easy to use mapsever output plugin AFAIK. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.whar.vect does not respond
Nikos wrote: + exec v.distance from=burned_area_sample_1_points to=sample_1_grid column=gridcell to_column=cat upload=to_attr dmax=0.0 from_layer=1 to_layer=1 100% 100% 100% ## Here it waits... waits... maybe just wait? I am _sure_ it did not take too long some last time when I tried this with the same map(s) ## Currently I am watching the same process ran via strace! It throws out numerous lseek/lread messages. I'll give it some time but something is wrong because it takes too much time. ok so v.distance is taking a very long time. can you try with v.what.vect --vebose ? that should give some more messages from v.distance instead of just 100% 100% 100%. also, you can turn on the debug messages: g.gisenv set=DEBUG=1 turn it up to 2,3,.. to get more messages. set it back to 0 to turn them off. I see one in v.distance G_debug(3, SQL: %s, db_get_string(stmt)); maybe more DB troubles? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net.path weight co
Stefano wrote: i've some problem with v.net.path now, if i specify the length of the path as weight i should receive the same path, right? but this doesn't work. don't quote me on this, but maybe try the inverse length? ie make a column which is SQL magic max(length column) - this_line_length and use that as the cost. e.g. see the help page example with speed limits. I may have it backwards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: [GRASS-dev] QGIS GRASS
Maybe web site hits statistics are more relevant? or number of download? Markus wrote: Find them here (That's *real* data): http://grass.osgeo.org/logs-bin/awstats.pl?config=grass.osgeo.org (and that doesn't include mirrors [at least I use one often]) anyway I don't know how useful a comparison is, qgis is a much more 'for the masses' tool than grass, so it would be natural for there to be many more users there. the interesting question in my mind is what is the market penetration in each's specific niche? sure there is some overlap in what they do, but it is far from an exact match. some intersting bits that stick out from this month's log: crawl.yahoo.net is using tons of bandwidth this month non-viewed traffic is 120gb so far, viewed is 45gb. wtf? top 10 URLs of note: (versus effort going into them) #4 /grass64/binary/mswindows/native/ #7 /wiki/GRASS_6_Tutorial http errors: 503 - Server busy 64.3 % 404 - Document Not Found 12.1 % I'm surprised anything beats 404, ... hmmph Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.vol.rst basic questions
I wrote: you are somewhat lucky that you are working near the equator. and I'm not just saying that because it's 4 degrees and raining! H ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.vol.rst basic questions
Christian Ferreira wrote: Actually, here I have a very strange thing... If I run g.list rast3d, I can list my interpoled volume. But if I try to run r3.info ctd_volume2 in the command line I get a message telling ERROR: Raster map ctd_volume2 not found, but if I use the GUI for r3.info is possible to read the file (like above). The same happens if I try start nviz with: nviz bathy volume=ctd_volume2 no idea. Aham. So, this means that v.vol.rst is not supposed to be used with Lat-Long? no idea, I'm just speculating based on the fact that lat/lon adds a lot of complication and the coder would have to had specifically written in special support for it. If yes, I will definitely quit this Lat-Long location and go to UTM. try both, see which way works best Well, after trying the whole Friday with nearlly no results, I'm quite convinced that v.vol.rst is not dumb. I meant that in the sense of it may not be lat/lon aware, not at all that it was a stupid program. Here is a try adjusting res3 to 0.000278 (30m), zmult to the same number and dmin to 0.001 http://picasaweb.google.com/chris.for.lists/Map#5334573425418213906 volume seems 90deg roated?! Hamish: actually the thing that I worry about there is not the x,y with z using different units (easily fixed by reprojecting to a planimetric projection), it is that all of your data points are essentially in a single straight line, and what effect that has on the 3D algorithm? Christian: As long I'm capable to produce a 2D slice along the transect/volume to show the data, the rest would not matter for the moment. But I understand that interpolation algorithm is having a hard time when trying to interpolate the cells away from the transect. again, I'm no expert at all with the module, just guessing. certainly all interpolation modules will have problems extrapolating through unconstrained boundaries to some extent. This was a test... the best is probably how you are saying below... it is a good test to do.. have you done the same thing with UTM before had had good results? Well, is not better (or possible) to set in GRASS a temporary region so thin (in the N-S axis) to create this 2D slice? sure, but I meant it was a 2D problem (x vs z) and you could fool the GIS into using its 2D x,y tools to solve the x,z problem then rotate the cells back to the correct orientation. and also maybe some r3.out.vtk stuff with Paraview or Vis5D? I'm trying to simply do all using GRASS... maybe is not the best choice. as good as any, better than most. :) just different tools for the job to explore. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] rotating symbols in d.vect?
Davids Corine wrote:
I know that it is possible to rotate symbols based on data in a column
in the attribute table in ps.map, but is this also possible in d.vect?
On the Wiki page for IconSymbols it implies that rotation of symbols
should be possible in the d.vect module from v.6.3, but I cannot
figure out how and there is nothing in the manual pages for d.vect.
hmph, the wiki page was wrong. I've just fixed that and added this as a
new wish in the trac system: http://trac.osgeo.org/grass/ticket/600
I think it would be a moderately simple feature to add.
Using the GRASS 6.4.0RC version you might try the v.out.ascii+d.graph
work-around I added to that wish-report:
#spearfish dataset
#create example values using the cat number for angle
# rotation is measured in degrees CCW from East
g.copy vect=archsites,test_rotate
v.db.addcol test_rotate column='rotation double precision'
v.db.update test_rotate column=rotation value='CAT'
v.out.ascii test_rotate column=rotation | \
awk -F'|' '{printf(rotation %s\nsymbol geology/strike_triangle 12 %s %s
black black\n, $4, $1, $2)}' \
test_rotate_graph.rules
d.graph -m test_rotate_graph.rules
d.vect test_rotate disp=cat yref=top
for GRASS 6.3 I think you have to get the v.out.ascii.db script from
wiki addons. (the 'v.out.ascii column=' option is new)
but William has 6.4.0RC Mac packages available on his website, which
is perhaps an easier/better solution to that.
(apologies if this post appears twice, I tried to post this
a few days ago already)
first copy I've seen.
good luck,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] RE:How to find shortest distances from the investigation point to the shoreline
sgw00412 wrote: I tested by two kinds of geographical coordinate systems by using the same data. One of the geographical coordinate systems is UTM54, and the remainder is wgs84. data :point vector data (10 points) and a line vector data OS: grass 6.2.3 on Cygwin. As a result, the case of UTM54 obtained the distance of meter. On the other hand, wgs84 obtained the distance of decimal value. So, I guess that the decimal value of wgs84 is a degree of latitude longitude. Grass manual wrote that ...In lat-long locations v.distance gives distances (dist and to_along) in meters not in degrees calculated as geodesic distances on a sphere.. http://www.ces.iisc.ernet.in/grass/grass64/manuals/html64_user/v.distance.html Though this manual is version 6.4, the manual of version 6.2 is not written it. Is this interpretation correct? If it is so, please teach me the method of converting the decimal value into the meter. Yes, version 6.2.3 is giving distances in (useless) degree units. This was fixed in Jan 2008 by Martin to use geodesic distance in meters, so GRASS 6.3.0 and the upcoming 6.4 do return meters. But 6.2.3 was released in Nov 2007 and so is too old to have that fix. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass cell registration format
Seb wrote: What type of registration do GRASS raster cells use? cell, not grid. see http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html I'm trying to import several hundred rasters from GMT into GRASS, old GMT binary grid or new NetCDF GMT binary grid? and the only way I managed to do it was by piping grd2xyz output through r.in.xyz, did r.in.gdal not work? that should take care of the grid-cell registration region adjustments for you. (hopefully) does it segfault too? as the Wiki recommendation to use r.in.bin failed with segmentation fault (I think this is due to the GDAL packages in Debian sid, which cannot read the GMT grids because gdalinfo shows that same segfault). weird, r.in.bin specifically does not use GDAL at all. did you convert to an old style GMT grid before trying 'r.in.bin -h'? was an earlier version of gdalinfo able to read it? can gmt's grdinfo say anything about it? One of my concerns with the pipe I described is that grd2xyz's output corresponds to grid line registration, and I'm not sure this matches what GRASS uses. All of this happens in a lat/lon location. Any tips would be appreciated. Thanks. maybe the new XYZ import wiki page Markus just created can help? it explains how to expand the region by half a cell outward to deal with the different registration method. (see also the r.region module) http://grass.osgeo.org/wiki/Import_XYZ but r.in.gdal should be the easy automatic way... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass cell registration format
Seb: I'm trying to import several hundred rasters from GMT into GRASS, and the only way I managed to do it was by piping grd2xyz output through r.in.xyz, oh, besides the GMT wiki page[1] see also this wiki page[2] which gives an example of grd2xyz | r.in.xyz. [1] http://grass.osgeo.org/wiki/GRASS_and_GMT [2] http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data please fix directly or point out any errors or inefficiencies you find. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
