<br>hello,<br><br> Please help me to open tiff images i m using grass6.1 in windows<br>this is not supporting r.in.tiff when i m opening tif file by r.in.gdal there is only<br>a grey image.<br><br><br><br><b><i>grassuser-request@grass.itc.it</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Send grassuser mailing list submissions to<br> grassuser@grass.itc.it<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://grass.itc.it/mailman/listinfo/grassuser<br>or, via email, send a message with subject or body 'help' to<br> grassuser-request@grass.itc.it<br><br>You can reach the person managing the list at<br> grassuser-owner@grass.itc.it<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of grassuser digest..."<br><br><br>Today's Topics:<br><br> 1. Re: 64 bit or parallel processing (S?ren Gebbert)<br> 2. using LLID
numbers with the linear referencing system<br> (Lindsay Mico)<br> 3. Re: 64 bit or parallel processing (Hamish)<br> 4. RE: 64 bit or parallel processing (Charles Ehlschlaeger)<br> 5. RE: 64 bit or parallel processing (Jonathan Greenberg)<br> 6. Open Source GIS Gathering San Diego (OSG-SD) - June 18th,<br> 2007 (Dana Nibby)<br> 7. Re: 64 bit or parallel processing (Glynn Clements)<br> 8. Re: help with ogr2ogr and .shp file (Hamish)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 28 Feb 2007 23:48:49 +0100<br>From: S?ren Gebbert <soerengebbert@gmx.de><br>Subject: Re: [GRASS-user] 64 bit or parallel processing<br>To: Glynn Clements <glynn@gclements.plus.com><br>Cc: grassuser@grass.itc.it<br>Message-ID: <45E606D1.50907@gmx.de><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br><br>Glynn Clements wrote:<br>> Hamish wrote:<br>> <br>>> It may be interesting
to try and parallelize the segmentation library,<br>>> but most of GRASS's raster code needs to be rewritten.<br>>><br>>> two problems:<br>>> 1) most grass raster modules are serial row based. maybe if the raster<br>>> format gets updated to a tiled model it would be possible to start<br>>> parallizing it. (not impossible, NULL and FP support was added in the past)<br>>> or break up lines into chunks like raster modules that have rows= or<br>>> percent= options already.<br>> <br>> Rows versus tiles doesn't have any impact upon the ability to<br>> parallelise the code.<br><br>It will be easier with a tile based approach to parallelize the code.<br>The g3d lib implementation allows different tile sizes. So you are able<br>to define tile sizes (befor open a map) which will fit perfectly into<br>the memory. Those tiles can be processed in parallel.<br>I guess a similar approach can be implemented using the segment
library <br>for raster maps.<br><br>I hope to get a prototype running using tile based parallelizing <br>approach in 5 - 6 months. It will be part of the new gpde library and <br>will use the gpde array implementation for easy data access and because <br>its thread safe (AFAIKT).<br>The gpde lib uses OpenMP www.openmp.org for parallel computation in <br>grass. But only the linear equation solver and the linear equation <br>system assembler are parallelized. This will hopefully change in the future.<br><br>To enable parallel data access will be a hard work in grass and will <br>only work on cluster file systems. One approach will be to distribute <br>the rows and tiles to different storage places to enable parallel data <br>access.<br><br>Just my two cent<br>Soeren<br><br>>> 2) the raster file format is split over may directories making it hard<br>>> to "lock" a map so another job doesn't try and edit the same map. the<br>>> future plan is to have the
raster format stored like the vector format,<br>>> $MAPSET/raster/$MAPNAME/element, edited as a copy and moved into position<br>>> in full when the raster is closed.<br>>><br>>> 3) (bonus problem) we need to ensure that the region (WIND) file isn't<br>>> modified by any module but g.region, and that modules read the WIND file<br>>> only one when they first start. (in case it changes mid-process)<br>> <br>> This isn't an issue for parallelising individual modules (i.e. using<br>> multiple threads in order to utilise multiple CPU cores). It is an<br>> issue for being able to run multiple modules concurrently.<br>> <br>> The core problem for parallelising GRASS is that the libraries aren't<br>> remotely thread-safe, and the way that they are written is such that<br>> making them thread-safe would be a lot of work.<br>> <br>> The two biggest issues are:<br>> <br>> 1. Use of global/static variables; libgis
alone has ~180 of them (not<br>> including the 181 GRASS_copyright variables).<br>> <br>> 2. Use of "scratch" buffers. Current policy deprecates the use of<br>> alloca(), so eliminating scratch buffers would involve lots of<br>> malloc/free calls for short-lived buffers, which is inefficient.<br>> <br>> Consequently, it isn't feasible to make the bulk of GRASS thread-safe. <br>> We might be able to do this for limited portions, e.g. the core raster<br>> I/O code (get/put row operations), but you would still need to ensure<br>> that everything else was called from the main thread.<br>> <br>> It would be more feasible to modify individual modules; e.g. a<br>> multi-threaded version of r.mapcalc might be feasible. But unless the<br>> raster I/O code was made thread-safe, you would still be limited by<br>> the rate at which map data could be read and written by a single<br>> thread, so it would only be worthwhile for cases where
the bulk of the<br>> overhead was in the actual calculations.<br>> <br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 28 Feb 2007 16:13:53 -0800<br>From: "Lindsay Mico" <lindsaymico@hotmail.com><br>Subject: [GRASS-user] using LLID numbers with the linear referencing<br> system<br>To: grassuser@grass.itc.it<br>Message-ID: <BAY121-F20D805DBDA00493E92B8C4A3800@phx.gbl><br>Content-Type: text/plain; format=flowed<br><br>Fellow GRASS users,<br><br>I would like to build a new point data layer from a large database of stream <br>surveys which have 2 pieces of spatial info:<br><br>1) an LLID number for that stream<br>2) distance from the start of that stream<br><br>Based on what I have seen, I would use the linear referencing system <br>modules. I am not sure if I need to build a new reference layer as I have a <br>stream layer with the LLID info already in it. Additionally, I could not <br>find an example of how v.lrs.segment works in practice.
I have attempted to <br>summarize things as I understand it to help make it easier to answer my <br>questions. As I understand it the input parameters for v.lrs.segment would <br>be as follows:<br><br>1) input= the stream layer with the associated LLID info<br>2) output = the name of the output layer<br>3) llayer = whether it is a point or line (is it 1 for line and 0 for <br>point?)<br>4) rsdriver = I don't know what this means<br>5) rsdatabase = the location of the file with the LLID # and distance<br>6) rstable = the name of the file which has the LLID number and distance? <br>will it automatically add in the other data in the database? Or do I do <br>that later using a spreadsheet program on the .dbf<br><br>As I am still learning how to do this, I expect I will have more questions <br>in the future. Hopefully this will be of use to others as well. Many <br>thanks in advance. Cheers.<br><br><br>Lindsay Mico<br>Environmental Consultant<br>Demeter Design
LLC<br>(503) 368-7195<br>http://demeterdesign.net<br>"Thoughtful Planning is the Surest Investment"<br><br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 1 Mar 2007 13:14:14 +1300<br>From: Hamish <hamish_nospam@yahoo.com><br>Subject: Re: [GRASS-user] 64 bit or parallel processing<br>To: Glynn Clements <glynn@gclements.plus.com><br>Cc: grassuser@grass.itc.it<br>Message-ID: <20070301131414.69298749.hamish_nospam@yahoo.com><br>Content-Type: text/plain; charset=US-ASCII<br><br>Glynn Clements wrote:<br>> It would be more feasible to modify individual modules; e.g. a<br>> multi-threaded version of r.mapcalc might be feasible. But unless the<br>> raster I/O code was made thread-safe, you would still be limited by<br>> the rate at which map data could be read and written by a single<br>> thread, so it would only be worthwhile for cases where the bulk of the<br>> overhead was in the actual calculations.<br><br>Right, so working on
individual modules which can typically take 10+<br>hours to run (*.rst, watersheds, viewsheds (incl. r.sun), indices from<br>RS data, etc) seems like a much better focus of effort for the greatest<br>gain:work ratio. And as seen in the MPI add-ons this is exactly where<br>the previous ad-hoc effort has gone.<br><br>IIRC Helena said that the RST modules have changed substantially sice<br>GRASS 5 and the s.surf.rst.mpi work would have to be largely redone.<br><br>Any thoughts on gains that could be made by MPI'ing the segmentation<br>lib? Do do modules using that usually do so for memory needs not<br>processing speed?<br><br><br>Hamish<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, 28 Feb 2007 18:52:38 -0600<br>From: "Charles Ehlschlaeger" <c.ehlschlaeger@insightbb.com><br>Subject: RE: [GRASS-user] 64 bit or parallel processing<br>To: <grassuser@grass.itc.it><br>Message-ID: <5mf1q2$2ba67f@asav15.insightbb.com><br>Content-Type: text/plain;
charset="US-ASCII"<br><br>Most GRASS raster functions, r.mapcalc and similar, won't speed up by more<br>than a couple of percent from parallelization. 90% of the time spent by<br>these commands comes from moving the data off the hard drive and getting it<br>to the CPU and visa versa (based on parallel processing research I did in<br>the mid '90s). For "normal" GRASS raster commands, having four hard drives<br>on RAID 0 will dramatically increase GRASS performance more than anything<br>one thing you could do to a computer (or GRASS itself). The reason ORNL<br>parallelized my code was that the computational requirements was over c^2,<br>where c is the number of grid cells on a map, for some of the analyses they<br>wanted to do.<br><br>As Hamish wrote in recent email, good candidates for parallelization would<br>be viewshed analysis or other functions requiring many cells to be read to<br>get a value for each output grid cell. r.watershed won't benefit
from<br>parallelization.<br><br>Chuck Ehlschlaeger, Associate Professor & GIS Center Director<br>Department of Geography, Western Illinois University<br>215 Tillman Hall, 1 University Circle, Macomb, IL 61455<br>cre111@wiu.edu, phone: 309-298-1841, fax: 309-298-3003<br><br>-----Original Message-----<br>From: grassuser-bounces@grass.itc.it [mailto:grassuser-bounces@grass.itc.it]<br>On Behalf Of Glynn Clements<br>Sent: Wednesday, February 28, 2007 3:33 PM<br>To: Hamish<br>Cc: grassuser@grass.itc.it<br>Subject: Re: [GRASS-user] 64 bit or parallel processing<br><br><br>Hamish wrote:<br><br>> It may be interesting to try and parallelize the segmentation library,<br>> but most of GRASS's raster code needs to be rewritten.<br>> <br>> two problems:<br>> 1) most grass raster modules are serial row based. maybe if the raster<br>> format gets updated to a tiled model it would be possible to start<br>> parallizing it. (not impossible,
NULL and FP support was added in the<br>past)<br>> or break up lines into chunks like raster modules that have rows= or<br>> percent= options already.<br><br>Rows versus tiles doesn't have any impact upon the ability to<br>parallelise the code.<br><br>> 2) the raster file format is split over may directories making it hard<br>> to "lock" a map so another job doesn't try and edit the same map. the<br>> future plan is to have the raster format stored like the vector format,<br>> $MAPSET/raster/$MAPNAME/element, edited as a copy and moved into position<br>> in full when the raster is closed.<br>> <br>> 3) (bonus problem) we need to ensure that the region (WIND) file isn't<br>> modified by any module but g.region, and that modules read the WIND file<br>> only one when they first start. (in case it changes mid-process)<br><br>This isn't an issue for parallelising individual modules (i.e. using<br>multiple threads in order to utilise multiple CPU
cores). It is an<br>issue for being able to run multiple modules concurrently.<br><br>The core problem for parallelising GRASS is that the libraries aren't<br>remotely thread-safe, and the way that they are written is such that<br>making them thread-safe would be a lot of work.<br><br>The two biggest issues are:<br><br>1. Use of global/static variables; libgis alone has ~180 of them (not<br>including the 181 GRASS_copyright variables).<br><br>2. Use of "scratch" buffers. Current policy deprecates the use of<br>alloca(), so eliminating scratch buffers would involve lots of<br>malloc/free calls for short-lived buffers, which is inefficient.<br><br>Consequently, it isn't feasible to make the bulk of GRASS thread-safe. <br>We might be able to do this for limited portions, e.g. the core raster<br>I/O code (get/put row operations), but you would still need to ensure<br>that everything else was called from the main thread.<br><br>It would be more feasible to modify individual
modules; e.g. a<br>multi-threaded version of r.mapcalc might be feasible. But unless the<br>raster I/O code was made thread-safe, you would still be limited by<br>the rate at which map data could be read and written by a single<br>thread, so it would only be worthwhile for cases where the bulk of the<br>overhead was in the actual calculations.<br><br>-- <br>Glynn Clements <glynn@gclements.plus.com><br><br>_______________________________________________<br>grassuser mailing list<br>grassuser@grass.itc.it<br>http://grass.itc.it/mailman/listinfo/grassuser<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Wed, 28 Feb 2007 17:06:33 -0800<br>From: "Jonathan Greenberg" <greenberg@ucdavis.edu><br>Subject: RE: [GRASS-user] 64 bit or parallel processing<br>To: <grassuser@grass.itc.it><br>Message-ID: <000301c75b9d$dab6bab0$b0a6eda9@terra.cstars.ucdavis.edu><br>Content-Type: text/plain; charset="us-ascii"<br><br>I'm now working at UCD on a project with
> 65 (!) hyperspectral images, and<br>a LOT of the slow downs stem from I/O intensive processes -- with that said,<br>there are plenty of "standard" raster processing routines that start<br>becoming processor intensive (e.g. linear spectral unmixing) that, with a<br>decent i/o setup (we have a lot of cheap-o 2-drive RAID0s that we back up to<br>a permanent location, this nearly doubles our I/O speed). Not having any<br>idea of how grass's raster access backbone functions, it does seem you could<br>have a generic tiling routine that could be called from all of the raster<br>commands that would be highly parallizable (I note that RSI ENVI does this<br>out of the box now, it detects the # of processors and simply starts forking<br>a single image across all of the processors, I assume one line/tile per<br>processor). Mapcalc and related processes would be a good start, and keep<br>in mind *spatial* analyses (e.g. texture windows) as you design it. <br><br>My suggestion
to the GRASS programmers: if you decide this is useful, I'd<br>HIGHLY recommend trying to do this in an out-of-the-box approach, e.g.<br>having an install-time "mp" capability -- if it requires being a) experts in<br>raster processing, b) experts in GRASS and c) experts in parallel coding,<br>you'll end up with 3 people doing SMP :) <br><br>--j<br><br>-----Original Message-----<br>From: grassuser-bounces@grass.itc.it [mailto:grassuser-bounces@grass.itc.it]<br>On Behalf Of Hamish<br>Sent: Wednesday, February 28, 2007 4:14 PM<br>To: Glynn Clements<br>Cc: grassuser@grass.itc.it<br>Subject: Re: [GRASS-user] 64 bit or parallel processing<br><br>Glynn Clements wrote:<br>> It would be more feasible to modify individual modules; e.g. a<br>> multi-threaded version of r.mapcalc might be feasible. But unless the<br>> raster I/O code was made thread-safe, you would still be limited by<br>> the rate at which map data could be read and written by a single<br>> thread, so
it would only be worthwhile for cases where the bulk of the<br>> overhead was in the actual calculations.<br><br>Right, so working on individual modules which can typically take 10+<br>hours to run (*.rst, watersheds, viewsheds (incl. r.sun), indices from<br>RS data, etc) seems like a much better focus of effort for the greatest<br>gain:work ratio. And as seen in the MPI add-ons this is exactly where<br>the previous ad-hoc effort has gone.<br><br>IIRC Helena said that the RST modules have changed substantially sice<br>GRASS 5 and the s.surf.rst.mpi work would have to be largely redone.<br><br>Any thoughts on gains that could be made by MPI'ing the segmentation<br>lib? Do do modules using that usually do so for memory needs not<br>processing speed?<br><br><br>Hamish<br><br>_______________________________________________<br>grassuser mailing
list<br>grassuser@grass.itc.it<br>http://grass.itc.it/mailman/listinfo/grassuser<br><br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Wed, 28 Feb 2007 18:23:11 -0800 (PST)<br>From: Dana Nibby <danaspatial@yahoo.com><br>Subject: [GRASS-user] Open Source GIS Gathering San Diego (OSG-SD) -<br> June 18th, 2007<br>To: grass mailing list <grassuser@grass.itc.it><br>Message-ID: <672492.17452.qm@web37112.mail.mud.yahoo.com><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>Folks, save the datum.<br><br>We're tentatively planning a 2nd Annual Open Source GIS Gathering to be held on Monday, June 18th - probably starting early afternoon, ending late in the evening. The same Monday of the Plenary Session(s) of another famous GIS conference held in San Diego.<br><br>Don't be lost in space... San Diego State University's Visualization Lab is easy to find via trolley from the San Diego Convention Center area.<br><br>We filled the Lab in 2006, and
arrangements are being made to accommodate more. Suggested ideas for this year include technical workshops and roundtable discussions.<br> <br>If you, or anyone you know, would be interested in presenting on an open source GIS topic, or conducting a technical workshop, please contact Dana Nibby here: danaspatial@yahoo.com.<br><br>There's now a mailing list for OSG-SD 2007. If you think you may be interested in attending, please sign-up below:<br><br>http://lists.telascience.org/mailman/listinfo/osg-sd<br><br>Spread the word to the extent possible. Geotag, you're "it."<br><br><br>Spatial Regards,<br><br> Dana<br><br><br> <br>---------------------------------<br>Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:
http://grass.itc.it/pipermail/grassuser/attachments/20070228/da62997e/attachment-0001.html<br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 1 Mar 2007 02:27:10 +0000<br>From: Glynn Clements <glynn@gclements.plus.com><br>Subject: Re: [GRASS-user] 64 bit or parallel processing<br>To: Hamish <hamish_nospam@yahoo.com><br>Cc: grassuser@grass.itc.it<br>Message-ID: <17894.14846.975053.90603@cerise.gclements.plus.com><br>Content-Type: text/plain; charset=us-ascii<br><br><br>Hamish wrote:<br><br>> Any thoughts on gains that could be made by MPI'ing the segmentation<br>> lib? Do do modules using that usually do so for memory needs not<br>> processing speed?<br><br>Modules which use the segment library normally do so because they<br>access the raster data in an order other than top-to-bottom.<br><br>If an algorithm reads the data in a linear fashion, there's no point<br>in using the segment library.<br><br>Ultimately, we need to look into replacing
the core raster I/O code. <br>However, this needs to be done incrementally; we can't afford to put<br>everything on hold while we re-write everything which uses<br>G_{get,put}_raster_row() etc (i.e. most of GRASS).<br><br>-- <br>Glynn Clements <glynn@gclements.plus.com><br><br><br><br>------------------------------<br><br>Message: 8<br>Date: Thu, 1 Mar 2007 17:56:32 +1300<br>From: Hamish <hamish_nospam@yahoo.com><br>Subject: Re: [GRASS-user] help with ogr2ogr and .shp file<br>To: antonio rodriguez <antonio.raju@gmail.com><br>Cc: grass list <grassuser@grass.itc.it><br>Message-ID: <20070301175632.2212ecdb.hamish_nospam@yahoo.com><br>Content-Type: text/plain; charset=US-ASCII<br><br>antonio rodriguez wrote:<br>> I need some help and advice to transform a .shp file to a format <br>> readable by GRASS.<br><br>from within your lat lon GRASS location:<br><br>v.in.ogr location=<br><br>to import the shape file and create a new location for it based on its<br>.prj
projection info. (assuming it has a .prj file. if not you'll have<br>to create the needed location manually and import using v.in.ogr from<br>within the new location)<br><br>> Extent: (100528.742188, 3991489.250000) - (610083.250000, 4288506.900918)<br>> Layer SRS WKT: (unknown)<br><br>Looks like you'll have to create a new location and set the projection<br>settings manually...<br><br><br>then (in the lat/lon location) suck it into the lat/lon projection with<br>v.proj.<br><br><br><br>Hamish<br><br><br><br>------------------------------<br><br>_______________________________________________<br>grassuser mailing list<br>grassuser@grass.itc.it<br>http://grass.itc.it/mailman/listinfo/grassuser<br><br><br>End of grassuser Digest, Vol 11, Issue
1<br>****************************************<br></grassuser@grass.itc.it></antonio.raju@gmail.com></hamish_nospam@yahoo.com></glynn@gclements.plus.com></hamish_nospam@yahoo.com></glynn@gclements.plus.com></grassuser@grass.itc.it></danaspatial@yahoo.com></grassuser@grass.itc.it></greenberg@ucdavis.edu></glynn@gclements.plus.com></grassuser@grass.itc.it></c.ehlschlaeger@insightbb.com></glynn@gclements.plus.com></hamish_nospam@yahoo.com></BAY121-F20D805DBDA00493E92B8C4A3800@phx.gbl></lindsaymico@hotmail.com></glynn@gclements.plus.com></soerengebbert@gmx.de></blockquote><br><BR><BR><div><strong>Pawan Joshi</strong> <br><font color="#ff80ff"><font color="#000000">0120-4314870</font> <br></font>G-5, Sector 20 <br>Noida </div> <div><br><font color="#ff40ff">"Do what you love @};- , Love what you do."</font><br></div><p> 
<hr size=1><a href="http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com">Bored stiff?</a> Loosen up...<br><a href="http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com">Download and play hundreds of games for free</a> on Yahoo! Games.