Re: [GRASS-user] grass70 and display monitor
I very much agree with Markus. The main point is that a command line interface is *much* faster than a GUI, once you have learned to use it. This can take a long time to learn (take the VIM editor for example), and for most people that is simply not worth it. When you have it in your fingers however, it really is much more efficient. I still use Grass54 for digitizing, even if I have to convert the vector maps into the new format, because digitizing, the most labour-intensive job there is in GIS, gets done much more efficiently with the left hand using the keyboard, and the right hand using the mouse. That program has disappeared, but Markus's example illustrates perfectly the case for the actual version of GRASS. I understand that programmers have limited time and resources, and I certainly agree that these should be spent on the GUI: it's important for many more people than the bunch of old-hand command line hackers. I *would* plead however to leave as much of the old functionality in place as possible. If I understand Glynn's posting on this subject correctly however, this will be very difficult, as the Vask library has been removed (why?), and all mouse interaction has been dropped from the display commands. If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases? Jan Markus Neteler wrote: On Fri, Dec 4, 2009 at 3:23 PM, Michael Barton michael.bar...@asu.edu wrote: Roy, I guess you haven't been following quite all of this discussion. Sincerely, I am in the same boat apparently, see below. You can still run all module commands in GRASS from any terminal. You can TYPE d* commands into the command line interface of the GUI and have the resulting maps displayed in the GUI display canvas. You can also type the d.* commands into any xterminal and have grass maps saved as graphic files to view. These can be viewed automatically with free image viewers (like d.mon did) as Glynn has shown. The old, primitive, INTERACTIVE xterminal behavior is all that has been dropped. And that's the key issue here. Personally, I need (beside d.rast/d.vect) - d.zoom - d.measure - d.where to interactively work with the maps. GRASS analysis consists in my case of a significant amount of graphically digging in the maps. For interactive use, there is a much more sophisticated interface that exists now--that is, you can do a lot more interaction than you could do before. True. But it is not yet as efficient as the old method. To better explain (and please don't get me wrong, you have done a tremendous job with the new GUI!!, note that I am one of these funky cmd line power users :-): - to visualize a, say, raster map which I have been looking at 3 months ago, I type in bash CTRL-R and a fraction of what I remember of the name, then maybe another few CTRL-R to cycle to the right one. Enter and I see it. - Using the GUI, I have to use the icon/find the menu entry, select the map in the map selector (problem here, my MODIS LST time series have 5 * 1460 maps per mapset, that would be 7300 maps to scroll through!), then accept it and have it listed in the map list. Still I don't see it because the Render button isn't activated by default... (see my other poll about this some time ago). So, using the GUI here is unrealistic. Sure, I am a strange user :) Besides simply not being GRASS 4 or 5 (which are still available to be run), what functionality are you missing? The speed of displaying maps and the ease of querying them. If there was a command line possibility to control the wxGUI, I would most likely make the switch to GRASS 7. Speed really matters for me. I am routinely analysing 11,000+ maps and regularly work in 3 projects in one morning, so the command line history is a real lifesaver here to also recall what I have done (and to eventually morph it to a document). The new GUI, integrated with the command line possibility to throw in the maps, would be the perfect combination. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass70 and display monitor
Michael Barton wrote: A point on digitizing. If you haven't tried it, you should take a look at the digitizing that Martin has built into the new GUI. Because it has hot-key equivalents for all buttons, you CAN digitize with your right hand on the mouse and left on the keyboard. It also has a lot of contextual menus that you access by right clicking while you digitize rather than having to move to a separate text area like in 5.4. Ah, I hadn't realized that. Is that in GRASS 7? I don't use GRASS enough to compile the unstable versions, but now it's the first thing I am going to do on Monday. Takes away my only major problem with GRASS. BTW, I see that I asked for this last February (http://lists.osgeo.org/pipermail/grass-user/2009-February/048986.html). Don't know if that was the reason for the hot-keys, but thanks anyway. If that is too much trouble, I would be perfectly happy to use older versions of GRASS for dedicated purposes, provided I could use the same mapsets. Copying and converting maps between different versions if the program is a major source of errors, some of them very insidious. Would that be an alternative for retaining old functionality: reading directly from old-style databases? This is not something I do any coding for, but AFAIK, GRASS will continue to be able to read GRASS files from the past, either directly or via translation. It's not that important for me any more now, but perhaps older versions of GRASS could be bundled as Qgis in OsGeo4W, where you can install one or more of four versions. For Linux, you could think of distributing them like the FWTools utilities: each version in a single directory tree, including all the dependencies (and even a complete Python). That way, different versions can be used without conflicts between library versions. At least, that is the way I manage them on the cluster I am working on, to get quick functional copies on different nodes. Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit - new wiki page for migrators
A question from a very old GRASS-hand (I have used it since we got Internet in Amsterdam in 1991, having downloaded and compiled it, with the complete X-Window system, from a 9600-baud telephone line. Had even to compile the gcc-compiler, since native AIX cc didn't like GRASS): In the old, pre-6 v.digit, all commands were given by keyboard shortcuts. That took some exercise, but once you had it in your fingers (literally), you could digitize much faster than with the present click-button interface. I would guess it isn't all too difficult to add the old keyboard shortcuts to the system. Any idea from the developers whether this could be done? I still have GRASS 5.7 running for digitizing only. Beats every other package. Jan Dr. J. Hartmann Department of Geography University of Amsterdam Micha Silver wrote: I've posted a new page on the wiki [1] entitled Digitizing Area Features. It's targeted at new GRASS users, migrating from other non-topological software. I'd appreciate any comments from more experienced users as to correctness, completeness, or clarity. Thanks, Micha [1] http://grass.osgeo.org/wiki/Digitizing_Area_Features ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit - new wiki page for migrators
Yes, exactly, especially the panning and zooming. If this is not the place to place suggestions for enhancements, where can I put them? Vincent Bain wrote: Hi, it may not be the right place to develop proposals, but if I could piggyback on what Jan said, I think his suggestion is very pertinent to those who -- as I said in a recent previous post -- really produce vector data ! one has to be able to work with both hands (one on the keyboard, the other on the mouse or the graphic pad). It quickly becomes much more efficient than clicking around all the time ;-) Another enhancement I would really expect is the ability to have such shortcuts for dynamically panning and zooming, while digitizing. Sorry if I only can give suggestions, but few coding solutions... Thanks, Vincent Le mercredi 18 février 2009 à 14:53 +0100, Jan Hartmann a écrit : A question from a very old GRASS-hand (I have used it since we got Internet in Amsterdam in 1991, having downloaded and compiled it, with the complete X-Window system, from a 9600-baud telephone line. Had even to compile the gcc-compiler, since native AIX cc didn't like GRASS): In the old, pre-6 v.digit, all commands were given by keyboard shortcuts. That took some exercise, but once you had it in your fingers (literally), you could digitize much faster than with the present click-button interface. I would guess it isn't all too difficult to add the old keyboard shortcuts to the system. Any idea from the developers whether this could be done? I still have GRASS 5.7 running for digitizing only. Beats every other package. Jan Dr. J. Hartmann Department of Geography University of Amsterdam Micha Silver wrote: I've posted a new page on the wiki [1] entitled Digitizing Area Features. It's targeted at new GRASS users, migrating from other non-topological software. I'd appreciate any comments from more experienced users as to correctness, completeness, or clarity. Thanks, Micha [1] http://grass.osgeo.org/wiki/Digitizing_Area_Features ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit - new wiki page for migrators
Michael Barton wrote: Submit enhancement requests to the GRASS Trac site. That way, they don't get lost in a mountain of emails. I think there is a vdigit topic. If not, put it to wxgui. Done. Thanks Michael. Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit - new wiki page for migrators
No, I didn't know it, but to be honest, I find it almost as confusing as this mailing list :-). Jan Vincent Bain wrote: Not yet very familiar with grass wiki, but perhaps here : http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan#Wishlist Vincent Le mercredi 18 février 2009 à 15:55 +0100, Jan Hartmann a écrit : Yes, exactly, especially the panning and zooming. If this is not the place to place suggestions for enhancements, where can I put them? Vincent Bain wrote: Hi, it may not be the right place to develop proposals, but if I could piggyback on what Jan said, I think his suggestion is very pertinent to those who -- as I said in a recent previous post -- really produce vector data ! one has to be able to work with both hands (one on the keyboard, the other on the mouse or the graphic pad). It quickly becomes much more efficient than clicking around all the time ;-) Another enhancement I would really expect is the ability to have such shortcuts for dynamically panning and zooming, while digitizing. Sorry if I only can give suggestions, but few coding solutions... Thanks, Vincent Le mercredi 18 février 2009 à 14:53 +0100, Jan Hartmann a écrit : A question from a very old GRASS-hand (I have used it since we got Internet in Amsterdam in 1991, having downloaded and compiled it, with the complete X-Window system, from a 9600-baud telephone line. Had even to compile the gcc-compiler, since native AIX cc didn't like GRASS): In the old, pre-6 v.digit, all commands were given by keyboard shortcuts. That took some exercise, but once you had it in your fingers (literally), you could digitize much faster than with the present click-button interface. I would guess it isn't all too difficult to add the old keyboard shortcuts to the system. Any idea from the developers whether this could be done? I still have GRASS 5.7 running for digitizing only. Beats every other package. Jan Dr. J. Hartmann Department of Geography University of Amsterdam Micha Silver wrote: I've posted a new page on the wiki [1] entitled Digitizing Area Features. It's targeted at new GRASS users, migrating from other non-topological software. I'd appreciate any comments from more experienced users as to correctness, completeness, or clarity. Thanks, Micha [1] http://grass.osgeo.org/wiki/Digitizing_Area_Features ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Hamish wrote: - 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) 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? Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Interesting. I know something of these models (worked a few years for the archaeology department here in Amsterdam), and, like you, never had enough time to really code it. Apart from efficiency, I am wondering whether those really cool cost surfaces will degenerate into impossible vector polygons. Do you have any examples from archaeological practice, using this gravitation approach? How were they computed? Jan Benjamin Ducke wrote: The Voronoi diagram is closely related to gravity models: every cell in the raster map gravitates towards the closest center point in the input point pattern. If you change the gravitational attraction of individual points, you get a weighted Voronoi diagram. If you change the measure of gravity by switching from straight-line distance to e.g. cost-based then you get something more complex and realistic than any Voronoi algorithm can provide. In Archaeology, a simple formula (called Xtent) has been used to calculate such gravity models for a long time: I = C^a - k*d With I being the influence of an input point. I gets calculated for every input point at every cell in the map. The input point with highest I wins and the cell gets assigned to that point's ID. (C^a) is the weight of a point. (k*d) is your (weighted) distance measure. Set (C^a) constant and use a straight-line distance measure and you get your basic Voronoi diagram. Assign different weights to C and you get a weighted diagram. Replace (k*d) with a more realistic, cost-based measure and you get something ... really cool. I am sure, there is a myriad of similar models/formulas in other disciplines. I have actually written a GRASS module called r.xtent based on this. It still has some known bugs, however, and I simply don't have the time to fix it right now. It's also pretty bloated and inefficient, so a clean, more minimalistic start might not be a bad idea. Ben Jan Hartmann 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? Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Glynn Clements wrote: 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? Oops; I spoke too soon. In retrospect, this won't work. r.grow.distance relies upon the fact that once a cell falls out of consideration, it stays out. It will only consider cells which either are from the current row, or were used on the previous row. With distance scaling, this doesn't hold. A cell could be temporarily overriden by much nearer cells with increased scale factors (lower weights), then regain its influence once the distance increases. IOW, this isn't something which can implemented given the algorithm used by r.grow.distance. Any algorithm which implemented distance scaling would inevitably have worst-case memory usage proportional to the number of non-null input cells, as you can never forget a cell whose scale factor is lower than those currently being considered, as it will eventually regain its influence. Do you mean that implementing a raster version of weighted Voronoi methods would be very inefficient, compared to vector methods, or that it would be very difficult? I have tried to see what's in the ArcGIS extension (http://portal.acm.org/citation.cfm?id=1332465, documentation at: http://www.geog.unt.edu/~pdong/software/VoronoiHelp.pdf), but the math is beyond me. If you think it would be viable to implement this in GRASS, I could have a closer look at it. These weighted Voronoi polygons are really an interesting methodology. Jan Hartmann Departmann of Geography University of Amsterdam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Yes, I guess that what I meant too, you just formulate it better, in a more general way. I find this interesting, as I have experimented with weighted Voronoi polygons, but only in vector format. There is a complete book on that methodolgy: Atsuyuki Okabe, Barry Boots, Kokochi Sugihara, Sung Nok Chiu: Spatial Tesselations. Concepts and Applications of Voronoi Diagrams. Wiley, Chichester 2000. It's really fascinating to see how much you can do with this technology, not only in theory but also in practice. Of course, the vector based algorithms are hard to implement and can be very resource hungry. A lot of them are already available however: just Google on weighted voronoi. As always, a raster based approach could be not only more efficient, but also conceptually more general. There is an ArcGIS extension available that does exactly this: see http://portal.acm.org/citation.cfm?id=1332465 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? Jan Glynn Clements wrote: Jan Hartmann wrote: The problem with using r.cost is that you would need to know the cost for each cell before you have created the polygons. I think that the simplest accurate approach would be to modify r.grow.distance. Do you mean: adding a metric parameter to Euclidean, Squared, Manhattan, and Maximum? Something like: compute on the basis of the value of traversed cells? I mean scale the distance by the value of the nearest non-null cell. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Thiessen Polygons
Glynn Clements wrote: Dylan Beaudette wrote: While we are on this topic, is there a way to get a weigthed voronoi diagram using grass ? The ability to rank a point to tune the area's influence would be great, for that purpose I've been using an arcgis'extension* but with grass it is not possible**. Is there a way to get a similar result ? *http://www.geog.unt.edu/~pdong/software.htm **http://osdir.com/ml/gis.grass.user/2004-04/msg00036.html Regards, MORREALE Jean Roc Now that I have read about 'weighted voronoi diagrams', I wonder if a combination of r.cost + r.mapcalc would solve this problem. Something along those lines is demonstrated here: http://casoilresource.lawr.ucdavis.edu/drupal/node/288 This example isn't quite what is requested, although using r.cost with start=point_i, and stop=neighbor_points (derived from v.delaunay / v.distance?) may work. It would then be a little more work to convert the weighted-distance rasters into polygons, and link back to the original attribute tables... but (hopefully) not outside the realm of possibility via a script. The problem with using r.cost is that you would need to know the cost for each cell before you have created the polygons. I think that the simplest accurate approach would be to modify r.grow.distance. Do you mean: adding a metric parameter to Euclidean, Squared, Manhattan, and Maximum? Something like: compute on the basis of the value of traversed cells? Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using grass on rasters without converting?
Markus Neteler wrote: Hi Matt, On Thu, Oct 30, 2008 at 1:07 PM, matt wilkie [EMAIL PROTECTED] wrote: Hello Grass World, As a long time GIS user I've dipped into grass from time to time but never in depth. One of the things that's deterred me is the fact that I have a large body of data I work with (tens of gigabytes) and the prospect of having to convert into grass, process it, and then flip it back out again is unappealing. Sure - also for us :) But it has been solved recently: r.external - Link GDAL supported raster file to a binary raster map layer. http://grass.osgeo.org/grass64/manuals/html64_user/r.external.html This solves a need for me too. Could something like that be done for WMS services, i.e. not downloading them with r.in.wms, but linking them without making a local copy? Jan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
