Re: [GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script
> Hamish writes:
> > FWIW all known bashisms were removed prior to GRASS 6.2.2.
...
> > Anything left needing bash explicitly uses #!/bin/bash
Ivan wrote:
> I. e., `i.spectral', `r.mapcalculator', `r.tileset' and
> `v.in.gps.babel'? Could someone please point me to the list of
> the identified Shell portability issues of these scripts?
$ grep -rI 'bin/bash' scripts/* | cut -f1 -d: | grep -v '/.svn/'
scripts/i.spectral/i.spectral
variable arrays are bash specific:
${COORD[$i]}
I am not sure if this is ok or not:
$( cat "$TMP1")
?
scripts/r.tileset/r.tileset: heavy use of variable arrays
scripts/v.in.gpsbabel/v.in.gpsbabel: not sure
maybe mentioned in the bashism threads in the archives?
ISTR that dash had an option to bulk test a script for bashisms.
(see the archives)
I don't know if it is worth the effort to worry about making those sh
compatible. Even on Ubuntu where !/bin/sh isn't Bash, Bash is still
there from the terminal prompt and if you request it in the shebang.
And we've had no complaints from embedded users.
v.in.gpsbabel and r.tileset should both be rewritten in another
language anyway (python) so spending lots of effort on the current
versions of them would be energy better spent somewhere else IMO.
what's wrong with r.mapcalculator?
> As an alternative, it may be that GRASS could benefit from a
> Shell (et al)... implemented in Python. It's all but an
> original idea. E. g., Emacs implements Eshell [1], though it
> may be noted that because of Emacs Lisp Emacs dependency on the
> Shell is much looser than that of GRASS.
>
> Besides, such a Shell would have a much wider field of
> applicability than just being the interactive shell for GRASS.
> I guess, that may make such a project to attract some interest
> from the general Python community.
I don't think we should get into the business of trying to reimplement
a full shell. Interesting idea about putting some tasty bait out into
the wider Python developer community.
See also GRASS's tcltk gronsole capability* & QGIS's python shell menu
item.
[*] try typing 'ls' and then click [Run], or 'xeyes' and then [Run
(bg)] in the lower panel of GIS.m's ouput window. I guess we could put
some text like "console:" above the lower frame.
Hamish
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 2D to 3D points
Benjamin Ducke wrote: > That should work but it may not exactly be easy to locate for a > novice user. > > How about a little wrapper script for v.transform that simplifies > this action? > > I am increasingly concerned about the number of, sometimes basic, > geoprocessing functions that are present in GRASS but "hidden" > in complex module options. Of course people can always mail to > this list but in the first place it will create frustration for > them and possible turn them away. So we make little wrapper scripts like v.dissolve and v.centroids. That's much better than dealing with code duplication. but that shouldn't wrap 3 module commands together with temporary maps etc to perform something as simple as the 2d+attr column -> 3d points conversion. If as Maciek suggests v.transform could do the job then it's not so bad. The v.transform name even sounds right for the job. Hamish Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] more on v.thematic.area
I had time to do another quick test on v.thematic.area. It works fine if you manually put in the break (i.e., as numbers separated by commas). However, it colors all areas by the second color in the list if you try to embed a v.class command into the breaks= argument. I'm doing this on a Mac OS X 10.4.11, using X11. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: What to call 3D
Can anybody please say what is the official name for GRASS 3d raster data, which should be used in the raster intro? So far I have found the following: $ cd /usr/local/grass-6.3.svn/docs/html$ $ grep -r -i "3d raster" . | wc -l 89 $ grep -r -i voxel . | wc -l 50 $grep -r -i g3d . | wc -l 46 $ grep -r -i GRID3D . | wc -l 17 $ grep -r -i "3d cell" . | wc -l 6 "3d cell" (which r3.info uses in it's output too BTW) seems kindoff strange - 3d rasters are supposed to be only FP data type, whereas in 2D raster GRASS lingo "CELL" designates the integer data type. we have used "3D raster is called GRID3D" (similarly as 2D integer raster is called CELL) in the GRASSbook, but we have used voxel in few places too (I am not sure whether that was good). g3d is historical and 3d cell sounds confusing - it could get mixed up with CELL. Helena In the element list actually used by GRASS ($GISBASE/etc/ element_list), it is "officially" listed as ... grid3:rast3d:raster3D:raster3D files Although "grid3d" is the "main_elemant" name, some combination of "raster" and "3D" (including rast3d and raster3D) seems the most common variant used as alias, description, and menu item. I'd suggest "3D raster" as a text version to standardize on. It's the most clearly understandable (IMHO). Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and GPGPU
On Saturday 01 March 2008, Helena Mitasova wrote: > Another popular task that has been implemented using GPU is > insolation, visibility and similar class of tasks, > so r.sun, r.los would be another candidate modules that could use > faster implementation. > > Helena I like the sound of r.sun done on the GPU-- that is a very time intensive operation, which could use a boost. Some starters: # overview presentation: http://www.cs.unm.edu/~angel/CS534/LECTURES/GPGPU2.pdf # some discussion 1. http://www.gpgpu.org/forums/index.php?sid=27fd91350f750179126570bde633f792 # open source tools 2. http://sourceforge.net/projects/gpgpu # an extension to C for stream processing: Brook 3. http://www.gpgpu.org/w/index.php/Brook 4. http://graphics.stanford.edu/projects/brookgpu/lang.html With some possible drawbacks from [3] : " However this discounts the important part of transferring the data to be processed to and from the GPU. With a PCI Express 1.0 x8 interface, the memory of an ATI HD 2900 XT can be written to at about 730Mb/sec and read from at about 311Mb/sec which is significantly slower than normal PC memory. For large datasets, this can greatly diminish the speed increase of using a GPU over a well tuned CPU implementation. Of course, as GPU's become faster far more quickly than CPU's and the PCI Express interface improves, it will make more sense to offload large processing to GPU's. " # another library: libSh -- appears to be a well-supported C++ library, and metalanguage: 5. http://libsh.org/ 6. http://libsh.org/wiki/index.php/Main_Page 7. http://libsh.org/wiki/index.php/Metaprogramming_GPUs_with_Sh 8. http://libsh.org/wiki/index.php/Sample_Code > On Mar 1, 2008, at 4:38 AM, Benjamin Ducke wrote: > > Yes, that is an excellent thought. I was considering this > > possibility for speeding up common interpolation, image > > transformation and > > resampling, as well. > > > > Kriging in realtime, anyone? ;) > > > > Of course, this would have to be implemented in a GPU-specific > > library. > > > > NVidia has the CUDA SDK, which is not open source at the moment, but > > the pressure is on: > > > > http://forums.nvidia.com/lofiversion/index.php?t28458.html > > > > ATI already seems to have their stuff (CTM) opened up. > > > > Maybe a proof-of-concept GPGPU module would make a nice little SoC > > project? > > > > Benjamin > > > > Dylan Beaudette wrote: > >> Has anyone considered the possibility of doing stream-based > >> calculations on the GPU [1] for raster operations on large > >> datasets ? 1. http://en.wikipedia.org/wiki/GPGPU > >> It appears that this method works best on highly vectorized > >> instructions, often in 2 "dimensions"-- appropriate for matrix/ > >> grid computations. > >> Just a thought. > >> Dylan > > > > -- > > Benjamin Ducke, M.A. > > Archäoinformatik > > (Archaeoinformation Science) > > Institut für Ur- und Frühgeschichte > > (Inst. of Prehistoric and Historic Archaeology) > > Christian-Albrechts-Universität zu Kiel > > Johanna-Mestorf-Straße 2-6 > > D 24098 Kiel > > Germany > > > > Tel.: ++49 (0)431 880-3378 / -3379 > > Fax : ++49 (0)431 880-7300 > > www.uni-kiel.de/ufg > > > > ___ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-dev > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 3
On Mar 1, 2008, at 1:54 PM, [EMAIL PROTECTED] wrote: Date: Sat, 1 Mar 2008 18:59:41 +0100 From: "Marco Pasetti" <[EMAIL PROTECTED]> Subject: [GRASS-dev] winGRASS RC5 Fails on Creating a New Projection To: "GRASS Developer Mailing List" Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi, From startpanel, define new location with epsg codes Used 4326 for WGS84 Returned the following message: g.proj returned the following informational message: child killed: SIGABRT Ahha, the SIGABRT problem. I have no idea what it means, but have encountered it before. What that has meant when I've run into it is that something wasn't installed right. If you try to drag-and-drop the contents of the compressed WinGRASS distribution file, sometimes something gets missed. I assume that it's some kind of hidden (to Windows) file, but don't know what it is. The result is kind of random SIGABRT errors. I suspect that it is a problem with some Windows unzip applications but not others, though it may be a function of Windows copy I suppose. My solution is to EXTRACT the files to C:/ instead of doing a drag- and-drop. Try it and see if this fixes your problem. It's kind of black magic and I wish I knew exactly what caused it. But the error is inscrutable, at least to me. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and GPGPU
Another popular task that has been implemented using GPU is insolation, visibility and similar class of tasks, so r.sun, r.los would be another candidate modules that could use faster implementation. Helena On Mar 1, 2008, at 4:38 AM, Benjamin Ducke wrote: Yes, that is an excellent thought. I was considering this possibility for speeding up common interpolation, image transformation and resampling, as well. Kriging in realtime, anyone? ;) Of course, this would have to be implemented in a GPU-specific library. NVidia has the CUDA SDK, which is not open source at the moment, but the pressure is on: http://forums.nvidia.com/lofiversion/index.php?t28458.html ATI already seems to have their stuff (CTM) opened up. Maybe a proof-of-concept GPGPU module would make a nice little SoC project? Benjamin Dylan Beaudette wrote: Has anyone considered the possibility of doing stream-based calculations on the GPU [1] for raster operations on large datasets ? 1. http://en.wikipedia.org/wiki/GPGPU It appears that this method works best on highly vectorized instructions, often in 2 "dimensions"-- appropriate for matrix/ grid computations. Just a thought. Dylan -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CELL/FCELL/DCELL [was: Re: r.mapcal rand() strangeness]
On Mar 1, 2008, at 5:18 PM, Maciej Sieczka wrote: Glynn Clements pisze: Maciej Sieczka wrote: I was going to add this information, but I'm not sure if I understand correctly that GRID3D is always floating point. Raster intro seems to suggest so, but r3.mapcalc suggests the opposite, eg.: "Note: If you calculate with integer numbers, the resulting map will be integer". Please tell me. I suspect that's probably an artifact of verbatim copying from the r.mapcalc documentation. I'm fairly sure that G3D only supports FP. Can you confirm if double precision only? I guess so by experiments with r3.mapcalc - eg.: $ r3.mapcalc 'map=float(1)' $ r3.info map -t datatype="double" Looking at the r3.mapcalc code, the only way that you can get CELL > values from a 3D grid is if you use the various # operators to perform > colour lookups. It still yields double for me: $ r3.mapcalc 'map_g=g#map' $ r3.info map_g -t datatype="double" ? Can anybody please say what is the official name for GRASS 3d raster data, which should be used in the raster intro? So far I have found the following: $ cd /usr/local/grass-6.3.svn/docs/html$ $ grep -r -i "3d raster" . | wc -l 89 $ grep -r -i voxel . | wc -l 50 $grep -r -i g3d . | wc -l 46 $ grep -r -i GRID3D . | wc -l 17 $ grep -r -i "3d cell" . | wc -l 6 "3d cell" (which r3.info uses in it's output too BTW) seems kindoff strange - 3d rasters are supposed to be only FP data type, whereas in 2D raster GRASS lingo "CELL" designates the integer data type. we have used "3D raster is called GRID3D" (similarly as 2D integer raster is called CELL) in the GRASSbook, but we have used voxel in few places too (I am not sure whether that was good). g3d is historical and 3d cell sounds confusing - it could get mixed up with CELL. Helena Maciek ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] CELL/FCELL/DCELL [was: Re: r.mapcal rand() strangeness]
Glynn Clements pisze: Maciej Sieczka wrote: I was going to add this information, but I'm not sure if I understand correctly that GRID3D is always floating point. Raster intro seems to suggest so, but r3.mapcalc suggests the opposite, eg.: "Note: If you calculate with integer numbers, the resulting map will be integer". Please tell me. I suspect that's probably an artifact of verbatim copying from the r.mapcalc documentation. I'm fairly sure that G3D only supports FP. Can you confirm if double precision only? I guess so by experiments with r3.mapcalc - eg.: $ r3.mapcalc 'map=float(1)' $ r3.info map -t datatype="double" Looking at the r3.mapcalc code, the only way that you can get CELL > values from a 3D grid is if you use the various # operators to perform > colour lookups. It still yields double for me: $ r3.mapcalc 'map_g=g#map' $ r3.info map_g -t datatype="double" ? Can anybody please say what is the official name for GRASS 3d raster data, which should be used in the raster intro? So far I have found the following: $ cd /usr/local/grass-6.3.svn/docs/html$ $ grep -r -i "3d raster" . | wc -l 89 $ grep -r -i voxel . | wc -l 50 $grep -r -i g3d . | wc -l 46 $ grep -r -i GRID3D . | wc -l 17 $ grep -r -i "3d cell" . | wc -l 6 "3d cell" (which r3.info uses in it's output too BTW) seems kindoff strange - 3d rasters are supposed to be only FP data type, whereas in 2D raster GRASS lingo "CELL" designates the integer data type. Maciek ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] New Binary Package Project for winGRASS
Hi Benjamin, >Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and can be distributed freely. Good question! When I planned the work I dind't considered this option, because on the wiki it was (it is) suggested to use ActiveTcl; Probably I should reconsider to build Tcl/Tk from source using MinGW, and then rebuild GRASS... Moritz, what do you think about? >Would also be interesting to know how >8.5 is working on Win. AFAIK there are some problems for GRASS with 8.5, I read it in the list in the last weeks. Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Benjamin Ducke Inviato: sabato 1 marzo 2008 21.45 Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS Marco Pasetti wrote: > > 1. because I added some extra-supports in GRASS (such as PostgreSQL, > SQLite and ActiveTcl), I could use Dependency Walker to securely check > what files are needed and then add them in ../bin dir, in order to > prepare a self contained package/installer, whitout the need of asking > the user to install other pieces of software; but, can I do that (I > mean about licenses, permissions, and so on...)? About PostgreSQL and > SQLite I rebuilt packages from source, while about ActiveTcl I used prebuit windows installer. Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and can be distributed freely. Would also be interesting to know how 8.5 is working on Win. > > 3. do we really need MSYS? Quantum GIS self installer still have MSYS > inside (only few files), whithout the need of installing it > separately. Can we do do the same? Yes, please. The sh interpreter is vastly superior to cmd.exe. -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: R: [GRASS-dev] New Binary Package Project for winGRASS
OK PS: Expat is for XML Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Benjamin Ducke Inviato: sabato 1 marzo 2008 21.40 Cc: 'GRASS Developer Mailing List' Oggetto: Re: R: R: [GRASS-dev] New Binary Package Project for winGRASS Marco Pasetti wrote: > Hi, > >> maybe it would be better, or at least to make note like "this package >> is > required for GRASS compilation", etc. > > Ok. I'll do that later, before to release the final version. > > What about GEOS, GSL and Expat? Actually, GRASS uses none of them, but > GDAL uses GEOS, I'm not sure if it uses GSL (even if I think not) and > it would Only QGIS uses GSL for the georeferencer plugin. > use Expat ...if I could be able to enable that support in GDAL :-) For what? > > So, summarizing, for the GRASS guide only, should I remove GSL, Expat > and GEOS or leave only GEOS? Only GEOS seems to make sense to me. Benjamin > > Marco > > -Messaggio originale- > Da: Martin Landa [mailto:[EMAIL PROTECTED] > Inviato: sabato 1 marzo 2008 14.44 > A: Marco Pasetti > Cc: GRASS Developer Mailing List > Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS > > Hi, > > 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: >> Related to this (the guide): what do you think about keeping GRASS + >> Quantum GIS building guide together? Actually some things (like >> expat, geos and gsl) are not needed by GRASS, but they are for QGIS. >> Should I prepare two different documents, one for GRASS only and one >> for both GRASS and QGIS > > maybe it would be better, or at least to make note like "this package > is required for GRASS compilation", etc. > > Martin > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa > * > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] testing v.thematic.area
I just tested v.thematic.area and v.class. There still seems to be a problem with the v.class breaks. I tried it with fields from Spearfish. I added a column named "area" with the area of each field. d.thematic.area [EMAIL PROTECTED] column=area breaks='v.class -g [EMAIL PROTECTED] column=area algo=int nbcla=5' colors='blue,red,green,yellow,grey' bwidth=0 bcolor=black render=l ...colors all fields with the 2nd color, whatever it is. But it will not use the other colors. I notice that there is a lot of overlap in the information needed for v.thematic,area and v.class. It would make this easier to use and much easier to use in the GUI if we could simple pick algorithm and nbcla within d.thematic.area instead of having to insert a v.class command with duplicate info. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New Binary Package Project for winGRASS
Marco Pasetti wrote: 1. because I added some extra-supports in GRASS (such as PostgreSQL, SQLite and ActiveTcl), I could use Dependency Walker to securely check what files are needed and then add them in ../bin dir, in order to prepare a self contained package/installer, whitout the need of asking the user to install other pieces of software; but, can I do that (I mean about licenses, permissions, and so on...)? About PostgreSQL and SQLite I rebuilt packages from source, while about ActiveTcl I used prebuit windows installer. Why use ActiveTcl? The regular, GPL'd Tcl compiles without any problems and can be distributed freely. Would also be interesting to know how 8.5 is working on Win. 3. do we really need MSYS? Quantum GIS self installer still have MSYS inside (only few files), whithout the need of installing it separately. Can we do do the same? Yes, please. The sh interpreter is vastly superior to cmd.exe. -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: R: [GRASS-dev] New Binary Package Project for winGRASS
Marco Pasetti wrote: Hi, maybe it would be better, or at least to make note like "this package is required for GRASS compilation", etc. Ok. I'll do that later, before to release the final version. What about GEOS, GSL and Expat? Actually, GRASS uses none of them, but GDAL uses GEOS, I'm not sure if it uses GSL (even if I think not) and it would Only QGIS uses GSL for the georeferencer plugin. use Expat ...if I could be able to enable that support in GDAL :-) For what? So, summarizing, for the GRASS guide only, should I remove GSL, Expat and GEOS or leave only GEOS? Only GEOS seems to make sense to me. Benjamin Marco -Messaggio originale- Da: Martin Landa [mailto:[EMAIL PROTECTED] Inviato: sabato 1 marzo 2008 14.44 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS Hi, 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: Related to this (the guide): what do you think about keeping GRASS + Quantum GIS building guide together? Actually some things (like expat, geos and gsl) are not needed by GRASS, but they are for QGIS. Should I prepare two different documents, one for GRASS only and one for both GRASS and QGIS maybe it would be better, or at least to make note like "this package is required for GRASS compilation", etc. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and GPGPU
On Saturday 01 March 2008, Benjamin Ducke wrote: > Yes, that is an excellent thought. I was considering this possibility > for speeding up common interpolation, image transformation and > resampling, as well. > > Kriging in realtime, anyone? ;) > > Of course, this would have to be implemented in a GPU-specific library. > > NVidia has the CUDA SDK, which is not open source at the moment, but > the pressure is on: > > http://forums.nvidia.com/lofiversion/index.php?t28458.html > > ATI already seems to have their stuff (CTM) opened up. > > Maybe a proof-of-concept GPGPU module would make a nice little SoC > project? Exactly-- that seems like an ideal candidate: cutting edge and exciting-- something that seems very fundable. Good idea! Dylan > Benjamin > > Dylan Beaudette wrote: > > Has anyone considered the possibility of doing stream-based calculations > > on the GPU [1] for raster operations on large datasets ? > > > > 1. http://en.wikipedia.org/wiki/GPGPU > > > > It appears that this method works best on highly vectorized instructions, > > often in 2 "dimensions"-- appropriate for matrix/grid computations. > > > > Just a thought. > > > > Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script
> Hamish <[EMAIL PROTECTED]> writes: >>> bashisms common in GRASS >> As Bash becomes somewhat less popular in the GNU world and being >> replaced by other POSIX-compatible Shells, it makes sense to get rid >> of bashisms irrespective of the platform. > FWIW all known bashisms were removed prior to GRASS 6.2.2. This is > mostly because Ubuntu now uses dash for /bin/sh and a lot of folks > use Ubuntu. Anything left needing bash explicitly uses #!/bin/bash I. e., `i.spectral', `r.mapcalculator', `r.tileset' and `v.in.gps.babel'? Could someone please point me to the list of the identified Shell portability issues of these scripts? > Michael has a point in that GRASS heavily relies on UNIX shell > scripts, which is ok for Mac (after fixing GNUisms) but not for MS > Windows. Msys, mingw, and cygwin exist but are in the end all just > different ways of putting lipstick on a pig. >> Well, I've heard of Python, but don't know it. > for some things it will be easier, for others not. e.g. for shell > command scripting nothing will ever be as good as sh, Well, for the Lisp family of the languages a syntax extension mechanism is an inherent feature. Thus, nothing really prevents a Lisp from deciphering something like the following: (like-a-shell (| (run "g.mlist" "type=rast" "pattern=2008-\\*-temperature") (for-each-line r (let ((s (concat r "-celsius"))) (run "r.mapcalc" "\"$s\" = \"$r\" - 273.15") Though even such a notation, resembling the Shell code rather closely, is hardly acceptable for an interactive use. (Except for ones using Emacs as their command line editor.) > but for more complex programming python will be better. It's just a > matter of choosing a compromise. e.g. for your g.mlist example sh is > hard to beat. But that's exactly my point -- Python is hardly an alternative for the 1.5-liners that you type into the Shell interactively. And depriving a GRASS user of a Shell does, in my opinion, seriously limit the usefulness of GRASS. Thus, while MSYS' or Cygwin's Shell (and the ``usual'' tools) may be somewhat difficult to deploy on W32, it seems to me just unavoidable to have them installed in order to do anything useful with GRASS. As an alternative, it may be that GRASS could benefit from a Shell (et al)... implemented in Python. It's all but an original idea. E. g., Emacs implements Eshell [1], though it may be noted that because of Emacs Lisp Emacs dependency on the Shell is much looser than that of GRASS. Besides, such a Shell would have a much wider field of applicability than just being the interactive shell for GRASS. I guess, that may make such a project to attract some interest from the general Python community. > But for something complex like r.in.wms or v.in.garmin, sh just isn't > the right tool for the job. > for a quick primer see: 10 minutes Python tutorial for programmers of > other languages http://www.poromenos.org/tutorials/python [1] http://www.gnu.org/software/emacs/manual/html_mono/eshell.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] winGRASS RC5 Fails on Creating a New Projection
Hi, >From startpanel, define new location with epsg codes Used 4326 for WGS84 Returned the following message: g.proj returned the following informational message: child killed: SIGABRT Why? Thanks Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] RE: [GRASS-user] r.watershed problems in wingrass
With an upgrade to RC5, I am able to use watershed now too. Jerry -Original Message- From: Moritz Lennert [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 6:20 AM To: Gerald Nelson Cc: 'Charles Ehlschlaeger'; [EMAIL PROTECTED]; grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] RE: [GRASS-user] r.watershed problems in wingrass On Mon, February 18, 2008 19:46, Gerald Nelson wrote: > I tried it without the @ sign with no success; ie, the same problems. > Where > I am getting success is if I use the disk for paging. I suspect some kind > of > memory management issue having to do with Windows. I'm copying this email > to > the dev list in case someone there has a fix. I cannot reproduce the problem. Could you try with the North Carolina demo data (you can get that from here: http://grass.itc.it/download/data.php) and see if you get the same problem, so that everyone can try to reproduce ? Also try to run with the '-m' flag, if memory seems to be the problem. Moritz > > Regards, > Jerry > -Original Message- > From: Charles Ehlschlaeger [mailto:[EMAIL PROTECTED] > Sent: Monday, February 18, 2008 12:10 PM > To: 'Gerald Nelson' > Subject: RE: [GRASS-user] r.watershed problems in wingrass > > I wrote r.watershed before GRASS allowed the use of @ symbols. (Or, if > GRASS > did, I didn't know about them then.) It is possible that something in the > init.c file is wrong. Does the problem still exist when you add > "india_basic" to the list of mapsets and run r.watershed without the > "@india_basic"? > Sincerely, chuck > > Chuck Ehlschlaeger, Geospatial Science Consultant > PERTAN GROUP, http://pertan.com/ > [EMAIL PROTECTED], 309-255-2727 > http://chuck.ehlschlaeger.info/ > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gerald Nelson > Sent: Sunday, February 17, 2008 5:11 PM > To: [EMAIL PROTECTED] > Subject: [GRASS-user] r.watershed problems in wingrass > > I'm using wingrass63RC4. I am trying to find watersheds in India. I run > > "r.watershed [EMAIL PROTECTED] threshold=100 > basin=IndiaBasins" > > The result after a couple of seconds is > > "category information for [IndiaBasins] in [india_basic] missing or > invalid" > > It's as if grass is trying to read the new map before it creates it. > > Jerry > Gerald Nelson > Professor, Dept. of Agricultural and Consumer Economics > University of Illinois, Urbana-Champaign > office: 217-333-6465 > cell: 217-390-7888 > 315 Mumford Hall > 1301 W. Gregory > Urbana, IL 61801 > ___ > grass-user mailing list > [EMAIL PROTECTED] > http://lists.osgeo.org/mailman/listinfo/grass-user > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 > 5:50 AM > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 > 5:50 AM > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] R: winGRASS-6.3.0RC5
>Yes, html man pages are all correctly created! But Firefox still reports the same message! Really strange! It's a firefox problem, setting MSIE as html browser it works! What a shame, I hate MSIE!!! -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Marco Pasetti Inviato: sabato 1 marzo 2008 18.22 A: 'Moritz Lennert' Cc: GRASS Developer Mailing List Oggetto: [GRASS-dev] R: winGRASS-6.3.0RC5 Hi, >> 3) Help (button) in module GUI fails; I try to translate Firefox >> message from italian: >> Firefox can't open this address because the (c) protocol is not >> associated with any application >Funny, I don't have this problem, even without GRASS_SH being set... >Are you sure that the html man pages have been created correctly ? Check $GISBASE/docs/html. Yes, html man pages are all correctly created! But Firefox still reports the same message! Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] R: winGRASS-6.3.0RC5
Hi, >> 3) Help (button) in module GUI fails; I try to translate Firefox >> message from italian: >> Firefox can't open this address because the (c) protocol is not >> associated with any application >Funny, I don't have this problem, even without GRASS_SH being set... Are you sure that the html man pages have been created correctly ? Check $GISBASE/docs/html. Yes, html man pages are all correctly created! But Firefox still reports the same message! Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)
Hi, 2008/3/1, Michael Barton <[EMAIL PROTECTED]>: [snip] > >> Ignoring geodetic distance for LL projections is simply ignorance > >> (on > >> my part here) of the equations needed to do it. It's easy to > >> determine if a location is LL. In that case, it should calculate > >> geodetic distance rather than (or perhaps in addition to) displaying > >> distance in map units. Just need to have the functions to do this > >> added to the measurement methods. > > > > why to code it in Python when it is already available in gislib? We > > should avoid code duplication. > > > Certainly. If a new version of d.measure or a hypothetical g.measure > could be created, we could use that. Until that happens, we'll need > to do it in Python (which is not all that bad). Is there anyway to > access gislib directly from Python? This could be an alternative to > creating a new module or changing an existing one. yes, via SWIG interface, see ./swig/python. Anyway the SWIG-Python interface for GRASS is a bit limited, need to be improved. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)
On Mar 1, 2008, at 8:41 AM, Martin Landa wrote: Hi, 2008/3/1, Michael Barton <[EMAIL PROTECTED]>: Well, my understanding of the direction of GRASS is that by v7, we'll lose all the interactive xterm-specific d.* modules. Interactive use will all be shifted to whatever GUI we design, rather than being hard- coded into a module. Simple, interactive measurement between 2 points on a display screen seems to me something to be handled by a GUI. d.measure will go away OR change to a module in which you enter a start and end point and it returns the distance between the points. In the latter case, it could then be 'plugged into' a GUI as a function to calculate distance between points interactively 'grabbed' by the GUI. In that case I would vote for `g.measure coords=` or something similar. Then this module could be used in GUI (not matter which one) or directly from CLI. Or in wxPython to use Python SWIG interface (need to be improved) to use gislib for distance calculation and similar. Ignoring geodetic distance for LL projections is simply ignorance (on my part here) of the equations needed to do it. It's easy to determine if a location is LL. In that case, it should calculate geodetic distance rather than (or perhaps in addition to) displaying distance in map units. Just need to have the functions to do this added to the measurement methods. why to code it in Python when it is already available in gislib? We should avoid code duplication. Certainly. If a new version of d.measure or a hypothetical g.measure could be created, we could use that. Until that happens, we'll need to do it in Python (which is not all that bad). Is there anyway to access gislib directly from Python? This could be an alternative to creating a new module or changing an existing one. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)
Hi, 2008/3/1, Michael Barton <[EMAIL PROTECTED]>: > Well, my understanding of the direction of GRASS is that by v7, we'll > lose all the interactive xterm-specific d.* modules. Interactive use > will all be shifted to whatever GUI we design, rather than being hard- > coded into a module. Simple, interactive measurement between 2 points > on a display screen seems to me something to be handled by a GUI. > > d.measure will go away OR change to a module in which you enter a > start and end point and it returns the distance between the points. > In the latter case, it could then be 'plugged into' a GUI as a > function to calculate distance between points interactively 'grabbed' > by the GUI. In that case I would vote for `g.measure coords=` or something similar. Then this module could be used in GUI (not matter which one) or directly from CLI. Or in wxPython to use Python SWIG interface (need to be improved) to use gislib for distance calculation and similar. > Ignoring geodetic distance for LL projections is simply ignorance (on > my part here) of the equations needed to do it. It's easy to > determine if a location is LL. In that case, it should calculate > geodetic distance rather than (or perhaps in addition to) displaying > distance in map units. Just need to have the functions to do this > added to the measurement methods. why to code it in Python when it is already available in gislib? We should avoid code duplication. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)
On Mar 1, 2008, at 1:47 AM, Martin Landa wrote: Micheal, 2008/3/1, Michael Barton <[EMAIL PROTECTED]>: 2008/2/29, Dylan Beaudette <[EMAIL PROTECTED]>: [snip] Thanks for the update. I don't regularly use either of the GUI and did not know about this feature. Does the patch that I submitted interfere with this functionality? I think that it would be useful to have this functionality in the old style monitors as well. d.measure is not used in wxGUI. Display windows are not registered as GRASS displays (d.mon -L) [TODO, not sure how to implemented], I think it would be good to use d.measure or something like g.measure in wxGUI too instead of using Python-based function for distance calculation (at least it would make sense for LL projections)? Please correct me if I am wrong. Michael, What's wrong with the Python one? duplication of the code, and in this particular case ignoring geodetic distance for LL projections. Well, my understanding of the direction of GRASS is that by v7, we'll lose all the interactive xterm-specific d.* modules. Interactive use will all be shifted to whatever GUI we design, rather than being hard- coded into a module. Simple, interactive measurement between 2 points on a display screen seems to me something to be handled by a GUI. d.measure will go away OR change to a module in which you enter a start and end point and it returns the distance between the points. In the latter case, it could then be 'plugged into' a GUI as a function to calculate distance between points interactively 'grabbed' by the GUI. Ignoring geodetic distance for LL projections is simply ignorance (on my part here) of the equations needed to do it. It's easy to determine if a location is LL. In that case, it should calculate geodetic distance rather than (or perhaps in addition to) displaying distance in map units. Just need to have the functions to do this added to the measurement methods. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: R: [GRASS-dev] New Binary Package Project for winGRASS
Hi, >maybe it would be better, or at least to make note like "this package is required for GRASS compilation", etc. Ok. I'll do that later, before to release the final version. What about GEOS, GSL and Expat? Actually, GRASS uses none of them, but GDAL uses GEOS, I'm not sure if it uses GSL (even if I think not) and it would use Expat ...if I could be able to enable that support in GDAL :-) So, summarizing, for the GRASS guide only, should I remove GSL, Expat and GEOS or leave only GEOS? Marco -Messaggio originale- Da: Martin Landa [mailto:[EMAIL PROTECTED] Inviato: sabato 1 marzo 2008 14.44 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: R: [GRASS-dev] New Binary Package Project for winGRASS Hi, 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: > Related to this (the guide): what do you think about keeping GRASS + > Quantum GIS building guide together? Actually some things (like > expat, geos and gsl) are not needed by GRASS, but they are for QGIS. > Should I prepare two different documents, one for GRASS only and one > for both GRASS and QGIS maybe it would be better, or at least to make note like "this package is required for GRASS compilation", etc. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: R: [GRASS-dev] New Binary Package Project for winGRASS
Hi, 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: > Related to this (the guide): what do you think about keeping GRASS + Quantum > GIS building guide together? Actually some things (like expat, geos and gsl) > are not needed by GRASS, but they are for QGIS. Should I prepare two > different documents, one for GRASS only and one for both GRASS and QGIS maybe it would be better, or at least to make note like "this package is required for GRASS compilation", etc. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
R: [GRASS-dev] New Binary Package Project for winGRASS
Hi Martin, Be careful with the guide, it's still a WIP: refresh it regularly, updates are on the road... (even if I think that GRASS section is almost complete) Related to this (the guide): what do you think about keeping GRASS + Quantum GIS building guide together? Actually some things (like expat, geos and gsl) are not needed by GRASS, but they are for QGIS. Should I prepare two different documents, one for GRASS only and one for both GRASS and QGIS (since I actually don't see great utility of using QGIS without GRASS plugin, which is instead a great feature of QGIS, specially for not advanced users)? PS: thanks for the "great" ;-) -Messaggio originale- Da: Martin Landa [mailto:[EMAIL PROTECTED] Inviato: sabato 1 marzo 2008 14.00 A: Marco Pasetti Cc: GRASS Developer Mailing List Oggetto: Re: [GRASS-dev] New Binary Package Project for winGRASS Ciao Marco, 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: [snip] > 2. since the new wxPython GUI still doesn't work on windows (for > RC05, I'll check on trunk in the next days), I think that we can > avoid to include it in the RC05 package as requirement; why tell the > user to install Python and wxPython if the new GUI doesn't work? right now I am following your great installation guide, then I will try to make wxGUI working on Windows too (basic features for now). Without functional wxGUI doesn't make sense to require at least wxPython, Python maybe because of SWIG interface. [snip] Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New Binary Package Project for winGRASS
Ciao Marco, 2008/3/1, Marco Pasetti <[EMAIL PROTECTED]>: [snip] > 2. since the new wxPython GUI still doesn't work on windows (for RC05, I'll > check on trunk in the next days), I think that we can avoid to include it in > the RC05 package as requirement; why tell the user to install Python and > wxPython if the new GUI doesn't work? right now I am following your great installation guide, then I will try to make wxGUI working on Windows too (basic features for now). Without functional wxGUI doesn't make sense to require at least wxPython, Python maybe because of SWIG interface. [snip] Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New Binary Package Project for winGRASS
Hi, I decided to change the subject of the mail to a better one, and then to send the mail to the list, as I should have done before (sorry for the mistake). Let we start from this: >I think that if you could provide the binary package plus a directory which contains all the source tarballs you used >and your compilation information, this would be perfect. If you rather have me host these files, I can do so as well. >If you can, then that's perfect and I "officially" pass on the responsibility for maintaining the windows binary packages (cc to Markus for info). >I will obviously continue to help you and try to debug whenever possible. I have started to add some ToDo's on the Wingrass Status wiki page. >This is probably the best place to keep track of what still needs to be done. >So, as soon as your package of libraries (and header files) is ready, could you let me know where I can get it, >so that I can adapt my build system to that ? I'm very excited about that, that is officially contribute to a such important family ;-) ...but it's the first time for me (I mean about software releasing and all things related), so I guess that I need to learn some things before... That's my questions: For an user-oriented self installer: 1. because I added some extra-supports in GRASS (such as PostgreSQL, SQLite and ActiveTcl), I could use Dependency Walker to securely check what files are needed and then add them in ../bin dir, in order to prepare a self contained package/installer, whitout the need of asking the user to install other pieces of software; but, can I do that (I mean about licenses, permissions, and so on...)? About PostgreSQL and SQLite I rebuilt packages from source, while about ActiveTcl I used prebuit windows installer. 2. since the new wxPython GUI still doesn't work on windows (for RC05, I'll check on trunk in the next days), I think that we can avoid to include it in the RC05 package as requirement; why tell the user to install Python and wxPython if the new GUI doesn't work? 3. do we really need MSYS? Quantum GIS self installer still have MSYS inside (only few files), whithout the need of installing it separately. Can we do do the same? For development-oriented package: I thought about the following options: 1. pack all the MSYS "local" folder, excluding sources; all the applications and libraries included has been built by source with MSYS/MinGW, excluding Flex and Bison, for which I used prebuilt binaries packages from sourceforge GNUWin32 Project; 2. pack all the MSYS "local" folder, including sources for all the libraries/applications built; 3. pack all the MSYS environment, including MinGW installation, "local" folder and sources; actually, I think that both MSYS and MinGW don't need to be installed from related installers, you can just copy all the MSYS folder to your local hard drive. While for the compilation information i could: 1. add a pdf print of the html guide 2. add a simple text (txt) copy of the html guide >Sounds perfect. You can put the link here: >http://grass.gdf-hannover.de/wiki/Compile_and_Install#MS-Windows.2Fnative >and we could erase this part >http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#Compiling_by_your self >and just link to the previous wiki page. So I'll need to subscribe, log-in, delete previous entries and the simply add a "... see here for instructions" link? Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 2D to 3D points
That should work but it may not exactly be easy to locate for a novice user. How about a little wrapper script for v.transform that simplifies this action? I am increasingly concerned about the number of, sometimes basic, geoprocessing functions that are present in GRASS but "hidden" in complex module options. Of course people can always mail to this list but in the first place it will create frustration for them and possible turn them away. Benjamin Maciej Sieczka wrote: Michael Barton pisze: It doesn't seem to. I think it makes columns from the points. If the input is a 3d point it makes a vertical 3d line out of it (the lines's 2d length = 0, 3d length = 0 + input 3d point's z). As the manual says. It takes 2 additional commnads to extract the top node: v.extrude input=pt output=pt3d_ln hcolumn=wys type=point layer=1 v.to.points -n input=pt3d_ln output=pt3d_pt type=line llayer=1 v.extract input=pts3d_pt output=pts3d_pt_top type=point layer=2 new=-1 where="along>0" For tranforming 2d points into 3d directly there is v.transform I guess, using 'table' and 'columns' option. Maciek ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and GPGPU
Yes, that is an excellent thought. I was considering this possibility for speeding up common interpolation, image transformation and resampling, as well. Kriging in realtime, anyone? ;) Of course, this would have to be implemented in a GPU-specific library. NVidia has the CUDA SDK, which is not open source at the moment, but the pressure is on: http://forums.nvidia.com/lofiversion/index.php?t28458.html ATI already seems to have their stuff (CTM) opened up. Maybe a proof-of-concept GPGPU module would make a nice little SoC project? Benjamin Dylan Beaudette wrote: Has anyone considered the possibility of doing stream-based calculations on the GPU [1] for raster operations on large datasets ? 1. http://en.wikipedia.org/wiki/GPGPU It appears that this method works best on highly vectorized instructions, often in 2 "dimensions"-- appropriate for matrix/grid computations. Just a thought. Dylan -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
