Re: [GRASS-user] disappearing d.mon
This has now been fixed in the Arch Linux repos (package 'wxgtk3 3.0.5.1'). I can finally use 'd.mon' again. What a relief! Thanks, everybody, for chasing this one down! Best, Ben On 16/05/2021 01:29, Dave Roberts wrote: Thanks Markus! I'll push this along. On 5/15/21 3:01 PM, Markus Neteler wrote: Dave, Ben, Thanks to Anna and Tomas I now remember that the same happened in Fedora as well (last year). It seems that Arch/Manjaro are still missing this upstream fix for wxPseudoDC.FindObjects crash: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FwxWidgets%2FPhoenix%2Fpull%2F1849data=04%7C01%7Cdroberts%40montana.edu%7C0414fc5be7c743f8e1a508d917e49a10%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637567093344262380%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=c9XBx4ParX5kgjTPR%2FfqA19n1%2BNPp281L0UTHsiy7vA%3Dreserved=0 (in Fedora, it had been backported in https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsrc.fedoraproject.org%2Frpms%2Fpython-wxpython4%2Fc%2Ff5471fb86aaae46a686b85c654fcbb98516355e6%3Fbranch%3Drawhidedata=04%7C01%7Cdroberts%40montana.edu%7C0414fc5be7c743f8e1a508d917e49a10%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637567093344262380%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oZDugXEeBXWfKiubiktVxu4Vlr074%2FAdA0ii3AyXQmI%3Dreserved=0) Hence it is not directly a GRASS GIS problem but has to be fixed in wxWidgets. Please contact the maintainer of Arch/Manjaro wxWidgets to patch it accordingly and release an update (such as Fedora has done). Best, Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] disappearing d.mon
On 12/05/2021 13:30, Dave Roberts wrote: Colleagues, Finally, after probably a year I now have no errors about incompatible versions of wxwidgets, wxpython, and GRASS. However, when I execute d.mon wx0 it pops up the box, but which then spontaneously disappears after about 10-15 seconds. It leaves behind the MONITORS/wx0 file. Honestly I'm pretty much at my wits end with wxwidgets. I run manjaro(arch) linux with the the custom build by Sylvain Poulain at https://github.com/giscan/AUR-grass uname -a Linux sonnyboy 5.4.116-1-MANJARO #1 SMP PREEMPT Sun May 2 11:10:35 UTC 2021 x86_64 GNU/Linux Thanks in advance for any help, Dave Same here: - Arch Linux - grass 7.8.5 - GTK 3.24.29 - wxGTK2/3 3.0.5 - system Python 3.9.4 After a 'd.mon start=wxN', the monitor comes up, I can use 'd.*' commands to draw into it. I can resize and move the window, and I can interact with the UI elements in the icon and status bars. However: When I move the mouse cursor inside the monitor's map canvas, d.mon crashes and closes its window (after a delay of a few seconds). I can then use 'd.mon stop=wxN' and start the monitor again, with the same behaviour as above. Best, Ben ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] How to user "solver=" option of r.cost/r.walk
Dear Grass Users --
I am struggling to understand the usage of the
"solver=" option featured by both r.cost and
r.walk.
The r.walk manual page gives no details about it.
The r.cost manual page does contain an illustration
of the working principle, but no examples on how
to quantify the cells in the solver map. So it's
all a little too abstract for me.
I understand the basic premise: I have a relatively
coarse cost map, and r.cost's algorithm will often
encounter cells with many neighbours that have the
same cost. This produces ugly quantization effects
("steps") in least cost paths derived from such
surfaces. To work around this problem, I have so
far simply added some random noise to my cost
maps. However, it seems to me that the "solver="
option might be a more elegant, deterministic
solution to this problem.
So: Does anybody here have some experience with
the "solver=" option of r.cost? What kind of
values (ranges?) would a solver map contain?
How does r.cost interpret theses values (as
additional costs?). Could anyone come up with
an example of how to quantify a useful solver
map in practice?
Thanks!
Ben
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using V VOL RST -Zscale for anisotropy
Salut Francois, Have you tried setting "zscale" to a value smaller than "1"? E.g. "0.5" should give half as much weight to distances along the Z axis (which is equivalent to giving twice as much weight to X-Y distances). Best, Ben On 30/03/2019 20:16, Francois Chartier wrote: > Hi, > > I would like to know how zscale can be used to model anisotropy with > V.VOL.RST. see attached image view 3d raster in paraview (showing 2 > intersecting slices). > > I am modeling soil texture and would like to give more weight > horizontally than vertically. > > thanks, > Francois > > > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Anisotropy
On 16/03/2019 21:24, Francois Chartier wrote: > I thought Zscale was used to convert units ft to m, i didnt know it was > for giving more weight to one direction. That's only one application case. The manual page goes on: 'Rescaling of z-coordinates (zscale) is also needed when the distances in vertical direction are much smaller than the horizontal distances ..' That is equivalent to what you are looking for: instead of assuming that a process works slower or faster in the Z direction (anisotropy), you could also assume the speed is the same but the Z distance is shorter/longer, no? If I understand the manual page correctly, then 'zscale' only rescales Z values during interpolation, but the original coordinates are preserved in the voxel output. Why not just experiment and check if it produces a useful result? Cheers, Ben > > Le sam. 16 mars 2019 à 15:20, Benjamin Ducke <mailto:bendu...@fastmail.fm>> a écrit : > > On 16/03/2019 19:51, Francois Chartier wrote: > > Hi, > > > > Is it possible to add anisotropy when conducting interpolation for 3D > > raster. I would like to give more weight horizontally than vertically > > in the 3D interpolation process. > > 'v.vol.rst' has an option 'zscale'. > Is that not what you are looking for? > > Best, > > Benjamin > > > > > thanks, > > > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > > https://lists.osgeo.org/mailman/listinfo/grass-user > > > > > > -- > Dr. Benjamin Ducke > Deutsches Archäologisches Institut (DAI) > Zentrale Berlin, IT-Referat > > ___ > grass-user mailing list > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/grass-user > -- Dr. Benjamin Ducke Deutsches Archäologisches Institut (DAI) Zentrale Berlin, IT-Referat ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Anisotropy
On 16/03/2019 19:51, Francois Chartier wrote: > Hi, > > Is it possible to add anisotropy when conducting interpolation for 3D > raster. I would like to give more weight horizontally than vertically > in the 3D interpolation process. 'v.vol.rst' has an option 'zscale'. Is that not what you are looking for? Best, Benjamin > > thanks, > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > -- Dr. Benjamin Ducke Deutsches Archäologisches Institut (DAI) Zentrale Berlin, IT-Referat ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] V.Kriging
On 12/01/2019 17:57, Rich Shepard wrote: > On Sat, 12 Jan 2019, Francois Chartier wrote: > >> Is the module v.kriging still available in grass gis? Here is the error >> message I obtain trying to run v.kriging. I also did not find it in the >> drop drown menus. > > Francois, > > Yep. Works for me using 7.7.svn (r73895) on Slackware-14.2. > >> Secondly, is v.kriging able to generate a 3D raster based on 3D data >> points+attribute as v.vol.rst is capable? > > This I don't know. According to the manual page, v.kriging does handle 3D input explicitly[1]: "method ordinary kriging extended to 3D" To this end, it even supports variograms for 3D data (flags '-b' and 'u'), and you can use both 3D points or a Z attribute as input. I have not tried 3D kriging myself, but I would be extremely interested to hear back from anyone an this list how well this performs! Best, Ben [1] https://grass.osgeo.org/grass74/manuals/addons/v.kriging.html > > Regards, > > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user -- Dr. Benjamin Ducke Deutsches Archäologisches Institut (DAI) Zentrale Berlin, IT-Referat * Projekt "Stunde Null" * ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Result of v.hull into solid 3D polygon with volume
Hi Vil,
at the time 3D support was added to v.hull, the new
3D vector API for GRASS had just been released, and
there was some uncertainty about the role of the
new geometry type "volume". Back then, there was
hardly any GRASS module that could do anything useful
with that type. Has that changed by now? If "volume"
is a usable type, then it should not be too difficult
to add a flag to produce a volume as output.
The function that would need to be modified is:
vector/v.hull/chull.c: void writeVertices(*Map)
In any case, in hindsight it looks weird now that
v.hull produces 3D faces plus a "kernel".
Maybe it would make more sense to output either
only 3D faces OR a volume plus a kernel?
In addition: For the next release, it would make
sense to rename this volume to v.hull.convex,
seeing that there is also v.hull.concave.
Best,
Ben
On 15/02/18 19:09, Vilem Ded wrote:
> Hi,
> I wonder if the 3D result of "v.hull" function can be converted into
> object of type "volume"?
> Right now it is giving me just faces of the 3D polygon and 1 kernel.
> Which is according to specifications ("The 3D hull will be composed of
> triangular faces. ")
>
> Moreover I wanted to import this object into PostGIS as one 3D spatial
> polygon and make it solid (i need to compute volume and overlay with
> points), but of course it was imported as bunch of 3D polygons
> represinting those faces. And making 3D solid polygon (ST_MakeSolid?) in
> PostGIS is probably question for another mailing list.
>
> Thank you
> Vil
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
--
Dr. Benjamin Ducke
Deutsches Archäologisches Institut (DAI)
Zentrale Berlin, IT-Referat
* Projekt "Stunde Null" *
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] creating high-resolution DMT
On 15/04/17 05:31, Vaclav Petras wrote:
> Back to filling holes in lidar data, I also think that the "fill in the
> gaps" approach is quite promising, so I ported the r.fill.gaps module to G7:
Great! I have read the diff and that was very
helpful for me. I can see that the old and
new raster APIs have only minimal differences.
Porting seems very straight-forward.
I hope that r.fill.gaps will be useful for others.
I did not have LiDAR in mind when I wrote it,
but now it seems so obvious that LiDAR processing
is an important domain of application for the module.
Cheers!
Ben
>
> https://grass.osgeo.org/grass72/manuals/addons/r.fill.gaps.html
>
> I didn't review the code, but the documentation is very nice and
> detailed. I did some mostly formatting updates for the current
> submitting guidelines and added complete example with lidar data.
>
> On Tue, Mar 21, 2017 at 7:29 AM, Benjamin Ducke <bendu...@fastmail.fm
> <mailto:bendu...@fastmail.fm>> wrote:
>
>
> I just realized that I have never committed "r.fill.gaps"
> to the add-ins repo.
>
>
> Really nice module, please, find more of these in your shelf :-)
>
> Thanks!
> Vaclav
>
>
>
> I have just done that now:
>
> http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.fill.gaps
> <http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.fill.gaps>
>
> Its purpose is filling small gaps in otherwise dense
> data using IDW with a pre-computed weights matrix.
> It works on rasterized data, so you simply use v.to.rast
> on your vector points first. Make sure to set the
> cell size small enough so that you don't get many
> vector points falling into the same cell. The result
> will be an oversampled raster with a lot of small
> "no data" cells. That's exactly the intended input for
> r.fill.gaps!
>
> This is not multi-core code, (parallelizing
> interpolation algorithms is hard, because you need to
> segment the data and then you need to deal with the
> seams between the segments), but it is very, very fast,
> as long as you keep the IDW radius small.
>
> The code is optimized to death, which makes it very
> hard to read. Another drawback is that it was written
> for GRASS 6 (but converting it to GRASS 7 should not
> be hard, since it uses only the basic raster API).
>
> r.fill.gaps is not useful for filling large gaps, both
> in terms of performance (for large IDW radii) and
> interpolation quality (it's IDW -- enough said).
>
>
>
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] creating high-resolution DMT
On 21/03/17 10:12, Blumentrath, Stefan wrote:
> Hei Martin,
>
> Same experience here. For larger datasets from LiDAR I rather use IDW
> for interpolation.
I just realized that I have never committed "r.fill.gaps"
to the add-ins repo.
I have just done that now:
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.fill.gaps
Its purpose is filling small gaps in otherwise dense
data using IDW with a pre-computed weights matrix.
It works on rasterized data, so you simply use v.to.rast
on your vector points first. Make sure to set the
cell size small enough so that you don't get many
vector points falling into the same cell. The result
will be an oversampled raster with a lot of small
"no data" cells. That's exactly the intended input for
r.fill.gaps!
This is not multi-core code, (parallelizing
interpolation algorithms is hard, because you need to
segment the data and then you need to deal with the
seams between the segments), but it is very, very fast,
as long as you keep the IDW radius small.
The code is optimized to death, which makes it very
hard to read. Another drawback is that it was written
for GRASS 6 (but converting it to GRASS 7 should not
be hard, since it uses only the basic raster API).
r.fill.gaps is not useful for filling large gaps, both
in terms of performance (for large IDW radii) and
interpolation quality (it's IDW -- enough said).
Best,
Ben
>
> The "per hole filling" in r.fillnulls is not utilizing multiple cores
> and if you have a lot of holes that can slow down the whole process
> significantly. Not sure if a mask can help to avoid filling no data
> areas around your data.
>
> For r.fillnulls there is an enhancement ticket (with a patch) for
> speedup of the patching of the maps at the end...
> https://trac.osgeo.org/grass/ticket/1938 However, it does not tackle
> parallel filling of holes...
>
> Cheers Stefan
>
> ___ grass-user mailing
> list grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Orthorectification of tilted digital camera images
On Mon, Aug 17, 2015, at 08:43, Blumentrath, Stefan wrote: Hi Markus, Florian, and others, Thanks for your replies. I still did not solve this, so I am grateful for any hint. Could you maybe apply a two-stage process where you first correct (at least partially) the perspective distortion and then do an orthorectification on the result? I don't think that the GRASS georeferencer has a perspective/projective transform, but QGIS does. (In case anyone wants to implement the projective transform in GRASS: I have made a plain C translation of the QGIS algorithm available here: https://svn.code.sf.net/p/gvsigce/code/trunk/libraries/libCTL/ -- requires GNU Scienfic Library for the matrix algebra.) Best, Ben Now, I extracted the relevant data (XY-location containing the mapset (“reconyx”) with the image group (containing i.ortho.photo files), and camera file as well as the target location (“ETRS_32N”) with the “target” mapset containing the DEM (“dem_1m”) and two of my attempts for orthorectification (with and without INIT file active). You can fetch the zip-file with the GRASS DB (22 MB) within the next 30 days from: https://www.dropbox.com/sh/swri19zn5m9gb7w/AACADlkqGZKO_JMS_YbLNXBXa?dl=0 There you will also find the original image (“IMG_0015.jpg”) as it comes from the camera. As a next step I will take another test image with a more orthophoto-like perspective and no visible sky. I hope, that way I can check whether the issue is due to the chosen camera position / angle or the way I defined the exposure in the INIT file… I have a strong feeling that my problems - in one or the other way - have to do with camera angles… Unfortunately, it does not seem to be possible to specify only the exposure parameters one is sure about. i.photo.rectify uses either all or nothing to initialize the orthorectification algorithm… Cheers Stefan From: grass-user-boun...@lists.osgeo.org [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Florian Mueller Sent: 15. august 2015 20:54 To: grass-user grass-user (grass-user@lists.osgeo.org) Subject: Re: [GRASS-user] Orthorectification of tilted digital camera images Dear Stefan, Can you provide some example photos in a Dropbox (e.g.) folder? Best regards, Florian On Sat, Aug 15, 2015 at 7:53 PM, Markus Neteler nete...@osgeo.orgmailto:nete...@osgeo.org wrote: On Tue, Aug 11, 2015 at 11:37 PM, Blumentrath, Stefan stefan.blumentr...@nina.nomailto:stefan.blumentr...@nina.no wrote: Dear all, Although there is a lot of relevant information regarding the orthorectification of tilted digital camera images in GRASS GIS online (here: ... Does up-slope direction of the photo or sky in the photo conflict with the orthorectification algorithm? I have no idea... in general the algorithm is very robust but was really written for aerial photos. When it comes to the GCPs I am in principle quite confident that they are placed OK. Or do you think that GCPs measured by a hand held GPS are too imprecise? They should be fine. However, depending on initial camera settings RMS something like 268, which indicates that something is wrong here. If I do not use i.photo.init, the image is placed much better (RMS around 10-20), but still pretty poor… About 10 years have passed that I tried the last time, memory is fading... Did you figure it out? ... Btw: Some of the submodules of i.ortho.photo are not linked to the /bin folder in GRASS 6.4.5svn, so I have to start them like this: /usr/local/grass-6.4.5svn/etc/i.photo.init To my knowledge they are intentionally hidden in order to be run from the i.ortho.photo main menu (in GRASS GIS 6). Markus ___ grass-user mailing list grass-user@lists.osgeo.orgmailto: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] Copy raster map from one unprojected location to another
On Thu, Mar 19, 2015, at 11:25, Roy wrote: Hi, Il 19/03/2015 11:04, Johannes Radinger ha scritto: Of course, I could export the map to geotiff and import them in the other location; IMHO this is the simpler way, Bad idea. You will lose all associated metadata: colour table, categories, editing history, maybe even the correct cell stats and no data code. GRASS raster maps are sets of files that are unfortunately a little spread out over several subdirectories in the mapset directory. To copy the entire collection of files that constitutes a GRASS raster map from one place to another, use: http://grass.osgeo.org/grass64/manuals/r.pack.html and the associated r.unpack. Best, Ben Roy. ___ 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] g.extension gives an error when installing r.prominence
Thayer,
On Tue, Jan 6, 2015 at 7:35 PM, Thayer Young thaye...@yahoo.com
mailto:thaye...@yahoo.com wrote:
When I try to install the r.prominence extension I get the following
error:
g.extension.py -i extension=r.prominence
svnurl=http://svn.osgeo.org/grass/grass-addons/grass6
WARNING: GRASS_ADDON_PATH has more items, using first defined -
'/Users/thayer/Library/GRASS/6.4/Modules/bin'
...
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v
to see invocation)
...
ERROR: Compilation failed, sorry. Please check above error messages.
Which version of Mac OS X are you on?
I recall having a similar problem, related to gettext,
with OS 10.9.
In my case, this solved the problem (requires an
Internet connection):
1. Go to http://brew.sh/ and install brew, then:
2. in the Terminal, issue:
brew install gettext
3. Try compiling again.
Best,
Ben
On Wed, Jan 7, 2015 at 10:37 PM, Thayer Young thaye...@yahoo.com
mailto:thaye...@yahoo.com wrote:
I am on Mac OS 10.10. From the About GRASS GIS window:
GRASS GIS 6.4.5svn, SVN Revision 61583M, GIS Library Revision 50937
(2012-02-25), Python: 2.7.6, wxPython: 2.8.12.1
I installed it using the Michael Barton snapshot , but I installed it
using
the Kyng Chaos frameworks (I tried both GUIs and went with the Barton
version).
I see. So I add Michael in CC, perhaps he remembers the solution since
a similar issue was discussed last year:
http://lists.osgeo.org/pipermail/grass-dev/2014-April/068136.html
(and related messages).
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass-user Digest, Vol 105, Issue 9
The problem is that the linker does not find
lintl. Search your file system to see
if and where you have a copy of libintl.dylib.
If it exists somewhere, then you need to tell
the linker where it is. E.g. if you find it
in /usr/local/lib, then add that path to
the linker search path:
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib
... before invoking g.extension.
Solving this linker issue will probably get you there
faster than trying to set up a complete environment
for compiling GRASS modules.
Cheers,
Ben
On 08/01/15 16:33, Thayer Young wrote:
Ben,
Thanks for your response. Unfortunately, I already have both Homebrew
and gettext installed. I am still unable to install r.prominence or
r.findtheriver.
I will try reading the Notes on GRASS Programming in Opensource GIS
and see if I can compile it using Eclipse.
-Thayer
Date: Thu, 08 Jan 2015 15:34:21 +0100
From: Benjamin Ducke bendu...@fastmail.fm mailto:bendu...@fastmail.fm
To: grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] g.extension gives an error when installing
r.prominence
Message-ID: 54ae956d.8080...@fastmail.fm
mailto:54ae956d.8080...@fastmail.fm
Content-Type: text/plain; charset=windows-1252
Thayer,
On Tue, Jan 6, 2015 at 7:35 PM, Thayer Young thaye...@yahoo.com
mailto:thaye...@yahoo.com
mailto:thaye...@yahoo.com mailto:thaye...@yahoo.com wrote:
When I try to install the r.prominence extension I get the following
error:
g.extension.py -i extension=r.prominence
svnurl=http://svn.osgeo.org/grass/grass-addons/grass6
WARNING: GRASS_ADDON_PATH has more items, using first defined -
'/Users/thayer/Library/GRASS/6.4/Modules/bin'
...
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v
to see invocation)
...
ERROR: Compilation failed, sorry. Please check above error messages.
Which version of Mac OS X are you on?
I recall having a similar problem, related to gettext,
with OS 10.9.
In my case, this solved the problem (requires an
Internet connection):
1. Go to http://brew.sh/ http://brew.sh/and install brew, then:
2. in the Terminal, issue:
brew install gettext
3. Try compiling again.
Best,
Ben
On Wed, Jan 7, 2015 at 10:37 PM, Thayer Young thaye...@yahoo.com
mailto:thaye...@yahoo.com
mailto:thaye...@yahoo.com mailto:thaye...@yahoo.com wrote:
I am on Mac OS 10.10. From the About GRASS GIS window:
GRASS GIS 6.4.5svn, SVN Revision 61583M, GIS Library Revision 50937
(2012-02-25), Python: 2.7.6, wxPython: 2.8.12.1
I installed it using the Michael Barton snapshot , but I installed it
using
the Kyng Chaos frameworks (I tried both GUIs and went with the Barton
version).
I see. So I add Michael in CC, perhaps he remembers the solution since
a similar issue was discussed last year:
http://lists.osgeo.org/pipermail/grass-dev/2014-April/068136.html
(and related messages).
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
http://gvsigce.org/
--
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems with r.mapcalc
)
|
| Timestamp: none
|
||
|
|
| Type of Map: raster Number of Categories: 0
|
| Data Type:DCELL
|
| Rows: 4409
|
| Columns: 7499
|
| Total Cells: 33063091
|
|Projection: Latitud - Longitud.
|
|N: 19:54:02.16SS: 30:01:58.200271S Res:
0:00:08.273087|
|E: 63:35:44.521118WW: 80:49:44.4W Res:
0:00:08.273087 |
| Range of data:min = -9254.65838509317 max = 9247.07852234276
|
|
|
| Data Description:
|
|generated by r.mapcalc
|
|
|
| Comments:
|
|(NIR_reflectance_1_h11v11 - MIR_reflectance_1_h11v11) /
|
|(NIR_reflectance_1_h11v11 + MIR_reflectance_1_h11v11) * 1
|
|
|
++
r.mapcalc --o expression=bla=NDVI_1_h11v11 - NDWI_1_h11v11
GRASS 7.1.svn (sequia):/opt/grass_trunk/bin.x86_64-unknown-linux-gnu
r.info http://r.info bla
++
| Map: blaDate: Mon Dec 8 18:04:41
2014|
| Mapset: sequia Login of Creator: polzader
|
| Location: sequia
|
| DataBase: /home/polzader/Documentos/grassdata_diana_bpr
|
| Title: ( bla )
|
| Timestamp: none
|
||
|
|
| Type of Map: raster Number of Categories: 0
|
| Data Type:DCELL
|
| Rows: 2861
|
| Columns: 9350
|
| Total Cells: 26750350
|
|Projection: Latitud - Longitud.
|
|N: 49:42:30.96SS: 60:04:18.329421S Res:
0:00:13.039975|
|E: 46:24:51.430659WW: 80:16:55.2W Res:
0:00:13.039975 |
| Range of data:min = -nan max = -nan
|
|
|
| Data Description:
|
|generated by r.mapcalc
|
|
|
| Comments:
|
|NDVI_1_h11v11 - NDWI_1_h11v11
|
|
++
--
Diana Marcela Brito Hoyos
Biologa
d.br...@javeriana.edu.co mailto:d.br...@javeriana.edu.co
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Computing major and minor axes for polygons
Hi All -- Does anybody here know of an existing GRASS modules that will compute the major and minor axes for the polygons of a vector map? Thanks and best, Ben ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Duplicate features in output of v.out.ogr
Hi All,
I have extracted the centroids of a map with polygons,
but some of the extracted centroids have identical cat
numbers. I suspect that those are centroids of multi-
part polygons that share the same attribute table records
in the original input data (a MapInfo file).
I would like to reduce my set of centroids to only one
per cat value.
So my question is.
Is there a simple way to remove features with duplicate
cat numbers from a GRASS map?
Thanks and best,
Ben
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grouping spatial points
Hi,
On 08/07/14 13:58, Johannes Radinger wrote:
Hi,
I've a point vector containing more than 500 points.
Some of these points are spatially clumped while
others are single independent points (from viewing the
map). Now I am wondering if there is any tool in
GRASS (or maybe other spatial-statistical software
like R) that can be used to group the data so that each
point clump is assigned to a group and each single group to its
own group. Of course, this needs a criterion where
to distinguish between groups/clusters. I'd like to have
groups that are separated by a distance of at least 5 km.
Is there any recommendation of a simple or more
advanced procedure to do that?
I think you are talking about hierarchical spatial
cluster detection. There is an implementation of this
in the free (but not open source) CrimeStat toolbox
(.Net Windows only - yuck). Perhaps R has something
similar/identical?
Best,
Ben
All suggestions all welcome! Thanks!
Best,
Johannes
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] survey: use of different geometry types in same vector map
Hi,
There are many other GIS and file formats that have
multi-geometry support, such as ArcInfo and MapInfo.
Actually, I am not sure that shapefiles with their
single geometry limitation aren't the exception rather
than the rule!
There are uses for this. E.g. in GRASS 6, the original
network analysis work on multi-geom input, with network
links and nodes represented in one and the same map.
Clearly, this is just a design decision, but it does serve
to keep related data tightly together in one dataset.
For the same reason, multi-geometry layers are also
useful for topological data processing.
E.g. GRASS stores boundary line objects and centroid
point objects in one map. If you have e.g. Shapefiles
and want to run topology tests, then you always have
to juggle separate layers.
And why create, e.g. three spatial tables per theme
in a PostGIS DBMS, if you might as well keep everything
nicely together in one? Especially if you have common
attribute data schemas.
So, while I think that separating geometries into different
_layers_ makes data processing easier, the same is not
necessarily true for the actual data _sources_. There,
multi-geom support can make data storage and essential tasks
such as topological validation much more efficient.
Best,
Ben
On 05/03/14 12:08, Moritz Lennert wrote:
Hello,
Recent discussions here with colleagues about GRASS' vector format and
the teaching of vector handling in GIS have brought up a question about
the fact that GRASS (contrary to some other well-known vector formats)
allows a mix of geometry types (points, lines, polygons) in the same
map, something which some GIS'ers consider quite unorthodox.
In order to enrich the reflection on that, I would like to ask GRASS
users for use cases where this mix has been useful. Do you use such
mixed geometry maps ? Which specific use cases do you use them for ?
In order not to flood the mailing list, you can also send me your
response by private mail. I'll report back to the mailing list with the
results.
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Hmm, the manual page does not say so explicitely,
but maybe band numbering starts with 0?
In that case your band 3 would have index number 2.
Ben
On 13/02/14 10:48, manuel.martin wrote:
Hi Ben,
Thanks for the reply. I tried with the band option but it looks like
gdal does not detect the multiple fields as multiple bands :
GRASS 7.0.svn (lambert93):~ r.in.gdal --o \
input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
\
band=3 output=testclc
WARNING: Raster map testclc already exists and will be overwritten
WARNING: Datum Not_specified_based_on_GRS_1980_ellipsoid not recognised
by GRASS and no parameters found
Projection of input dataset and current location appear to match
ERROR 5:
/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
GDALDataset::GetRasterBand(3) - Illegal band #
ERROR: Selected band (3) does not exist
Cheers, Manuel
On 02/12/2014 08:25 PM, Benjamin Ducke wrote:
Hi Manuel,
GRASS does not support multi-band rasters, so you'll have
to import each band as a separate raster map.
r.in.gdal has the band= option to specify a band number
to import.
Best,
Ben
On 12/02/14 17:05, manuel.martin wrote:
Hi all,
I tried to import an ArcGIS binary raster (corine land cover for the
French territory) with three fields on each pixels (VALUE, COUNT and
CODE_06) using the *r.in.gdal* command. The import works just fine,
except that in the resulting raster, in GRASS, I only get one field,
which seems to be the VALUE field (and not the CODE_06 field, which I am
interested in, and which is a categorical field, although coded with
integers).
Is there a way to produce a resulting raster with all the fields of the
initial ArcGIS layer, or alternatively to choose one unique field? Also,
is there a limitation on categorical fields. For instance, what if
instead of integer corine land cover codes I have literal labels, i.e.
levels of my categorical field coded with strings?
Cheers, Manuel
--
00--
INRA - InfoSol
Centre de recherche d'Orléans
2163 Avenue de la Pomme de Pin
CS 40001 ARDON
45075 ORLEANS Cedex 2
tel : (33) (0)2 38 41 48 21
fax : (33) (0)2 38 41 78 69
http://www.gissol.fr
00--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Ouch. I am beginning to suspect that the ESRI field
concept for raster layers does not translate well
to GRASS/GDAL. Sorry for not being able to help.
Maybe someone else on this list has experience with
this type of data structure?
At least now we know that r.in.gdal starts counting
bands with 1!
Ben
On 13/02/14 11:14, manuel.martin wrote:
I had already tried this (with 2) ;-). No luck either. Reading your
email I tried with 0 (maybe would gdal detect only two bands over
three). It comes out that only band=1 works
GRASS 7.0.svn (lambert93):~ r.in.gdal --o
input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
band=0 output=testclc
WARNING: Raster map testclc already exists and will be overwritten
WARNING: Datum Not_specified_based_on_GRS_1980_ellipsoid not recognised
by GRASS and no parameters found
Projection of input dataset and current location appear to match
ERROR 5:
/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
GDALDataset::GetRasterBand(0) - Illegal band #
ERROR: Selected band (0) does not exist
On 02/13/2014 10:59 AM, Benjamin Ducke wrote:
Hmm, the manual page does not say so explicitely,
but maybe band numbering starts with 0?
In that case your band 3 would have index number 2.
Ben
On 13/02/14 10:48, manuel.martin wrote:
Hi Ben,
Thanks for the reply. I tried with the band option but it looks like
gdal does not detect the multiple fields as multiple bands :
GRASS 7.0.svn (lambert93):~ r.in.gdal --o \
input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
\
band=3 output=testclc
WARNING: Raster map testclc already exists and will be overwritten
WARNING: Datum Not_specified_based_on_GRS_1980_ellipsoid not
recognised
by GRASS and no parameters found
Projection of input dataset and current location appear to match
ERROR 5:
/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
GDALDataset::GetRasterBand(3) - Illegal band #
ERROR: Selected band (3) does not exist
Cheers, Manuel
On 02/12/2014 08:25 PM, Benjamin Ducke wrote:
Hi Manuel,
GRASS does not support multi-band rasters, so you'll have
to import each band as a separate raster map.
r.in.gdal has the band= option to specify a band number
to import.
Best,
Ben
On 12/02/14 17:05, manuel.martin wrote:
Hi all,
I tried to import an ArcGIS binary raster (corine land cover for the
French territory) with three fields on each pixels (VALUE, COUNT and
CODE_06) using the *r.in.gdal* command. The import works just fine,
except that in the resulting raster, in GRASS, I only get one field,
which seems to be the VALUE field (and not the CODE_06 field, which
I am
interested in, and which is a categorical field, although coded with
integers).
Is there a way to produce a resulting raster with all the fields of
the
initial ArcGIS layer, or alternatively to choose one unique field?
Also,
is there a limitation on categorical fields. For instance, what if
instead of integer corine land cover codes I have literal labels, i.e.
levels of my categorical field coded with strings?
Cheers, Manuel
--
00--
INRA - InfoSol
Centre de recherche d'Orléans
2163 Avenue de la Pomme de Pin
CS 40001 ARDON
45075 ORLEANS Cedex 2
tel : (33) (0)2 38 41 48 21
fax : (33) (0)2 38 41 78 69
http://www.gissol.fr
00--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Hi Manuel,
GRASS does not support multi-band rasters, so you'll have
to import each band as a separate raster map.
r.in.gdal has the band= option to specify a band number
to import.
Best,
Ben
On 12/02/14 17:05, manuel.martin wrote:
Hi all,
I tried to import an ArcGIS binary raster (corine land cover for the
French territory) with three fields on each pixels (VALUE, COUNT and
CODE_06) using the *r.in.gdal* command. The import works just fine,
except that in the resulting raster, in GRASS, I only get one field,
which seems to be the VALUE field (and not the CODE_06 field, which I am
interested in, and which is a categorical field, although coded with
integers).
Is there a way to produce a resulting raster with all the fields of the
initial ArcGIS layer, or alternatively to choose one unique field? Also,
is there a limitation on categorical fields. For instance, what if
instead of integer corine land cover codes I have literal labels, i.e.
levels of my categorical field coded with strings?
Cheers, Manuel
--
00--
INRA - InfoSol
Centre de recherche d'Orléans
2163 Avenue de la Pomme de Pin
CS 40001 ARDON
45075 ORLEANS Cedex 2
tel : (33) (0)2 38 41 48 21
fax : (33) (0)2 38 41 78 69
http://www.gissol.fr
00--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.cva r.prominence binaries for Windows 64
Hi Dario,
On 21/01/14 16:08, Moritz Lennert wrote:
On 21/01/14 15:56, Dario Guiducci wrote:
Hello,
I would like to compile an add-on module to my installation of GRASS
6.4.3, specifically the r.cva and r.prominence modules developed by Mark
Lake and Benjamin Ducke.
http://www.ucl.ac.uk/~tcrnmar/downloads/AdvancedViewshedAnalysis.tar.gz
You can use both modules through the SEXTANTE/GRASS interface
in gvSIG OADE 2010:
http://www.oadigital.net/software/gvsigoade
For instructions, see the PDF manual that will be copied
to your computer as part of the installation process.
Note that gvSIG OADE 2010 is now unmaintained. There is
a successor called gvSIG CE (www.gvsigce.org), which
will release a stable version in a few weeks (inshallah).
It will also include r.cva and r.prominence. But if you
need them right now, use OADE 2010. It works fine.
Hoping that I can compile these modules myself, I've ran into a number
of problems trying to compile OSgeo4w64 on my system. I'm guessing it
has something to do with the 64bit processor, but I'm also not too
experienced with compiling open source software for this to be easy in
the first place.
Both modules have not seen updates for a while, so I am not sure
that they will compile on GRASS 6.4.3 at all at this moment.
Unfortunately, OSgeo4w64 includes some MS Visual C/C++ projects
and some MSVC runtimes/DLLs, whereas the GRASS binaries that ship
with gvSIG use only open source MinGW DLLs, so I don't think you
can just copy the GRASS modules over (but it's worth a try).
I was wondering if anyone would be kind enough to compile the above
modules, and produce a working binary that I could implement into GRASS
here on my Windows 64-bit system. Or at the very least, point me in the
right direction for how to go about this myself.
You should probably try r.viewshed, for which windows binaries are
pre-compiled [1] and should be installable with g.extension. See also [2].
I would say the same: Try if r.viewshed suits your needs first.
It's much more efficient than r.cva (though not as flexible and
convenient for cumulative analyses).
Alternatively, if you opt for gvSIG: Look in the SEXTANTE group
Visibility Lighting. There are many other options in there.
Best,
Ben
Moritz
[1] http://wingrass.fsv.cvut.cz/grass64/addons/grass-6.4.3/
[2] http://osgeo-org.1560.x6.nabble.com/Status-of-r-cva-td5063519.html
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Fwd: Esri Software Update Notification: Update to Alert Issued on May 14, 2013
I'm glad that I use GNU/Linux!
(couldn't resist)
Seriously, though: At some point we need to archive
such evidence on the wiki, so that next time someone
claims that only proprietary software can offer
reliable quality -- see this URL!
Cheers,
Ben
On 09/13/2013 07:28 PM, Michael Barton wrote:
I'm glad that I use GRASS
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
Begin forwarded message:
*From: *Esri newslet...@esri.com mailto:newslet...@esri.com
*Subject: **Esri Software Update Notification: Update to Alert Issued
on May 14, 2013*
*Date: *September 13, 2013 10:11:39 AM MST
*To: *Michael Barton michael.bar...@asu.edu
mailto:michael.bar...@asu.edu
Esri - Understanding our world.
blue bar
*Information on Microsoft Patch to Fix Data Corruption Issue*
In May of this year, we informed you about Microsoft update KB 2775511
that could result in data corruption when using ArcGIS on a Windows 7
system and writing data to remote data storage on a Windows Vista, 7,
2008/2008 R2, or 2012 system.
This is a follow-up to inform you that Microsoft has now released a
fix under KB 2732673 for this issue.
Esri has tested the fix and verified that it resolves the data
corruption problem previously mentioned.
*The following describes what you need to do to apply this fix:*
* If you previously installed Microsoft KB 2775511, download and
install the update found inKnowledge Base article 2732673
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://support.microsoft.com/kb/2732673?WT.mc_id=EmailCampaign17055aaccording
to the IT policies of your organization.
* If you have not yet installed Microsoft KB 2775511 but plan to do
so at a future date, install the update found atKB 2732673
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://support.microsoft.com/kb/2732673?WT.mc_id=EmailCampaign17055anow
to avoid any issues that may impact file geodatabases and
shapefiles stored on network drives.
*SeeEsri Knowledge Base article 41119
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://support.esri.com/en/knowledgebase/techarticles/detail/41119?WT.mc_id=EmailCampaign17055afor
further information and updates.*
Esri.com
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://www.esri.com?WT.mc_id=EmailCampaign17055|Privacy
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://www.esri.com/legal/privacy.html?WT.mc_id=EmailCampaign17055|Contact
Us
http://autobahn.esri.com/esri/etrack.aspx?DSN=b9ca57b2fbe8cb42458807853387983f6a0f6be5ccdab113FORMID=987c099fe12995c46059458324632afcAUDID=1d1b97763e915159f36016c0f46fe0e9EMAILID=8f9ff131ddf0d93209849360ad83fcf9ed298cefd1667847DECODE=1INTID=2dad22db1ebd20fdccc60fd624169bb2URL=http://www.esri.com/about-esri/contact.html?WT.mc_id=EmailCampaign17055
Copyright © 2013 Esri. All rights reserved.
Esri, 380 New York Street, Redlands, CA 92373, USA.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from aerial photography
One of the handiest solutions for extracting 3D data
using SfM is this:
http://homes.cs.washington.edu/~ccwu/vsfm/
It includes georeferencing and can handle the coordinate
ranges that occur in geographical data. It is free
to use for non-commercial applications but unfortunately
not open source.
Anyhow, SfM works best when there is a large series
of images with a lot of overlap and small angular
displacement between consecutive images. Traditional aerial
imagery will not always give good results. There can also
be trouble with the simple camera model that some SfM
tools (including VSFM) use.
An open source solution that is optimised for remote
surveying applications is currently lacking, AFAIK.
Best,
Ben
On 09/10/2013 04:45 AM, Tim Bowden wrote:
On Mon, 2013-09-09 at 15:08 +0200, Markus Neteler wrote:
On Mon, Sep 9, 2013 at 10:59 AM, Tim Bowden tim.bow...@mapforge.com.au wrote:
Hi,
If all I've got is raw (ie, unrectified) aerial photography sufficient
ground control points, what is the process for creating a DEM (assuming
it's possible with GRASS)? I've not been able to find any documentation
apart from orthorectification using an existing DEM.
You can find something in the Wiki
http://grasswiki.osgeo.org/wiki/Stereoscopic_analysis#GRASS_5
There is an old software stereo which seems to offer this, see links there.
It would be great to get this functionality into GRASS 7.
Markus
Thanks Markus,
For now this capability seems to be 'missing'. Once again I'm
left wishing I was a competent c/c++ programmer (wip...).
In any event, I suspect this approach has been mostly (?) superseded by
'Structure from Motion' type modelling which I'm also playing with- was
just hoping to be able to add 'traditional' photogrammetric modelling
to my toolkit and be able to do a comparison between the two).
Regards,
Tim Bowden
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How GRASS loads raster images into memory?
Hi,
Basically, GRASS reads rasters row-by-row.
But it is up to the individual module to
keep more than one row in memory to speed
up calculations. That is why some GRASS modules
have options for the user to adjust the amount
of raster data to be cached in memory.
The GRASS raster engine is very well documented
in the GRASS developers manual:
http://grass.osgeo.org/programming6/gisrasterlib.html#gisrastintro
(for GRASS 6)
Best,
Ben
On 08/16/2013 03:08 PM, Andranik Hayrapetyan wrote:
Good day,
I would like to understand how GRASS loads raster images into memory to
perform calculations on them.
Does it load the entire image into memory and only then do the
calculation on them, or it loads image into memory by portions sequentially?
Or may be this depends on specific module?
In particular I am interested in 2 modules: *r.mapcalc* and *r.patch*.
In my experiments I had strong feeling that it loads image into memory
by portions, because the usage of memory during the calculation was not
big but the HDD I/O was continuous and quite aggressive...
Any answer or links to documentation about this issue can help me a lot.
Thanks in advance!
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Linux Journal features GRASS GIS
Dear All,
This month's edition of the Amerian Linux Journal
(www.linuxjournal.com) features an article on GRASS.
Overall, I would say the article does a good job
of introducing potential new users to GRASS.
However, while reading it, I realised that two
conceptual problems remain that new users might
struggle with:
1. The role of the PERMAMENT mapset remains
hard to grasp (the article wrongly suggests that
this should be the default mapset to log into).
2. The GUI does not speak the same language as
the CLI when it comes to the use of the terms
map, layer and monitor.
The first issue could be addressed by displaying
a warning of the kind Do you really want to work
in the PERMANENT mapset when a first-time login
attempt is made.
The second issue requires some consideration of
how map and layer are used in different ways
at the moment. Traditionally, a map is a GRASS
raster or vector dataset. In the GUI, what used to
be a monitor is now called Map Display, whereas
what used to be maps is now called Map layers
(and the associated window title is Layer Manager).
Novice users might stumble over this when they
discover the vector modules' layer= option and/or
any single-input module's map= option.
Also:
- The window title Layer Manager is somewhat
of a misnomer, since this is really the main window
and does a lot more than just managing a layer list.
- Using the location name as right-hand part of the
Map Display window title suggests that there could be
multiple locations per GRASS session (as there can be
multiple Map Display windows), which is misleading
(at least for languages that use left-to-right writing).
To bring back consistency, some review of terminology
across CLI and GUI seems in order. Since it seems to
me that it is easiest to change some strings in the
GUI, I would suggest something like this:
Layer Manager = GRASS GIS - location (filename.gxw)
Map Display x = GRASS GIS - location (Monitor x)
Map layers = Maps
Display x = Monitor x
Best,
Ben
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Linux Journal features GRASS GIS
On 06/05/2013 11:33 AM, Hamish wrote:
Hi,
last month or so we changed the location wizard to offer to create a
user mapset, which should gently nudge people in the direction of not
using the PERMANENT mapset for everyday work, and exploring the
concept of MAPSETS. as long as your user name starts with a letter
before p your one is the first offered. even if not, you are more
likely to click on your own name.
Perhaps the dialog that offers to create a new mapset
should also advise that there will always be a
PERMANENT mapset for common static base data.
I see a funny thing where on linux wx organizes the [cancel][ok] so
the [cancel] is right under your mouse when you get to the pop up for
workspace mapset creation, but on windows the [ok] is pre-selected.
That's probably because wxWidgets delegates the
management of the actual widgets to the OS' own
class library. And for some reason the Windows
designers thought it would be wise to have OK
selected by default. On Mac OS and Linux (GTK+),
different standard behaviour is used.
so I think the problem is already partially addressed.
I would still favour a warning message when
a user attempts to log into PERMANENT for the
first time (perhaps with a little Do not show this
hint again toggle button).
moving PERMANENT to .PERMANENT would break backwards compatibility
too much I think, and it is useful when you want to share e.g.
country coastline maps.
Yes, attempting to completely hide the PERMANENT
folder would be counter-productive. It is actually
a very useful thing -- if used properly.
Best,
Ben
wrt maps wording I don't think there is too much confusion about
what they are.
layer is certainly used in two ways. Originally the vector DB link
ones were called fields (and still are in bits of the vector API
fns internally), but Radim decided to change that after a long while.
I can't quite remember, you'll have to dig in the archives to see the
logic in it. Anyway it was before the new GUIs arrived so before the
overlap.
wrt display vs monitor I don't think there is too much confusion.
at least new users not using 'd.mon x0' will not have to worry about
monitors since they will never see them. and if they get it wrong
it's still sort of the same thing to them so they shouldn't notice
the difference. (ps, I just noticed the d.rast3d.py module
description is a bit fuzzy in what it will render to [nothing?]
[note also in grass 5 there was a d.3d module like m.nviz.image now
does])
but probably Layer manager - GRASS GIS manager makes more sense
seeing it is both the layer manager and the GUI menus, and the python
console, and the output window ... the trouble with layers is that
people coming from other GIS software will naturally thing in the
foreign terminology that they are used to, and that was the GUI map
kind.
(btw, maybe pack the Help menu to the far right side, and make the
layer manager window wider/bigger by default)
Hamish
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Horizon based voxel interpolation for GRASS
Hi Tim,
Thanks for your willingness to contribute to
GRASS GIS via this year's GSoC.
I am assuming that you want to plan your work
along the lines of this implementation:
http://chl.erdc.usace.army.mil/chl.aspx?p=sa=ARTICLES;41g=50
In that case, you will need to deal with
3D points as input data. Each point should
represent the lower boundary of a soil
horizon as detected in the sample (core)
to which the point belongs.
The output will be a 3D raster layer,
possibly 2D interpolated surfaces as
intermediate data.
But we will also need to think about cross-sections,
which can be added to the input data to improve
the interpolation.
Btw., there is a similar implementation here:
http://umweltgeologie.geologie.uni-halle.de/downloads/
(see INVIS and HYVIS).
It's done in Visual Basic and for ArcGIS 9,
but nevertheless, some useful things might
be learned from it (it's GPL too and comes
with full scource code).
Best,
Ben
On 05/08/2013 06:48 PM, Tim Bailey wrote:
Hello fellow GRASS users. My name is Tim Bailey. I am an environmental
systems graduate student at Humboldt State University in California. I
submitted a proposal to write a grass module that would do voxel
interpolation on horizon based datasets for the Google Summer of Code.
This project was an open ticket on the OSGeo GSOC proposal site. I
would love to hear from anyone that has ideas about the data structure
for this project.
Tim Bailey
timi...@gmail.com mailto:timi...@gmail.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Processing LiDAR data in GRASS GIS
On 05/03/2013 01:18 PM, Hamish wrote:
jr.morreale wrote:
Then what would be the limit for grass7 with 4gb of ram, no
topology/database ? Can it handle billions of points ?
In my experience, it can (even GRASS 6), if:
a) you rasterize the input data directly (r.in.xyz,
as suggested by Hamish).
b) your file system supports files 4GB (which really
just about anything except a VFAT formatted USB drive
should these days)
and
c) (in case you want to export the results for use
with another GIS) your GDAL has a GeoTIFF driver
that has 64 bit BigTIFF support enabled.
To save storage space, use single precision
floating point data if you can.
Best,
Ben
I don't really know to be honest. Try the experimental approach
and keep an eye on `top`, and let us know the results. :) See the
grass wiki FAQ for a hint on adding temporary swap space on Linux
if you need it.
r.in.xyz can handle many billions of points without trouble for
non-exotic statistical aggregations; memory use there is more a
matter of raster region size and you can do multi-pass if memory
is an issue on a really really huge region.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass vector model, cats and layers concept
That looks nice and clear to me now.
Best,
Ben
On 04/22/2013 10:37 PM, Vincent Bain wrote:
Thank you Ben and Moritz for your comments,
http://www.toraval.fr/telec/catsnlayers_4.zip
Feel free to modify the source svg file,
Vincent.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass vector model, cats and layers concept
On 04/22/2013 04:38 PM, Vincent Bain wrote:
Le lundi 22 avril 2013 à 14:58 +0200, Moritz Lennert a écrit :
On 22/04/13 14:41, Vincent Bain wrote:
Thank you Moritz,
- I'm not sure I like the difference in size of cat values between
layers. It gives the idea that there is one important and two secondary
layers.
Sorry, I don't understand. Cats values are all the same font size in the
drawing (I turned 1 values to sth else, perhaps an optical illusion)
Sorry, I was confused by your id. I'm not sure that this id is helpful
in your drawing as most users will never be confronted to id's, only to
cat values. I think making them this prominent in the drawing might
cause more confusion than help in understanding.
I agree with you that most users won't feel concerned by the feature-id,
especially the majority of people working on imported data (what's more
for the user, there's no way to manage this internal numbering). Those
who learn grass in order to /produce/ geographical data may very soon in
their learning process be concerned by this. My humble opinion is that
awareness of the existence of a geometrical identifier is an integral
part of the problem. I would keep it in the sketch, perhaps as you
suggest in a less prominent appearance.
+1. Like so many, I also got confused about this
the first time I started working with the GRASS
vector API.
Maybe you could put a short note somewhere on the
illustration stating that the internal feature ID
is assigned automatically and can be used to select
geometries directly (using v.edit)
or similar.
Best,
Ben
No, what I meant is to have a unique cat for each plot in layer 2 and
then have an attibute table with columns cat and type, the second then
giving the type of the plot, while the first is a unique identifier of
each plot.
OK, I'll have a look.
Thanks,
V.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass vector model, cats and layers concept
Yes, it looks a lot nicer with the
GRASSy green colours.
Best,
Ben
On 04/20/2013 04:50 PM, Vincent Bain wrote:
Thank you Benjamin for your reply,
my first concern was to output a graphically light and neutral drawing.
It is much easier to make things more readable with a little bit of
colors.
http://www.toraval.fr/telec/catsnlayers_2.zip
VB
Le samedi 20 avril 2013 à 12:53 +0200, Benjamin Ducke a écrit :
Thanks Vincent,
This is something that was needed
for a long time. A few suggestions:
I find the light grey that you used
extensively in the illustration
hard to read.
Since the word field is also
a technical key word in this context,
I would rename the example table
fields to plots.
Best,
Ben
On 04/20/2013 12:47 PM, Vincent Bain wrote:
Hello,
recently I suggested [1] to scribble a sketch to illustrate concepts of
categories and layers specific to grass vector model.
Here it is:
http://www.toraval.fr/telec/catsnlayers.zip
I would appreciate to have your feedbacks on it, hoping thinks are true
and clear enough...
The idea is to provide a visual aid to the manuals/vectorintro.html and
if necessary a page on the wiki where the diagram would be explicitely
commented :
- terminology (feature-id, cat, layer, database connection)
- related handling commands (v.category and so on).
Yours,
Vincent.
[1] On Moritz's proposal :
http://lists.osgeo.org/pipermail/grass-user/2013-April/067668.html
___
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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Make 3D soil-profiles
The document is still available online here:
http://www.is.informatik.uni-kiel.de/~ma/trcs/thesis.html
Ben
On 04/05/2013 03:29 AM, Thomas Adams wrote:
David,
See if you can find the PhD thesis:
THREE-DIMENSIONAL RULE-BASED CONTINUOUS SOIL MODELLING
Martin Ameskamp
Bericht 9701 Februar 1997
I can send it to you, if you would like.
Tom
On Thu, Apr 4, 2013 at 9:38 AM, David n d_neu...@msn.com
mailto:d_neu...@msn.com wrote:
Hi!
I want to fetch a rasterdata(.jpg)-soilprofile to an polyline in 3D.
The jpg-picture should then look like a curtain, falling down of the
polyline, so to say... this would be an example how i think the
result should look like: http://www.terramath.com/software/sr_1.jpg
Do you have an idea to solve this problem with GRASSGIS, i have no
glue...
Thank you very much!
Yours sincerely,
David
___
grass-user mailing list
grass-user@lists.osgeo.org mailto: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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Apply v.transform in polygons with overlays
On 02/26/2013 01:32 PM, José María Michia Roberts wrote:
José María Michia Roberts:
[...]
many elements disappear after importing the layer,
and more elements disappear after applying v.transform
[...]
In reply to myself: I now remember that I had solve this by adding
-c to v.in.ogr, so the output layer is not cleaned and all source
elements are imported. But v.transform don't have such option. ¿May
be this implemented? ¿May be useful?
Many GRASS modules expect topologically
clean input data (level 2 data).
The cleaning functions will run automatically
if the data is not clean.
A fix might be to introduce a new GRASS env
variable that can be set to suppress the cleaning
functions. While it would probably be trivial to
implement this, it would also break with GRASS'
basic design and the assumptions that its vector
processing modules make (namely that the input
data is topologically correct).
Ben
Hamish:
try running v.split on the largest of the polygons.
search the mailing list archives for the florida coastline
problem.
I've found a thread named speeding up v.in.ogr. It is a bit complex.
I gave him a look, but I think it not applies to my case, since I have
many polygons, with many small overlaps. Also, each polygon have a
database record, so I need to preserve at least an numeric field (an
ID), so split the polygons seems to be problematic to me.
On the other hand, revisiting the man page for v.transform I've
noted the ST_Affine PostGIS function. If I'm right, by taking the
transformation matrix reported by v.transform (applied to any
element) and entering their values in ST_Affine, I could transform a
whole PostGIS table (within a PostGIS table, polygons can be
overlapped). I tried that way, but I get an incorrect result. I
suspect the problem is in the transformation matrix values reported by
GRASS. I will refer to this in a new thread.
Thanks all!
José
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing ESRI Shapefile might cause attribute data corruption
Maris,
This sounds a like a truly horrible problem.
Thanks for raising awareness of this.
Are there any other sources on the web where
it would be possible to get more information
about this?
Have you tried downgrading only the Shapefile
drivers in the GDAL 1.9.x release?
Best,
Ben
On 02/15/2013 05:01 PM, Maris Nartiss wrote:
JFYI
GRASS is also hit hard by recent GDAL/OGR ESRI Shapefile encoding
saga. Importing ESRI Shapefile with non-latin text most likely will
corrupt Your text.
Symptoms - even when setting correct encoding for wxgui in
preferences, non-latin letters are shown grabbled and doubled (two
garbage symbols instead of a single letter).
Solution - create a .cpg file and pray or downgrade GDAL/OGR on
pre-1.9.0 version (not an option for WinGRASS users).
Note - if Your data are corrupted during import with v.in.ogr, there's
no easy way how to correct it.*
* find/replace in LO Calc might do the trick for DBF file.
Have a nice day.
Maris.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Low pass filtering
On 01/25/2013 05:28 PM, John Nicholls wrote:
Hi
I am looking for some direction in applying a low pass filter to a
raster greyscale of geophysics data. The filtering objective is fairly
typical, aimed at removing influence of background noise normally
Striping is not really noise. It's a systematic defect
in your data that cannot easily be removed with a simple
low-pass filter.
There is really no universal cure for this problem.
Unless your stripes are perfectly aligned with the
X or Y axis of your geographical region, simple
map algebra won't get you far, either.
The classic treatise on the subject is this one:
http://www.oimoen.com/PDFs/artifacts.pdf
Basically, the trick is using a low-pass and high-pass
filter whose shapes and sizes match those of your
stripes.
visible as linear striping or similar in a raster image created via
v.in.ascii then v.surf.idw or v.surf.bspline. I’ve tried r.mfilter
applying both 3x3 and 7x7 low pass filters as detailed in the GRASS
literature, and ask here if there are other methods either via r.mapcalc
or R which may prove more effective. I am not familiar with r.mapcalc,
nor R. I wonder if anybody has applied lowpass filters using either of
these 2 before, and would be kind enough to provide me with a lead in to
get started. Perhaps there a manual page I've not yet got to. Still a
long way to go with GRASS, but it really is superb for the limited
vector and raster analysis I need.
It's also superb for very advanced vector and raster
analyses ;)
Cheers,
Ben
Grass version I am using is 6.4.2 on Ubuntu.
Many thanks in advance,
JohnN
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Import of multi-part polygons using v.in.ogr?
Hi List --
Looking at function centroid() in geom.c
of v.in.ogr, it seems to me that the code
for import of polygons always assumes that
the first ring is the exterior boundary and
the following ones are all interior boundaries
(see comment on lines 70 and 71).
Is this a limitation of GRASS' vector model
or would it be possible to import multi-part
polygons with more than one outer boundary by
amending the code in v.in.ogr?
I understand that it is possible to import
multi-part geometries into GRASS and assign
each part the same cat number. However,
when exporting with v.out.ogr, they will be
exported as separate parts, each with its
own attribute table row. Is there any
way to preserve multi-part features using
v.in.ogr and v.out.ogr?
If this is currently not possible: Would it
be a viable solution to add a -j (join)
flag to v.out.ogr so that it will merge
geometries with the same cat into multi-
part features on export?
Cheers,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] reboxing, or 3D regridding
Tom -- this is an interesting use case.
I think you need to separate the reprojection step from
the resampling step. Maybe you could first
extract and reproject each one of the 56 lat/lon data slice
as an individual 2D raster layer, then stack the levels
into a new GRASS 3D raster.
For the next step, you would need some method to
resample/interpolate the voxel data to your target resolution.
Since you want fewer output than input slices, the easiest
option would be to just set the the GRASS region's Z resolution
to the number of output levels and let GRASS do a simple
linear resampling. But I am not sure that will give
a quality that's good enough for your purposes. Try it.
Best,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Wed, Nov 14, 2012, at 19:27, Tom Roche wrote:
summary: I'd appreciate advice regarding tools and methods for
transforming data attributed to voxels in an unprojected global grid
onto a projected 3D grid with different horizontal and vertical
resolution (or pointers to other resources to consult).
details:
ESMF defines well (if somewhat oddly) the general problem:
http://www.earthsystemmodeling.org/esmf_releases/public/ESMF_5_2_0rp1/ESMF_refdoc/node3.html#SECTION0302
Regridding, also called remapping or interpolation [or resampling], is
the process of changing the grid that underlies data values while
preserving qualities of the original data.
ESMF seems to provide excellent tools for doing 2D regridding (or
interpolating data values from the cells/pixels of one 2D/horizontal
spatial grid to another), as does GRASS::r.proj
http://grass.osgeo.org/grass64/manuals/html64_user/r.proj.html
though I have not used either, and am quite new to GRASS. (My current
personal favorite regridding tool is the R package 'raster': see code @
https://github.com/TomRoche/GEIA_to_netCDF/
) However I'm not seeing tools for reboxing, or interpolating data
values from the boxes/voxels of one 3D/horizontal+vertical spatial grid
to another. Am I missing something? I _do_ see (thanks, Doug Newcomb)
raster3D
http://grass.osgeo.org/grass64/manuals/html64_user/raster3D.html
but I don't see r3 API that does what I want:
I have output from a global atmospheric model that I'd like to use as
initial/boundary conditions for a regional model. This unprojected
global input (from the perspective of this usecase) netCDF has
dimensions=2.5° lon x 1.875° lat x 56 vertical levels. The regional
model covers North America using a 12-km grid projected LCC (Lambert
Conic Comformal), with 34 vertical levels: details @
https://github.com/TomRoche/cornbeltN2O/wiki/AQMEII-North-American-domain#wiki-EPA
The top height of the regional output is less than that of the global
input; i.e., the input domain fully contains the output domain, in all
3 dimensions.
Each box/voxel of the global input grid contains an estimate of its N2O
concentration. From those data I want to compute the concentrations for
each output box. I'd appreciate your recommendations for tools that can
do this. The best tool I've seen so far is R package=gstat, but (IIUC)
- gstat expects projected input. I'm not sure if I can work around that
for this usecase. Is there a conservative projection over North
America to which I could safely transform values from lon-lat
(essentially via cropping?) in order to input them to gstat?
- as the name implies, 'gstat' is doing geostatistical (variogram- and
covariance-based) modeling. I'm not sure either how to setup the
distance weighting for my usecase. I'm also unconvinced that a
statistical approach is necessary for this usecase, though it may be a
sufficient, or the best-available, approach; furthermore my position
may just be a prejudice due to my statistical ignorance.
TIA, Tom Roche tom_ro...@pobox.com
___
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] G_malloc error
Paul:
If you want GRASS to use more than 3.5GB of RAM,
then you need to run a 64 bit operating system.
Otherwise, no single application will get to see
more than 4GB. Also check your motherboard's manual
to see how much RAM it supports. Often, there are
limits of 16, 32 or 64GB total.
If you plan to use 64 bit Windows, then be aware
that Microsoft has put arbitrary limitations re.
usable RAM into each one of there many different
release versions. E.g. a Windows Home license might
not be able to use more than 8GB.
Ben
On 10/29/2012 02:19 PM, Paul Shapley wrote:
Hi Users,
I'm getting 'G_malloc' errors when using large images in Grass 6.4.3rc1.
I need to use much larger images than the one causing the error. Is
there a way around this problem? i have 3gb of RAM on this PC (standard
MS Windows installer not osgeo). Is this enough RAM or should i invest
in much more... or is there another cause of this?.
Error message:
Current region rows: 19998, cols: 15999
ERROR: G_malloc: unable to allocate 1279792008 bytes of memory at gsds.c:575
--
Paul J. Shapley
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] G_malloc error
On 10/29/2012 06:27 PM, Glynn Clements wrote:
[snip]
Also, we don't currently provide 64-bit GRASS binaries for Windows, so
you'd need to build it from source with a compiler that can produce
64-bit executables (and you'll need 64-bit versions of all of the
relevant libraries).
The last time I checked, MingGW-64 was still quite unstable, although
I don't know if that has changed since. The build system doesn't
support compiling with MSVC (and the free edition doesn't support
building 64-bit binaries).
True. And it's a beast to install and to get all the libs and
header files into place. However, the situation is improving
continuously. I have documented my efforts (trying to compile
a GRASS 6.4.3 distro with minimal dependencies for use via
SEXTANTE in gvSIG) here:
http://gvsigce.sourceforge.net/wiki/index.php/Development_and_releases.
It's incomplete (I have not been successful at compiling a complete
64 bit binary set on Windows so far), but maybe it will be of some use.
I believe that it is possible to compile 64 bit binaries with
MSVC, after downloading some additional packages:
http://support.brainvoyager.com/available-tools/52-matlab-tools-bvxqtools/339-how-to-get-a-64-bit-compiler-under-windows-to-use-with-matlab.html
However, I am not sure it's worth the trouble: MS change their
free MSVC policies and front-ends all the time. It seems a safer
bet to me that MingGW-64 will mature soon enough.
Cheers,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
On 05/28/2012 01:44 PM, Paolo Cavallini wrote:
Il 26/05/2012 20:59, Benjamin Ducke ha scritto:
Please report bugs relating to the SEXTANTE GRASS
interface to the SEXTANTE bug tracker:
http://bugs.gvsigce.org
After logging in, switch the selection under
Project: (upper right page area) to SEXTANTE:
http://gvsigce.sourceforge.net/wiki/index.php/How_to_report_bugs
The QGIS client code is just one of several GIS bindings
that SEXTANTE supports, but any problems related
to calling GRASS modules from SEXTANTE must be
fixed in the shared Java code base.
Wrong (no java here): http://hub.qgis.org/projects/sextante/issues
That is the bugtracker for the gvSIG edition.
I know it's confusing: http://hub.qgis.org/issues/5353
Thanks a lot.
SEXTANTE and gvSIG CE share a bug tracker
at http://bugs.gvsigce.org, a decision that
was made together with Victor Olaya a while
ago:
http://sextantegis.blogspot.de/2011/12/important-notice-for-gvsig-users.html
There is no such thing as a gvSIG edition
of SEXTANTE. SEXTANTE is a GIS-independent
library of processing functions written in Java.
Only the gvSIG bindings are gvSIG-specific code.
The GRASS GIS interface was written (in
large parts by myself!) in _Java_ and implemented
in the SEXTANTE _Java_ core libraries. It is _not_
QGIS-specific C++ code. I have spent many months
getting the SEXTANTE GRASS GIS interface into
good shape for _all_ host GIS, including QGIS.
There are now two different bug trackers
that track duplicate issues which have
to be fixed in the Java code base, _not_
the QGIS client code! I have already seen
several entries in the QGIS bug tracker
relating to GRASS, that are already reported
and being worked on at bugs.gvsigce.org.
The same is true for the R and SAGA backends,
both of which are also covered in the official
bug tracker.
Again: SEXTANTE is GIS-independent
and only bugs that refer to the QGIS side
(i.e. the specific bindings for that platform)
should be reported using the QGIS bug tracker.
Bugs that related to running GRASS/SAGA/R from within
SEXTANTE are GIS-independent and should thus be
worked on in one central place.
Of course, you are free to open as many additional
bug trackers, as you like, but this will result
in duplicate efforts, wasted time and resources,
and undermine all the work that has already been
done.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
OK, I think I can see my mistake now.
I always assumed that Victor had developed the QGIS bindings
on top of the existing Java libraries, using one of the
available Java to Python bridges or the Java Native Interface
for C++.
However, this does not seem to be the case. The code in:
http://code.google.com/p/sextante/source/browse/trunk/soft/bindings/qgis-plugin/src
does not contain just another binding for SEXTANTE to QGIS (even
though the SVN folder structure suggests this) -- Victor, please
correct me if I am wrong here.
Rather, it looks like it contains a complete re-write of SEXTANTE in
Python (excluding the original SEXTANTE processing tools, which seem
to be only available in their Java versions).
I am entirely unsure how to further maintain a code base in two
different programming languages and how to keep my own work
on the GRASS/SAGA/R interfaces in Java synchronized with this.
Any ideas welcome (but should probably be discussed on the SEXTANTE
user mailing list).
As far as the GRASS code sprint is concerned, please consider
that many people use SEXTANTE under gvSIG, OpenJUMP, GeoTools and
other Java-based GIS at this point, and that they are just as
interested in seeing the GRASS interface improved, as QGIS
users are. For now, I will monitor the QGIS bug tracker and
synchronize any relevant tickets manually with bugs.gvsigce.org.
Best,
Ben
On 05/28/2012 03:08 PM, Markus Metz wrote:
On Mon, May 28, 2012 at 2:47 PM, Paolo Cavallinicavall...@faunalia.it wrote:
Il 28/05/2012 14:33, Benjamin Ducke ha scritto:
SEXTANTE and gvSIG CE share a bug tracker
at http://bugs.gvsigce.org, a decision that
was made together with Victor Olaya a while
Hi all.
Sorry for the misunderstanding.
I am not sure Victor (main SEXTANTE dev, AFAIK) is listening here - if so, he
can
explain much better.
Anyway, I (and I suspect also Marckus) was referring to the QGIS Python plugin
called
sextante. No shared code with the Java version, AFAIK.
I have just compared the QGIS SEXTANTE plugin, the gvSIG SEXTANTE
plugin, and the generic SEXTANTE. For example, the contents of the
grass/description folder of QGIS SEXTANTE are completely different
from gvSIG and generic SEXTANTE. The former has hand-crafted .txt
files, the latter have automatically generated (grass command
--interface-description) XML files. QGIS SEXTANTE is pure python
without any java code, the others are pure java without any python
code.
There is a dedicated bug tracker for QGIS SEXTANTE, and from a user
perspective this is the logical place to report issues for QGIS
SEXTANTE, in particular when keeping in mind that the GRASS command
interfaces in QGIS SEXTANTE are hand-crafted, see v.buffer.angle.txt,
v.buffer.column.txt, v.buffer.distance.txt,
v.buffer.minordistance.txt, four different interfaces to the same
GRASS command v.buffer. In gvSIG SEXTANTE, there is only v.buffer.xml.
How should a user take these differences into account? Report to
http://bugs.gvsigce.org and explain that this does not apply to gvSIG
SEXTANTE, only to QGIS SEXTANTE?
Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
I do not see an alternative to manual sync (quite painful and inefficient, I
know).
All the best.
Neither do I, at this point. Manual sync it will be, then
-- argh :(
Sorry if I have been blunt in my reaction to this.
I have put a lot of thought effort into the SEXTANTE-GRASS
interface to get it to work as smoothly as it does now.
I would hate to see this work die a slow death for lack
of shared resources.
But perhaps the two code bases can somehow be kept in sync
-- at least for the most part.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Report from ongoing GRASS GIS Community Sprint in Prague
Hi,
sounds like an excellent code sprint!
One quick note:
Please report bugs relating to the SEXTANTE GRASS
interface to the SEXTANTE bug tracker:
http://bugs.gvsigce.org
After logging in, switch the selection under
Project: (upper right page area) to SEXTANTE:
http://gvsigce.sourceforge.net/wiki/index.php/How_to_report_bugs
The QGIS client code is just one of several GIS bindings
that SEXTANTE supports, but any problems related
to calling GRASS modules from SEXTANTE must be
fixed in the shared Java code base.
Cheers and happy hacking,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Sat, May 26, 2012, at 18:08, Markus Neteler wrote:
Greetings from the GRASS GIS Community Sprint 2012 in Prague.
With a peak participation of 16 persons, we are proceeding very well.
Find the current activity report at:
http://grass.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2012
Photos will be uploaded soon!
We are grateful for the support which we have received to organize
this GRASS Community Sprint. Special thanks to our sponsors:
* GFOSS.it, the Italian OSGeo chapter) - 1400 Euro
* Open Source Geospatial Foundation (OSGeo) - 1000 Euro
* FOSSGIS e.V. - 1000 Euro
* Stefan Sylla, sylla-consult, Frankfurt, Germany - 500 Euro
* Lubos Mitas, NC, USA - 200 Euro
Best
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] Re: ArcGIS vs GRASS notes
On 04/02/2012 08:00 PM, Alex Mandel wrote:
I can clarify some of the questions... Arc has dropped Visual Basic
in favor of python, in the current 10.x series though python can only
interact with tools in the toolbox (making it quite similar to how
GRASS works). Anything more directly using Arc libs to build
applications at the low level requires .Net.
Personally I like to explain it as GRASS fills the same role
typically filled by Spatial Analyst, 3D Analyst, Network Analyst and
Imagery Analyst (All add on extension to Arc). While not 100%
equivalent it's similar enough in feature set. I also tend to
recommend a combo of QGIS as the data prep/viewer/map maker and GRASS
(not via plugin) as the backend analysis workhorse.
For general Raster analysis that uses existing tools GRASS is a
great option. In the course I help with we've avoided it though
because the Location/Mapset concept throws too many students into
confusion early on. Instead we've followed a course similar to the
Utah one on how to
If you use GRASS via SEXTANTE and gvSIG, then you have all in one
package and no need to manage a location/mapset:
http://www.oadigital.net/software/gvsigoade
Basically it's like ArcView 3.x, plus all the [PayALotOfMoney] Analyst
extensions (Raster, Network, etc.).
I have used the above in many GIS training courses, as an integrated
software platform for students with different backgrounds, interests
and skill levels. I have also successfully replaced ArcGIS 10 with
the above for very demanding land use/management and data analysis
projects.
Best,
Ben
use GDAL/Numpy, which gives students more of a feel for how to
iterate over raster data and learn to deal with it in chunks or rows
to avoid memory issues, so they better understand how raster
algorithm development works. http://www.gis.usu.edu/~chrisg/python/
I need to talk with my Professor about getting our updated version
online.
Thanks, Alex
On 04/02/2012 10:40 AM, Michael Barton wrote:
I don't know of any such comparison, but you could write the user
and developer lists to see if there is one. I haven't kept up with
Arc scripting in recent years. I believe they switched from their
own OOL to Visual Basic. However, I've recently heard things that
suggest you can script in Python too (but I'm not sure about
that).
With GRASS, you can script in about anything that will interact
with the shell (or DOS window) in some way. In recent years, we've
emphasized Python over BASH, creating many convenience classes and
methods in Python for GRASS scripting.
I'm not sure of the level of your students. But if this is also an
introduction to GRASS and advanced GIS, I think it will make it
much harder for them to learn if you keep them from using the GUI.
An important aspect of the GUI from the point of view of scripting
is that it is designed to help users learn command-line tools and
scripting.
1. All GUI dialogs for commands have the option of copying the
command and its arguments so that it can be pasted into the command
line or into a script.
2. Additionally, the GRASS command console provides a rich hinting
environment (with autocompletion and tab to get command syntax) for
issuing GRASS commands.
3. Finally, the new graphical modeler is an excellent tools to
start scripting. You can create chains of GRASS commands--complete
with user interaction and recursion--with graphical tools, test
them, and then save them to Python scripts that can then be
enhanced. There are not many written docs for this yet, but there
is an excellent set of You-Tube videos on their use that should be
very helpful for students.
Michael
On Apr 1, 2012, at 8:15 AM, Doc Robinson wrote:
Professor Barton, I very much liked your posting comparing ArcGIS
with GRASS for the new user. I was wondering if you have run
across a good summary comparing the two with regard to scripting
for complex raster processing problems?
I going to introduce some of our graduate students (a couple
from Anthropology as well) to GRASS 6.4.x but not the GUI...just
the text CLI so they concentrate on script writing.
thanks in advance -- Regards,
Doc doc_robinson.vcf
_ C. Michael Barton Visiting Scientist,
Integrated Science Program National Center for Atmospheric
Research University Corporation for Atmospheric Research
303-497-2889 (voice)
Director, Center for Social Dynamics Complexity Professor of
Anthropology, School of Human Evolution Social Change Arizona
State University www: http://www.public.asu.edu/~cmbarton,
http://csdc.asu.edu
___ grass-user mailing
list grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] TIN (Linear interpolation) from points
v.geom no longer exists in the GRASS distribution,
because of licensing issues. See here
http://lists.osgeo.org/pipermail/grass-user/2002-April/006286.html
(first Google hit for v.geom grass)
The new modules for triangulation are v.delaunay,
v.voronoi and v.hull.
Ben
On 03/17/2012 02:56 PM, Vincent Bain wrote:
Hi,
sorry if I misunderstand your needs but have a look at r.surf.nnbathy,
it could do the job for a raster output. First you need to retrieve nn
libs. More details on the author's web page :
http://www.sieczka.org/programy_pl.html
Yours,
Vincent.
Le samedi 17 mars 2012 à 04:30 -0700, TheGeographer a écrit :
In the past there was a module which created TINs from points as input in
GRASS, but now it is not longer supported:
http://www.grass-kr.org/html/v.geom.html
For me this part is very interesting: MaxMin-Height triangulation
But the last GRASS version which is supported is Version 5.4 .
I easily created a TIN with 3 points in QGIS in a couple of seconds. Is
there an possibility in GRASS GIS,too?
I don't understand why it is still not integrated into GRASS GIS (This
application is much older than QGIS?)
The possibility of automation in GRASS GIS via shellscript is the main
reason why i need GRASS.
The (Elevation-)TIN should look like this:
http://osgeo-org.1560.n6.nabble.com/file/n4627723/tin_qgis.jpg
After the TIN creation I want to use the r.contour module to get contours
out of the TIN.
Greetings
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/TIN-Linear-interpolation-from-points-tp4627723p4627723.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
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
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: GUI command works, but not the command copied in the CLI
Have you tried Maris' suggestion and put quotes around
the value of the input= option?
The command that you copied below has a space in the
path leading to srtm.txt. If you do not quote this,
command line parsing _will_ break. This seems to be
the cause of your troubles. To make things easier,
avoid using folder names with spaces. For a quick
fix, rename GIS projects - GIS_projects.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Mon, Feb 27, 2012, at 04:44, PuffDany wrote:
Thanks very much for your input, Maris. Unfortunately it didn't make the
think work. Here's the command:
r.in.arc input=G:\Data\GIS projects\GRASSdata\Emmental\PERMANENT\srtm.txt
output=srtm11 (you can also see it in the printscreen of email 1)
This command is a direct copy/paste from the GUI, which works fine, and
its
not a problem of the filename already existing, as I have given new file
names.
Many thanks
PuffDany
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/GUI-command-works-but-not-the-command-copied-in-the-CLI-tp4514528p4514605.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
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] Warning message for paths with space(s)?
Would it be a good idea for GRASS to issue a warning
on start-up, if the user attempts to start a session
in a mapset that has a space in its path?
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Mon, Feb 27, 2012, at 05:16, PuffDany wrote:
Ah-Ha...!!! It works!!! I tried the ' and and // suggest by Maris, but
none
worked. However, the space in the path was the problem. So thanks a lot
to
both of you, Maris and Ben!!! It's a sunray in my day!!!
PuffDany
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/GUI-command-works-but-not-the-command-copied-in-the-CLI-tp4514528p4514689.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
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] spgrass6
As opposed to GRASS, R has not been designed with computational and/or memory efficiency as a priority. It has its limits when dealing with large datasets (not only GIS datasets). Maybe your analysis would allow you to run your computations on a representative sample instead of the whole dataset? Ben On Wed, Feb 22, 2012, at 11:34, Markus Neteler wrote: On Wed, Feb 22, 2012 at 11:32 AM, Paolo Cavallini cavall...@faunalia.it wrote: OK, I see, thanks. Are R devs aware of this? I guess so but.. Should we open tickets? ... no idea, perhaps grass-st...@lists.osgeo.org would be the right place to discuss this issue. 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] spgrass6
Have you tried a plotting function that is more efficient for gridded R data? Perhaps plot() from the raster package? I think this is rather a question for the R mailing list, though. Ben On Wed, Feb 22, 2012, at 13:02, Paolo Cavallini wrote: Il 22/02/2012 12:21, Benjamin Ducke ha scritto: As opposed to GRASS, R has not been designed with computational and/or memory efficiency as a priority. Oh! I was not fully aware of this. Maybe your analysis would allow you to run your computations on a representative sample instead of the whole dataset? In our case, the analysis is vert simple: just ssplot() of a small (2k by 2k cells) raster. Thanks. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ 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] NVIZ Wire Mesh
I would like to take the opportunity to share
a few observations I made with VTK/ParaView Co.
All 3D data produced in GRASS
can be exported to VTK format (r.out.vtk,
r3.out.vtk, v.out.vtk), and visualized in VTK-
based viewers such as ParaView. There are some
limitations, though: text type attributes are not
supported in the VTK output format. If you need
that, then take a look at VisIt, which is also
an excellent VTK-based application that can
directly read 3D shapefiles with all attribute types.
However, you might run into problems with complex
(concave) polygons, as the VTK visualization model
does not seem to support those (forget about polygons
with holes).
There is also a branch of ParaView, called
ParaViewGeo, that explicitly supports GIS data
formats. It seems to always lag a little behind
the official version, but it might well be worth
a look.
Cheers,
Ben
On 01/26/2012 03:31 PM, Saber Razmjooei wrote:
Have you looked into using Paraview to do that?
Cheers
Saber
-Original Message-
From: Anna Kratochvílovákratocha...@gmail.com
To: Paul Shapleyp.shap...@gmail.com
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] NVIZ Wire Mesh
Date: Thu, 26 Jan 2012 15:29:51 +0100
On Thu, Jan 26, 2012 at 2:09 PM, Paul Shapleyp.shap...@gmail.com wrote:
Hello,
I want to have the NVIZ wire mesh opaque but don't know how best to do this.
I don't want to be transparent. Does anyone know how this can be done?
Sorry but this is not possible. You can create a ticket to support
this behaviour but I'm afraid that nobody will work on it now.
Anna
Thanks,
--
Paul J. Shapley
___
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
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] overlapping areas seem valid to v.build: why?
be a strong expressed bias against other GIS systems which use a simple geometry model. It was certainly not my intention to suggest that GRASS is the only proper GIS. Different GIS have different design philosophies. Thus, they fit different use cases. I myself use more than one. Please don't allow discussions on technical functionality to devolve into this. You asked for opinions on a topic that goes well beyond the technicalities of v.in.ogr. Please see my notes further down. When I read something like, Well if you don't care about the quality of your data, go use another GIS system. I then seriously consider looking at the new PostGIS topological model, for example, for reasons that have NOTHING to do with the technical capability of either system. Having been part of the GRASS development team for a long time now, and having spent some time on improving v.in.ogr/v.out.ogr myself in the past, allow me to sum up: Without topological correctness (according to the GRASS data model, not PostGIS' or anybody else's), options for processing polygonal data in GRASS are severely limited. And it will not be possible to correctly manage complex polygons with islands/holes in them. Thus the man page for v.in.ogr states: -c Do not clean polygons (not recommended) So in fact you are asking for a modification to one of the most frequently used modules in GRASS that will *revert* the default behavior on which a lot of users (including myself) and shell scripts written by users to automate data analysis have come to rely. Using data with unchecked topology is possible via v.external. This module builds a pseudo topology that may be good enough in many cases. It works particularly well in GRASS 7. Thanks for all your hard work and commitment to this project, You are welcome. Thanks for your input. Best, Ben Roger -- Markus M Personally, I do not think this auto cleaning should ever have been made the default operation of the import tool. -- On Wed, Nov 30, 2011 at 9:37 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Moritz Lennert wrote: On 30/11/11 14:38, Markus Metz wrote: It seems to me that the confusion arises because you made use of features that allow you to skip topological cleaning which is not the default and not recommended. Maybe this calls for a v.check.topology module ? Or an option in v.build or v.clean which does that (i.e. just check, not clean) ? Good idea. I would opt for a new option/flag for v.build, which can already provide rather detailed diagnostics, e.g. dumping topology. Something like v.build -e for extended topology checks? Markus M ___ 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] Cannot get past Wiki captcha
Unfortunately, reCAPTCHA might be a victim of its own success - as of 2011, some spammers appear to have figured out a way to bypass it, either through character recognition or by using humans. For that reason, it is not necessarily recommended. I can confirm this. On another site that I manage, based on phpBB, I get unbelievable amounts of spambot requests to open accounts. Apparently, simple graphical captchas no longer hold them back. I think math captchas are a good idea. Plus, it's free brain exercise :) Cheers, Ben Part of the weakness of the ReCaptcha module is that ConfirmEdit doesn't include any penalty mechanism, so spam bots can simply keep trying to bypass the CAPTCHA until they get through. This is an issue that is strongly worth addressing in some way. Martin [1] http://www.mediawiki.org/wiki/Confirmedit -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
Thanks for looking into this, Martin.
Let's hope deactivating the captcha will have
no bad consequence in the form of spamming.
Cheers,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Sunday, November 20, 2011 3:16 PM, Martin Landa
landa.mar...@gmail.com wrote:
Hi,
2011/11/20 Benjamin Ducke bendu...@fastmail.fm:
Yes it does, so I guess the problem may be
the GRASS MediaWiki configuration/version.
unfortunately I cannot reproduce this problem (anyone here with
similar problem)? We are using recent version of Mediawiki [1] 1.17.0.
I have changed
$wgCaptchaTriggers['addurl']= true;
to
$wgCaptchaTriggers['addurl']= false;
It should help, Martin
[1] http://grass.osgeo.org/wiki/Special:Version
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
It's also possible to change the captcha plug-in.
Maybe a different one will work better:
http://www.mediawiki.org/wiki/Extension:ConfirmEdit
Also, there are some hints on that page about
problems with the captcha and WikiMedia dependencies.
Best,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Tuesday, November 22, 2011 3:10 PM, Martin Landa
landa.mar...@gmail.com wrote:
Hi,
2011/11/22 Hamish hamis...@yahoo.com:
why aren't we using the standard and very well tested debian
package for mediawiki?
that's simple, because than we would use for years (assuming that you
are not reinstalling OS when new stable Debian release will appear)
quite old version of mediwiki, in this case 1.12. Note that the
current version is 1.17. What's the problem with using recent *stable*
release of Mediawiki, which is BTW quite well tested to, at least for
Wikipedia? I am running several mediawikis from SVN (always recent
stable release) on Debian and I have no problem with that for last two
years. BTW, when updating your instance to the more recent version,
it's just matter of running `svn up` ;-)
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
Yes, but I was thinking about switching the
captcha type (the extension seems to support
several different ones). Who knows, maybe the
current captcha type conflicts with the system
setup.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Tuesday, November 22, 2011 3:25 PM, Martin Landa
landa.mar...@gmail.com wrote:
2011/11/22 Benjamin Ducke bendu...@fastmail.fm:
It's also possible to change the captcha plug-in.
Maybe a different one will work better:
http://www.mediawiki.org/wiki/Extension:ConfirmEdit
we already use this extension...
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
Yes it does, so I guess the problem may be
the GRASS MediaWiki configuration/version.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Friday, November 18, 2011 9:23 PM, Hamish hamis...@yahoo.com
wrote:
fwiw, I just tried editing
http://wiki.osgeo.org/wiki/Sandbox
and that did ask me to pass a captcha for the external
URLs added, and it worked.
does it work for you there?
it is not the same instance of MediaWiki, but at least
we can play spot-the-difference in the setups.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
@Ben: perhaps you are running NoScript or similar without the proper exemptions and that's blocking the all ok return signal? Hamish I tried on two different versions of plain Firefox, and made sure that cookies were enabled. I cannot see anything that could get in the way. But no luck, unfortunately. Maybe at some point another user will run into the same problem and then we might be able to see a pattern. Right now, I am clueless about this. It's the first time I am being refused by a wiki -- traumatic. Ben ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Cannot get past Wiki captcha
Hi list,
I am logged into the wiki and trying to save some
edits to this page:
http://grass.osgeo.org/grass-
wiki/index.php?title=GRASS_7_ideas_collection
Since I have included links to external web pages,
I am presented with a captcha. I solve the captcha,
hit enter and get presented with another captcha,
over and over again. Simply cannot get passed it.
I am on Firefox 7.0.1 with cookies enabled.
Any ideas what might be the problem?
Thanks,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
I just tried from a different machine, different
internet connection, Firefox 4, still the same
problem.
The captcha help text says these appear because
I have new links to external URLs in the text
(spam protection).
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Wednesday, November 16, 2011 10:55 AM, Martin Landa
landa.mar...@gmail.com wrote:
Hi,
2011/11/16 Benjamin Ducke bendu...@fastmail.fm:
I am logged into the wiki and trying to save some
edits to this page:
http://grass.osgeo.org/grass-
wiki/index.php?title=GRASS_7_ideas_collection
Since I have included links to external web pages,
I am presented with a captcha. I solve the captcha,
hit enter and get presented with another captcha,
over and over again. Simply cannot get passed it.
I am on Firefox 7.0.1 with cookies enabled.
strange, captcha are enable only when creating new account, they are
no required when editing wiki pages. Anyway I can edit wiki pages
without any problem, is there anyone having similar problems?
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
Similar. I tried to embed URLs
[http://myurl.org like this]
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Wednesday, November 16, 2011 11:19 AM, Martin Landa
landa.mar...@gmail.com wrote:
2011/11/16 Benjamin Ducke bendu...@fastmail.fm:
I just tried from a different machine, different
internet connection, Firefox 4, still the same
problem.
The captcha help text says these appear because
I have new links to external URLs in the text
(spam protection).
Something like
http://grass.osgeo.org/grass-wiki/index.php?title=Sandboxaction=historysubmitdiff=14396oldid=13386
?
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cannot get past Wiki captcha
OK, I have posted the text without the URLs for now.
That worked without problems.
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Wednesday, November 16, 2011 11:45 AM, Martin Landa
landa.mar...@gmail.com wrote:
2011/11/16 Benjamin Ducke bendu...@fastmail.fm:
Similar. I tried to embed URLs
[http://myurl.org like this]
as I sad before captcha shouldn't be enabled for editing. I cannot
reproduce this behaviour. Could some try it too? Eg. in
http://grass.osgeo.org/wiki/Sandbox
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ideas on how to handle 3D topology
Dear List --
I have sketched up some ideas on how to reduce the
complexity of 3D topology handling:
http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#3D_topology
I have some hope that it should be possible to implement
3D topological correctness in GRASS 7 and v.clean without
having to add a lot of code to the existing 2D methods.
I would be delighted to discuss the whole topic of 3D
topology, as I think it currently stands between GRASS
and more complex 3D vector data management/analysis.
Not sure if this mailing list or the wiki itself would
be the best place for discussion.
Best,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] measuring area on a 3d polygon
I think Michael's reply (see below) to my message is
actually the answer to your question ;)
Ben
On Wednesday, November 16, 2011 10:13 AM, Michael Barton
michael.bar...@asu.edu wrote:
r.surf.area
will calculate a topographically corrected area for rasters. So if you
convert your vector areas to raster, this will do the trick.
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
On Wednesday, November 16, 2011 11:01 AM, maning sambale
emmanuel.samb...@gmail.com wrote:
Hi,
I have a series polygons located in a mountainous terrain. I can
convert the 2d vector into 2.5d using v.drape and a DEM, however, it
only converts 2D vector point or line data and not areas. My task is
to calculate the area in hectares of the polygon incorporating the
elevation/surface of the polygon. I then need to subdivide the main
polygon into smaller polygons using a preferred area in hectares.
How to calculate 2.5d polygon areas in grass?
--
cheers,
maning
--
Freedom is still the most radical idea of all -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
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] i.pca fixes in trunk
Sounds like a very sensible couple of fixes to me.
Could these be backported to 6.4.x?
Cheers,
Ben
On 11/04/2011 11:53 AM, Markus Metz wrote:
Hi all,
based on the wiki for Principal Components Analysis [0], numerous
discussions in the mailing lists [1,2,3,4], particularly a comment by
Edzer Pebesma [5], and personal demand, I have fixed a few issues in
i.pca in trunk r49090.
- the faulty or missing centering of the input bands described in [0]
for should be fixed
- i.pca has a new flag -n to normalize input bands with (x - mean) / stddev
- values of the output maps are now calculated depending on the input
band transformation (centering or normalization). Is this OK?
- Eigen values, (vectors), and [percent importance] are now written to
stdout instead of stderr
The results of i.pca for the examples using SPOT imagery in the wiki
[0] are now identical to R's princomp() results. If the new -n flag is
used, the results of i.pca are identical to princomp(center = TRUE,
scale = TRUE).
Tested also with 9 input maps in a region with 400 million cells.
Markus M
[0] http://grass.osgeo.org/wiki/Principal_Components_Analysis
[1] http://lists.osgeo.org/pipermail/grass-user/2009-February/048722.html
[2] http://lists.osgeo.org/pipermail/grass-stats/2009-March/000933.html
[3] http://lists.osgeo.org/pipermail/grass-stats/2009-March/000942.html
[4] http://lists.osgeo.org/pipermail/grass-stats/2009-April/001028.html
[5] http://lists.osgeo.org/pipermail/grass-stats/2009-April/000977.html
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to generate a bigger PNG file
You can simply increase the resolution of your
current working region. Then you will get more
cells (and a bigger image) but exactly the same
information.
Ben
On 11/03/2011 01:16 PM, Luisa Peña wrote:
Greetings
I'm using r.out.png to generate PNG files from a small patch (like 6x15
pixels) but I'm obtaining a really small PNG file. Sicne I want to
display it a little bit bigger in a website I need to create a bigger
(in size) PNG. What can I do to do this?
One idea was to rescale it in a image processing software but I get a
low quality image
Is there any solution by using grass?
Thanks
Luisa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Draping of Raster images
You can only drape one raster over another (e.g.
to combine the colour information in an airphoto
with the elevation information in a DEM) in the
context of a visualization software like NVIZ
(which does the same stuff ArcScene does for ArcGIS).
If you want to turn 3D elevation vector points
into a raster with elevation values, use one
of the v.surf.* interpolation modules.
Ben
On 11/03/2011 03:32 PM, Anna Hodgkinson wrote:
Thank you, but neither of those would work for me - what I'm trying to do is to
make a 2D raster image 3D.
And I don't mean visualisation, I mean assigning cell values for elevation from
either another 3D surface or vector layer (both of which I have).
Sorry!
Anna
- Original Message -
From: Saber Razmjooeirazmjoo...@faunalia.co.uk
To: Anna Hodgkinsonanna.hodgkin...@thehumanjourney.net
Cc: Saber Razmjooeirazmjoo...@faunalia.co.uk, grass-user
grass-usergrass-user@lists.osgeo.org
Sent: Thursday, 3 November, 2011 2:21:23 PM
Subject: Re: [GRASS-user] Draping of Raster images
Alternatively, you can use:
r.shaded.relied
That will be 2D only.
Thanks, but there doesn't seem to be a way of elevating a 2D raster
surface. Do you have any experience with this, and would know what
command to use?
Many thanks,
Anna
- Original Message -
From: Saber Razmjooeirazmjoo...@faunalia.co.uk
To: Anna Hodgkinsonanna.hodgkin...@thehumanjourney.net
Cc: grass-user@lists.osgeo.org
Sent: Thursday, 3 November, 2011 1:52:36 PM
Subject: Re: [GRASS-user] Draping of Raster images
This page might be helpful:
http://grass.osgeo.org/wiki/Help_with_3D
Cheers
Saber
Dear all,
I was wondering whether it is possible to use GRASS to drape raster
images over existing 3D surfaces or vector layers.
I know ArcGIS is capable of this, is seems a fairly straight-forward
procedure there
(http://webhelp.esri.com/arcgisdesktop/9.3/tutorials/3D_analyst/3D_5.htm),
so I was hoping to achieve the same using open source GIS.
GRASS has a v.drape module, which can drape vector layers over 3D
surfaces, NVIZ seems to do the same.
It would be great if someone could tell me that GRASS (or any other
open source GIS package) is capable of draping raster images over
either other
rasters or vectors containing elevation information.
Many thanks and all the best,
Anna
__ Anna Kathrin
Hodgkinson MA MSt (Oxon) AIFA EES
Supervisor Geomatics
Oxford Archaeology: Exploring the Human Journey
Mobile: +44 (0)7906 638308 (personal)
Direct Dial: +44 (0)1865 980 855
http://thehumanjourney.net
Files attached to this email may be in ISO 26300 format (OASIS Open
Document Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.
This email has been processed by SmoothZap - www.smoothwall.net
___ grass-user mailing
list grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Files attached to this email may be in ISO 26300 format (OASIS Open
Document Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.
This email has been processed by SmoothZap - www.smoothwall.net
Files attached to this email may be in ISO 26300 format (OASIS Open Document
Format). If you have difficulty opening them, please visit http://iso26300.info
for more information.
This email has been processed by SmoothZap - www.smoothwall.net
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr of a 3d shape
You have 3D polygons in your input data.
Getting 3D polygon data into GRASS can be
tricky.
Since GRASS uses a 2D topology model for
polygons, it will butcher all 3D polygons that
do not overlap in 3D space, but do so from a 2D
perspective. It will also have trouble with
polygons that extend only along the Z axis
and have no X-Y area.
Even if you manage to get the data into
GRASS using v.in.ogr's -c flag, you won't
be able to do much with it, because the result
will not have a valid GRASS topology.
If import into GRASS fails, you basically
have two choices:
1. Import polygons as polylines (use the
type option in v.in.ogr). But that of
course will modify your geometries.
2. Use GRASS7 and v.external to attach
the Shapefile directly (GRASS 6.4 cannot
attach 3D vector data sources).
Best,
Ben
Btw. QGIS has a strictly 2D vector data model, so
that won't get you anywhere.
On 10/14/2011 05:19 PM, Markus Metz wrote:
Sebastian Schubert wrote:
Hi,
I want to read a 3d shape. Unfortunately, it does not finish (killed
after 2 hours!). Qgis is able to import it although I guess it is done
in 2d what grass is also capable of without the -z switch. Here is the
output with grass 6.4.1:
v.in.ogr --v -z dsn=St_Flaeche_3D.shp out=basel3d
Projection of input dataset and current location appear to match
Using temporary vectorbasel3d_tmp
Layer: St_Flaeche_3D
Counting polygons for 1192679 features...
Boundary splitting distance in map units: 176.386
Importing map 1192679 features...
100%
-
Building topology for vector mapbasel3d_tmp...
Registering primitives...
397678 primitives registered
1549444 vertices registered
Topology was built
Number of nodes: 268594
Number of primitives: 397678
Number of points: 0
Number of lines: 0
Number of boundaries: 397678
Number of centroids: 0
Number of areas: -
Number of isles: -
-
WARNING: Cleaning polygons, result is not guaranteed!
-
Break polygons:
100%
100%
-
Remove duplicates:
100%
-
Break boundaries:
100%
Intersections: 239035
-
Remove duplicates:
100%
-
Clean boundaries at nodes:
-
Break boundaries:
100%
Intersections: 22
-
Remove duplicates:
100%
-
Clean boundaries at nodes:
-
Break boundaries:
100%
Intersections: 0
-
Remove duplicates:
100%
-
Clean boundaries at nodes:
-
Change dangles to lines:
100%
-
Remove bridges:
99%
Here it stops to produce output but still there is 100% CPU usage. Any idea?
Yes. It takes very long because of a high number of potential bridges.
This can happen with some larger vector files and processing speed has
been improved in 6.4.2 and above. Please try 6.4.2RC1 if possible.
Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] use nnbathy 1.96 as stand alone in windows7?
You could probably use MinGW-win64 and MSYS directly on Windows 7. The two of them together provide all you need to run Unix-style configure scripts and compile C/C++ source code on Windows (in 32 and 64 bits). It's a much leaner option than Cygwin. I have recently documented how to set up the two on the gvSIG CE Wiki. You might be able to make use of these instructions, as well: http://gvsigce.sourceforge.net/wiki/index.php/Setting_up_the_GNU_Compiler_Collection http://gvsigce.sourceforge.net/wiki/index.php/Getting_started_with_MSYS Best, Ben - Original Message - J Layug wrote: Please bear with me as I'm new to GRASS. I want to interpolate 3D vectors points to create a raster DEM using the natural neighbor method. Can I compile and run nnbathy 1.96 in windows 7 as an executable file without using the GRASS GIS platform? nnbathy does not require GRASS to build or run, they are completely separate. as to if nnbathy can be ported to build on Windows7, I don't know, but I'd note that the configuration script is based on UNIX autoconf, which would suggest MacOSX and Linux as the target platforms. I would guess that you could install Cygwin onto your Windows7 computer and build it in there, but for that some UNIX experience is useful. Alternately you could install Ubuntu in a VirtualBox VM and jump into the virtual machine to do your processing then copy the results file back out to your normal MS Windows environment. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] mentor required to help publish a GRASS addon (DEM)
Dear Rebecca, I have recently worked on a number of GRASS shell scripts for signal processing (also with archaeological applications in mind). Email me your script and note, or (provided it's not very large), attach and email it to this list. I will have a look at it to see if it needs any improvements and test it on Windows and Mac OS X (not this week, though). Have you written a manual page for it yet? Cheers, Ben - Original Message - Dear GRASS users, I have been working on automating a technique known as Local Relief Modelling (see http://www.ag-caa.de/caanlde/paperdownload/hesse.pdf ). The process allows the extraction of microtopographic changes from a DEM (in this case archaeological remains) and is very useful in areas of large topographic variation e.g mountain ranges where small scale features are masked by large shadows in shaded relief models. I have written and extensively tested a bash script in GRASS 6.4 as part of my doctoral work and would like to make it publicly available so that other researchers can access and use this tool. To do this I need a mentor, so I was wondering if anyone could spare a few hours to help me? I look forward to hearing from you, Best wishes, Rebecca Bennett Postgraduate Researcher (Archaeology Group) School of Applied Sciences, Bournemouth University ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)
Hm-hm. Citing from the website: The problem is that the ratio of change due to air to curvature is not 1:7 (0.13), as the standard refraction coefficient suggests. It is 0.325. As far as I can tell, this is a mis-understanding. The value 0.325 applies to radio waves. Visible light is very close to 1:7. You can read up on the arguments here: http://forums.esri.com/Thread.asp?c=3f=40t=161962#474778 There is also some more information in that forum thread regarding more realistic modelling of refraction under different atmospheric conditions. I realize the whole discourse is somewhat clouded. But I don't have access to most of the relevant literature for the time being, nor do I have the necessary scientific background -- so any fresh input will be much appreciated! Btw.: using r.ecurv.comp, one can freely specify the atmospheric correction factor. [...] But given that most DEMs have an inherent vertical error that is greater than the influence of these effects, can we quantify that? for example what's STRM 95% confidence accuracy? From Farr et al. 2007: Summary of SRTM performance. All quantities represent 90% errors in meters. Africa Australia Eurasia Islands N. America S. America Absolute Geolocation Error 11.9 7.2 8.8 9 12.6 9 Absolute Height Error 5.6 6 6.2 8 9 6.2 Relative Height Error 9.8 4.7 8.7 6.2 7 5.5 Long Wavelength Height Error 3.1 6 2.6 3.7 4 4.9 [sorry for the ugly format, it's tab separated] What I wold love to see is a method for probabilistic viewsheds, which adds random +/- offsets (within the vertical error range) to the elevation model cells, runs the viewshed computations several times, each time with new random offsets, then outputs the average visibility of each cell after n runs (not sure how best to determine n). That would be much more realistic than those over- confident 0/1 viewsheds. Such a method could even take into account roughly modelled blocks of vegetation or other obstacles for which height is hard to quantify precisely. -- shouldn't be too hard to implement in a little script. Ben I am not sure it's worth spending too much time on (it might be for very long distance visibility -- I just don't know). it would be good for us to do a rough back of the envelope calc to justify that before fully forgetting about it. I guess for the worst case scenario we could try the views from Mt. Everest and/or Olympus Mons and see what difference it makes. No need to go into mountains, just increase observer elevation offset, preferably in a moderately flat area to get really far views. Using correction for earth curvature only, max is a bit more than 100 km with 3km observation offset. 200km is impossible without leaving earth's atmosphere. Markus M -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)
- Original Message - Hamish wrote: [..] ok, done for r.viewshed in r46423. Number of visible cells reduces slightly when the curvature flag is used, and rebounds ever so slightly when the refraction flag is used. Please test. Cool, that's what one would expect. Reassuring. Well, that refraction correction is really a rough simplification of reality. Essentially, it uses the same amount of correction as ArcGIS. There is some justification for this. You can find links to articles here: http://mapaspects.org/content/effects-curvature-earth-refraction-light-air-and-fuzzy-viewsheds-arcgis-92 I could not get at the Yoeli(1985) article as it's behind a paywall my univ does not subscribe to. Can anyone say what's in it? But in summary, accounting for realistic refraction conditions would be much more complex, as it would also have to take into plus different refraction at different elevations, etc. I don't mind that / it is not so different from the physics I do in my day job, and just using a fudge factor of +1/7th leaves me feeling like the job is poorly done. Passing the coeff off to the user without further guidance seems like a bit of a cop out. I suppose there is a gradient in the coeff as you move from the tropics to high latitudes, daily temperature, Linke factor, humidity, aerosols, etc ... ? I am sure there is. But I lack the background to judge this correctly. But given that most DEMs have an inherent vertical error that is greater than the influence of these effects, can we quantify that? for example what's STRM 95% confidence accuracy? [I think this needs a probabilistic approach, see my other reply to this thread.] I am not sure it's worth spending too much time on (it might be for very long distance visibility -- I just don't know). it would be good for us to do a rough back of the envelope calc to justify that before fully forgetting about it. I guess for the worst case scenario we could try the views from Mt. Everest and/or Olympus Mons and see what difference it makes. -- that would rock :) Ben thanks, Hamish -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)
- Original Message - On Thu, May 26, 2011 at 12:26 PM, Benjamin Ducke benjamin.du...@oxfordarch.co.uk wrote: Hm-hm. Citing from the website: The problem is that the ratio of change due to air to curvature is not 1:7 (0.13), as the standard refraction coefficient suggests. It is 0.325. As far as I can tell, this is a mis-understanding. The value 0.325 applies to radio waves. Visible light is very close to 1:7. What if I am interested in radio waves, not visible light, e.g. for antenna relay positions? IMHO, that refraction coefficient should not be hard-coded. Agreed. It's a settable value in r.ecurv.comp and should also be one in all GRASS modules that have refraction compensation. Ben I realize the whole discourse is somewhat clouded. But I don't have access to most of the relevant literature for the time being, nor do I have the necessary scientific background Me neither. But any correction should take into account that the observer is not necessarily a human without optical equipment (telescope etc), but can also be some technical device, e.g. a sender or receiver of whatever signals. my .2c Markus M -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)
[snip] However, after some testing and comparison with the output of ArcGIS' Viewshed module, I can now confirm that the correction method works just fine. It gives confidence sure, but there's no way of knowing if their black box is actually correct or not, maybe we make the same mistakes? :) All the better to follow/cite published articles. Of course, that will always be a problem. But I have compared three independent methods: r.los with built-in correction, ArcGIS with built-in correction, and r.ecurv.comp. In general, the outputs are very similar, even down to small detail. The remaining differences must be in implementation details and the fact that r.los does not implement atmospheric refraction. I have also run some of the LOS algorithms in SEXANTE (on a DEM that was processed with r.ecurv.comp, since they lack any built-in correction). Again, results were very much the same as r.los and ArcGIS. Only ArcGIS outputs those contiguous viewsheds, though. So they must have done something to tune the output. certainly the ideal solution is to have both curvature and refection corrections implemented as flags in the new improved r.viewshed. (say, is that now ready for moving into grass7? *) That should be really easy to do. All that's needed is to amend the existing correction but taking away 1/7 to account for the adverse effect of refraction. Does refraction only work in the vertical or would you be able to slightly see around some distant volcano horizontally? ..perhaps the phenomenon is related to the atm pressure gradient, in which case purely a vertical-only effect..? Well, that refraction correction is really a rough simplification of reality. Essentially, it uses the same amount of correction as ArcGIS. There is some justification for this. You can find links to articles here: http://mapaspects.org/content/effects-curvature-earth-refraction-light-air-and-fuzzy-viewsheds-arcgis-92 (@Markus N: maybe that answers your question, as well?) But in summary, accounting for realistic refraction conditions would be much more complex, as it would also have to take into plus different refraction at different elevations, etc. But given that most DEMs have an inherent vertical error that is greater than the influence of these effects, I am not sure it's worth spending too much time on (it might be for very long distance visibility -- I just don't know). Do you think that noise happens because of a translation of the coarse horizontal grid cell size when it is translated into the vertical plane? That's a really interesting thought. It could very well be a quantization effect of that kind. That might explain why the noisy patches seem to show structural features of the DEM. Cheers, Ben -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] I need some help to import a GIS file to GRASS64
Are you sure you have the right extents? Try g.region rast=puertoRico then display again. Also, you could try: r.info puertoRico to get the raster statistics and extent and check if it makes sense. Are you on Windows? The output below shows that the map is being written to a PNG output file. Did you check that file? Cheers, Ben - Original Message - Hello! My name is Ivan. I have been trying to import a GIS raster flie to GRASS64. I do the next proucedure in Ubuntu 10.04: -I run grass64 -I define a new location using the EPSG code: 32161 (based in the information at the end of this email) -When Grass asks me: Select datum transformation parameters, I choose the second one: (Used in whole nad83 region. towgs84 = 0.000, 0.000, 0.000) -Then I enter in the PERMANENT folder. And then I do this: r.in.gdal input=/home/ivan/grassdata/prgap_landcover.img output=puertoRico Projection of input dataset and current location appear to match r.in.gdal complete. Raster map puertoRico created. d.rast map=puertor...@permanent -o PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/ivan/grassdata/pr/PERMANENT/.tmp/ivan-laptop/6771.0.ppm, GRASS_WIDTH=642, GRASS_HEIGHT=482 g.pnmcomp in=6771.2.ppm mask=6771.2.pgm opacity=1.0 background=255:255:255 width=642 height=482 output=6771.1.ppm d.rast map=puertor...@permanent -o PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/ivan/grassdata/pr/PERMANENT/.tmp/ivan-laptop/6771.0.ppm, GRASS_WIDTH=482, GRASS_HEIGHT=482 g.pnmcomp in=6771.2.ppm mask=6771.2.pgm opacity=1.0 background=255:255:255 width=482 height=482 output=6771.1.ppm g.region n=18.529654 s=17.874067 e=-65.218506 w=-67.957335 rows=4793 cols=19279 nsres=15 ewres=15 tbres=1 d.rast map=puertor...@permanent -o PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/ivan/grassdata/pr/PERMANENT/.tmp/ivan-laptop/6771.0.ppm, GRASS_WIDTH=482, GRASS_HEIGHT=482 g.pnmcomp in=6771.2.ppm mask=6771.2.pgm opacity=1.0 background=255:255:255 width=482 height=482 output=6771.1.ppm g.pnmcomp in=6771.2.ppm mask=6771.2.pgm opacity=1.0 background=255:255:255 width=482 height=482 output=6771.1.ppm d.rast map=puertor...@permanent -o PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/ivan/grassdata/pr/PERMANENT/.tmp/ivan-laptop/6771.0.ppm, GRASS_WIDTH=482, GRASS_HEIGHT=482 g.pnmcomp in=6771.2.ppm mask=6771.2.pgm opacity=1.0 background=255:255:255 width=482 height=482 output=6771.1.ppm d.rast map=puertor...@permanent -o PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/ivan/grassdata/pr/PERMANENT/.tmp/ivan-laptop/6771.3.ppm, GRASS_WIDTH=642, GRASS_HEIGHT=154 g.pnmcomp in=6771.5.ppm mask=6771.5.pgm opacity=1.0 background=255:255:255 width=642 height=154 output=6771.4.ppm The problem is that the Map Display is in blank. If you want to try it, you can donwload the file from ftp://ftp.gap.uidaho.edu/products/Puerto_Rico/GISdata/Landcover/1_Land_cover_grid/ the file is prgap_landcover.zip , and inside you will find the a .img file Here I add more Information: Spatial_Domain: Bounding_Coordinates: West_Bounding_Coordinate: -67.957335 East_Bounding_Coordinate: -65.218506 North_Bounding_Coordinate: 18.529654 South_Bounding_Coordinate: 17.874067 Spatial_Data_Organization_Information: Direct_Spatial_Reference_Method: Raster Raster_Object_Information: Raster_Object_Type: Pixel Row_Count: 4793 Column_Count: 19279 Vertical_Count: 1 Spatial_Reference_Information: Horizontal_Coordinate_System_Definition: Planar: Map_Projection: Map_Projection_Name: Lambert Conformal Conic Lambert_Conformal_Conic: Standard_Parallel: 18.03 Standard_Parallel: 18.43 Longitude_of_Central_Meridian: -66.43 Latitude_of_Projection_Origin: 17.83 False_Easting: 20.00 False_Northing: 20.00 Planar_Coordinate_Information: Planar_Coordinate_Encoding_Method: row and column Coordinate_Representation: Abscissa_Resolution: 15 Ordinate_Resolution: 15 Planar_Distance_Units: meters Geodetic_Model: Horizontal_Datum_Name: North American Datum of 1983 Ellipsoid_Name: Geodetic Reference System 80 Semi-major_Axis: 6378137.00 Denominator_of_Flattening_Ratio: 298.257222 Entity_and_Attribute_Information: Detailed_Description: Entity_Type: Entity_Type_Label: Layer_1 Attribute: Attribute_Label: ObjectID Attribute_Definition: Internal feature number. Attribute_Definition_Source: ESRI Attribute_Domain_Values: Unrepresentable_Domain: Sequential unique whole numbers that are automatically generated. Attribute: Attribute_Label: Value Attribute_Definition: A number assigned to each specific land cover class or type. Attribute: Attribute_Label: Red Attribute: Attribute_Label: Green Attribute: Attribute_Label: Blue Attribute: Attribute_Label: Class_names Attribute_Definition: Land cover types Attribute: Attribute_Label: Opacity Attribute: Attribute_Label:
Re: [GRASS-user] AdvancedViewshedAnalysis
Hi Becky, The installation manual: ftp://88.208.250.116/gvSIG_OADE_Installation.pdf has some details about setting up the software on the Mac. See section 4: If you have ticked the GRASS GIS option in the installer, then the folder you need to specify is within the App folder of gvSIG OADE 2010 on your Mac: Contents/Resources/grass. If you are using a Mac, you should definitely read through the Mac specific section of the PDF manual above and also the Mac section on the support page here: http://www.oadigital.net/software/gvsigoade/gvsigbugs This version of gvSIG has been developed to run on Mac OS X Snow Leopard and Intel hardware. Anything older than that will probably require some extra fiddling to make it work. Best, Ben - Original Message - I've now downloaded gvSIG OADE 2010. Thanks for putting me on to this by the way it's brilliant! However, I'm struggling to setup GRASS in SEXTANTE settings window. Doesn't recognise GRASS GIS installation folder (error message 'The selected folder does not contain a valid GRASS installation') or perhaps what i mean is that I don't know where the GRASS installation folder is on the mac. I've tried several different options, but all give same error message. Any help would be great. Cheers Becky Dr Rebecca Rennell Uist Archaeology www.uistarchaeology.com be...@uistarchaeology.com Date: Fri, 13 Aug 2010 15:45:05 +0100 From: benjamin.du...@oxfordarch.co.uk To: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] AdvancedViewshedAnalysis Hi Becky, if you want to have it super easy, download and install gvSIG OADE 2010: http://www.oadigital.net/software/gvsigoade When you run the installer, make sure to tick all available extensions, so you get the SEXTANTE and GRASS geoprocessing tools. Full instructions are here: ftp://88.208.250.116/gvSIG_OADE_Installation.pdf A quickstart guide for gvSIG is also available: ftp://88.208.250.116/gvSIG_OADE_Quickstart.pdf ... but surely, someone at your department is already using gvSIG? You can then run a large number of GRASS modules directly via the SEXTANTE graphical user interface. r.cva and r.promincence are already included. Best, Ben On 08/13/2010 12:38 PM, Rebecca Rennell wrote: Hi GRASS-Users Apologies for cross-posting. My difficulty is with install AdvancedViewshedAnalysis extension using GEM within GRASS 6.4.ORC6 command 'gem6' is not recognised command 'gem install AdvancedViewshedAnalysis.tar' produces the following error message ERROR: Could not find a valid gem 'AdvancedViewshedAnalysis.tar' (= 0) in any repository I have an older version of GRASS (GRASS 6.3.0). From here the command 'gem6 -i AdvancedViewshedAnalysis.tar -v' begins to install and then aborts with the following error message: ERROR: Compilation failed for these module(s): /private/tmp/grass.extension.Mngj89/AdvancedViewshedAnalysis/src/raster/r.cva /private/tmp/grass.extension.Mngj89/AdvancedViewshedAnalysis/src/raster/r.prominence Run 'make' manually in each module's directory for details. make: *** [default] Error 1 I've now run make in both modules (I think), but I still get the same error message. I also don't understand why the tar file is recognised from GRASS 6.3 but not 6.4. I'm almost certainly doing something very stupid - any help gratefully received! Thanks Becky grass-user@lists.osgeo.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Opensource and pretty maps design anybody?
I think that of all open source GIS, gvSIG currently has the most advanced interactive map production facilities: http://www.oadigital.net/software/gvsigoade It has very advanced labeling modes, flexible symbology and symbol levels, and also comes with a complete map layout GUI. The version above also comes with integrated GRASS GIS 6.4, so you can directly map your GRASS data into a gvSIG data view and map layout. My colleagues have informed me that they can produce high-quality maps by exporting to PS/PDF and then doing the final retouching in Inkscape (of which the latest version is due any day now). Best, Ben On 08/17/2010 08:12 PM, kapo coulibaly wrote: Thank you all for your suggestions. I've used qgis quite a bit, it has a nice GUI but it is not very good with pretty maps. I'll give the SVG format, GMT and other graphic softwares a try. But how do you handle large numbers of feature (contour labeling)? It can be pretty tedious if you are going to cycle through various attributes attached to the same features. I think there is a case to be made that there is a gap to be filled. Opensource GIS software (Grass GIS, qGIS, Mapwindow, Saga...etc) could use some enhancement in this department. On Tue, Aug 17, 2010 at 11:59 AM, Malte Martin ma...@perlomat.de wrote: QGIS? http://www.qgis.org/en.html It comes along with a GRASS Plugin so you can use GRASS datasets. Malte Am 17.08.2010 um 17:56 schrieb kapo coulibaly: I've been using opensource GIS for a while (GRASS a lot). But they are all very limited when it comes to creating nice maps. I always have to resolve to using ArcGIS to put final touches on maps. Anybody has a suggestion for a free software to use for map design? ___ 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 -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help in Defending FOSS SDI
Hi Ravi, sorry about the late reply, but maybe some of the presentations and reports we have on the OA Digital website will provide some useful material/arguments for you: http://www.oadigital.net/research Current GIS software, proprietary or open source, has so much functionality that you can always make one or the other look like the winner, depending what application area you focus on. At OA Digital, we have tried to focus on arguing three strong points that open source solutions have, no matter what the particular features may be: 1. Economic suistanability: licensing fees have no merits for the customer past their expiration date. Once that is reached, all former investment is automatically invalidated. On the other hand, investing into open source development and staff skills instead of licenses has long-term merits and is suistanable. 2. Modular functionality: it's all there. If not in one package than via a combination of several. If something is still missing: hire a programmer to add it. It's also really easy to build automatic, very efficient data processing workflows from small open source components using scripts etc. 3. Interoperability: it's really easy to exchange data among open source applications, because they respect open standards and don't drop older file formats just to force customers to upgrade. By contrast, proprietary applications just try to lock you into them by using undisclosed file formate (so called vendor lock-in). This is one of the most important points, because the future of GIS is in spatial data infrastructures (SDI), where the data is at the centre of all planning and management and the GIS applications become more and more interchangeable. Hope this will provide some support arguing your points for open source software. You have to realize that the big GIS vendor (let's not kid ourselves: there really is just one and they have a suffocating monopoly on the market) will have about 1000 x the resources to put into marketing, brochures, shiny packages, lobbying and high-ranking political connections. So this is always an uphill struggle, no matter how clear the open source advantages are to the informed mind. Good luck! Ben On 08/02/2010 12:31 AM, Ravi wrote: Some so called SDI experts feel that FOSS SDI cannot perform at-par with Proprietary SDI. Please provide examples to fight a case from an Indian state which swears by Free and Open Source Software. We can never expect a better level playing field. Kerala - India Here are some excerpts from a document that has false claims supporting Proprietary Software. However, it is worthwhile to mention here that the OSS (Open Source Software) does not match the advanced functionalities of many of the commercial (proprietory) software that is in the market. Image processing and analysis capabilities of the open source software is not comparable to the commercial software when one require to carry out advanced data manipulations, image fusion, 3D modeling, ortho-correction, auto-georeferencing, stereo-image/air photo interpretation (PROBABLY REFERRING TO GRASS), advanced geospatial analysis etc., In such cases, certain proprietary software become an integral part of the Spatial Data Infrastructures, which can not be avoided. At a later stage the some of the proprietary software need to be purchased. It is a well known fact that web portal that run with OSS are neither OGC-compliant nor interoperable(PostGIS and Webservers to react). At the present juncture it is only possible to establish the KSDI Geoportal with the available COTS enterprise software. The detailed PDF document will be emailed on demand. This is a case that has the potential to set trends in India. Hope to have a good discussion such that we can sum it up and present at a meeting being conducted on August 11th 2010, to settle the issue. Ravi Kumar ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] gvSIG OA Digital Edition 2010 out now with GRASS GIS support
http://oadigital.net OA Digital are proud to announce the immediate availability of gvSIG OADE 2010, the user-friendly, open source GIS that gives you freedom, functionality and flexibility. Following two beta versions and extensive testing at sites around the world, this release represents a stable, feature-rich GIS desktop application, second to none in its data management and geoprocessing capabilities. This version is based on the source code of gvSIG 1.10, as developed by CIT Valencia and others. We would like to thank them all for their great work making user-friendly, cross-platform and open source GIS a reality. For installation instructions, support and downloads: http://www.oadigital.net/software/gvsigoade This software runs on Windows, Linux and Mac OS X. - NEW FEATURES - Perhaps the most exciting new feature in this release is the integration of nearly 180 GRASS GIS raster and vector processing modules. See here for an overview of other features: http://www.oadigital.net/software/gvsigoade/gvsigfeaturesprobs - ABOUT THIS EDITION OF GVSIG - GvSIG OADE 2010 differs from the official CIT gvSIG 1.10 release in the following respects: - completely new installer frontend - includes latest Java Runtime Environment - reworked menu structure, keyboard shortcuts and layer context menus - better integration into all supported operating systems - comes with SEXTANTE 0.6 and GRASS GIS 6.4 integrated - additional documentation and sample data - fully self-contained; can e.g. run from a removable USB device - WE WOULD LIKE TO HEAR FROM YOU - If you are using gvSIG OADE as part of your research, teaching or business, we would like to hear from you! Let us know what you, your department or company use gvSIG for and your motivation for using the software. -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] gvSIG OADE 2010 with GRASS GIS support released
http://oadigital.net OA Digital are proud to announce the immediate availability of gvSIG OADE 2010, the user-friendly, open source GIS that gives you freedom, functionality and flexibility. Following two beta versions and extensive testing at sites around the world, this release represents a stable, feature-rich GIS desktop application, second to none in its data management and geoprocessing capabilities. This version is based on the source code of gvSIG 1.10, as developed by CIT Valencia and others. We would like to thank them all for their great work making user-friendly, cross-platform and open source GIS a reality. For installation instructions, support and downloads: http://www.oadigital.net/software/gvsigoade This software runs on Windows, Linux and Mac OS X. - NEW FEATURES - Perhaps the most exciting new feature in this release is the integration of nearly 180 GRASS GIS raster and vector processing modules. See here for an overview of other features: http://www.oadigital.net/software/gvsigoade/gvsigfeaturesprobs - ABOUT THIS EDITION OF GVSIG - GvSIG OADE 2010 differs from the official CIT gvSIG 1.10 release in the following respects: - completely new installer frontend - includes latest Java Runtime Environment - reworked menu structure, keyboard shortcuts and layer context menus - better integration into all supported operating systems - comes with SEXTANTE 0.6 and GRASS GIS 6.4 integrated - additional documentation and sample data - fully self-contained; can e.g. run from a removable USB device - WE WOULD LIKE TO HEAR FROM YOU - If you are using gvSIG OADE as part of your research, teaching or business, we would like to hear from you! Let us know what you, your department or company use gvSIG for and your motivation for using the software. -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Entering point data with SQLite
On 06/28/2010 09:52 PM, Kurt Springs wrote: Also, I have been using SQLite Database Browser 1.3. It doesn't place the rows of field names in the order they are created. In fact there seems to be no order at all and no way to rearrange the order. I have found http://sqlitestudio.one.pl to be an extremely useful open source solution for SQLite DB management. Also, the author is very friendly and prompt to accommodate wishes for additional functionality. Have you considered simply using v.in.ogr/v.out.ogr to manage the data in an external SQLite3 database? Starting with GRASS 6.5.svn and GDAL 1.7, this should work well. Cheers, Ben As always, any help will be greatly appreciated. Kurt ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQLite connection - error
Hi Espen, the regular SQLite tables driver does not support geometry storage in SQLite databases. If you want to connect to a spatially enabled SQlite3 database, use v.in.ogr instead. Cheers, Ben - Original Message - Hi! I have tried to read the documentation and the mailing list for how to connect to a SQLite database. So far I have done this: 1. db.connect driver=sqlite database='/home/espen/db.sqlite' 2. Created a new vector map called test 3. v.db.connect map=test table=GSHHS_f_L2 -o key=PK_UID However I get this warning: WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: column 'Geometry', SQLite type 2 is not supported WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: column 'Geometry', SQLite type 2 is not supported The table GSHHS_f_L2 is now part of vector map test and may be deleted or overwritten by GRASS modules And running v.info map=test show that the layer does not have any objects ++ | Layer: test | | Mapset: PERMANENT | | Location: newLocation | | Database: /home/espen/Dokumenter/grassdata | | Title: | | Map scale: 1:1 | | Map format: native | | Name of creator: espen | | Organization: | | Source date: Wed Jun 23 08:55:30 2010 | || | Type of Map: vector (level: 2) | || | Number of points: 0 Number of areas: 0 | | Number of lines: 0 Number of islands: 0 | | Number of boundaries: 0 Number of faces: 0 | | Number of centroids: 0 Number of kernels: 0 | || | Map is 3D: No | | Number of dblinks: 1 | || | Projection: Lat/Lon | | N: 0 S: 0 | | E: 0 W: 0 | || | Digitization threshold: 0 | | Comments: | || ++ Could anybody explain to me what the warning means, and why I cannot access the features? The only thing i can guess is that I can only use version 1 of SQLite? However, I am not familiar with the different versions of SQLite. Kind regards, Espen Isaksen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQLite connection - error
No, unfortunately you are right. This is not an option for you. There is some severe inefficiency in the way v.in.ogr handles attribute and geometry data during import, which makes the whole process slow. Unfortunately, no one has yet stepped forward to re-design the logics (as far as I am aware). Ben - Espen Isaksen espen.isak...@gmail.com wrote: My understading from this page is that it is not possible to compile OGR with Grass write support? http://gdal.org/ogr/ogr_formats.html Am I wrong? This might indicate that write support is possible: http://grass.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin Espen 2010/6/24 Benjamin Ducke benjamin.du...@oxfordarch.co.uk: You could try compiling GDAL with GRASS support and using ogr2ogr directly to convert from the external format to GRASS. Ben - Original Message - Thanks Achim and Ben for your quick answers! I never even thought about that(a bit embarrassing really :-) ) I suppose that means I am back to the horribly slow import through v.in.ogr. Practically impossible for me to import a 100 mb shapefile. If anybody has suggestions for good performance, please go ahead and tell me. Espen 2010/6/24 Achim Kisseler achim.kisse...@jupiter.uni-freiburg.de: This is because SQLite is not SpatiaLite (SQLite with spatial extension). GRASS does not support SpatiaLite as far as I know. If you just want to use the Data from Spatiallite, you can export the tables as shape-files or csv and import these to GRASS. Hope it helps a bit, Achim Espen Isaksen schrieb: Hi! I have tried to read the documentation and the mailing list for how to connect to a SQLite database. So far I have done this: 1. db.connect driver=sqlite database='/home/espen/db.sqlite' 2. Created a new vector map called test 3. v.db.connect map=test table=GSHHS_f_L2 -o key=PK_UID However I get this warning: WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: column 'Geometry', SQLite type 2 is not supported WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: unable to parse decltype: POLYGON WARNING: SQLite driver: column 'Geometry', SQLite type 2 is not supported The table GSHHS_f_L2 is now part of vector map test and may be deleted or overwritten by GRASS modules And running v.info map=test show that the layer does not have any objects ++ | Layer: test | | Mapset: PERMANENT | | Location: newLocation | | Database: /home/espen/Dokumenter/grassdata | | Title: | | Map scale: 1:1 | | Map format: native | | Name of creator: espen | | Organization: | | Source date: Wed Jun 23 08:55:30 2010 | || | Type of Map: vector (level: 2) | | | | Number of points: 0 Number of areas: 0 | | Number of lines: 0 Number of islands: 0 | | Number of boundaries: 0 Number of faces: 0 | | Number of centroids: 0 Number of kernels: 0 | | | | Map is 3D: No | | Number of dblinks: 1 | | | | Projection: Lat/Lon | | N: 0 S: 0 | | E: 0 W: 0 | | | | Digitization threshold: 0 | | Comments: | | | ++ Could anybody explain to me what the warning means, and why I cannot access the features? The only thing i can guess is that I can only use version 1 of SQLite? However, I am not familiar with the different versions of SQLite. Kind regards, Espen Isaksen ___ 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 -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information
Re: [GRASS-user] modis data
On 06/01/2010 09:10 PM, Hamish wrote: bharath s wrote: iam working on modis data (mydo9q1 250 m) using grass (gis) software. i want to overlay google earth boundary for southindia.. after geocorrection on modis data... but the boundaries are not matching. please help me to solve this problem. is the projecton playing any role in it ? actually iam using lat/long and datum as wgs84. I would try to use the natural earth vector boundary instead of Google's one. Yes, indeed. Since Google's shiny 3D toy is getting dangerously close to being accepted into mainstream science and research now, one should be aware that there are differences between Google's private way of handling lat/lon projections and international geodetic systems: http://www.sharpgis.net/post/2008/05/SphericalWeb-Mercator-EPSG-code-3785.aspx This will lead to inaccuracies when trying to overlay Google data and EPSG 4326 data. The same problem exists for Microsoft's clone of Google Earth (they do seem to take the copying business serious at MS). The magnitude of error will vary with your region's scale and location. NASA's 3D Earth tool is, as may be expected, more competent, so perhaps the better choice for 3D GIS visualization: http://worldwindcentral.com/wiki/Map_projection_Plug-in Best, Ben see 1:10 million, 1:50 million and 1:110million scale maps from http://grass.osgeo.org/wiki/Global_datasets#Natural_Earth_imagery if 1:10m is too crude for you, there NOAA's coastline extractor + v.in.mapgen, or v.in.gshhs from wiki addons; or others listed on the above wiki page. see also http://grass.osgeo.org/wiki/MODIS Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: GRASS GUI assessment
On 06/01/2010 10:59 AM, Jenny Turner wrote: First of all, let me thank you for all your help on describing and commentying the GRASS GUI's. Regarding Benjamin Ducke: - Wxpython Vector Digitizer is not yet available in Windows right? - Regarding QGIS, if a GRASS function is not available at QGIS I have heard that it's quite easy to put in QGIS (just edit a python file and XML as far as I remember). right? Not if the GRASS module in question does 3D data processing (voxel or 3D vector), is an imagery module or takes multiple input maps (see the list I posted). To support such GRASS functionality, the QGIS GRASS plugin needs to be extended at source code level. There are hard limits to what the current QGIS GRASS plugin can do. - And comparing QGIS and WXPYTHON: Which one is more stable and usable? QGIS is NOT a GRASS GUI. QGIS is a GIS on its own with an optional GRASS GUI interface as a plugin. That QGIS GRASS plugin is pretty solid but it does not feel more stable or mature to me, than the current wxPython based GUI for GRASS. Ben Thanks, Jenny ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GUI assessment
Hi Jenny, this one is easy: forget the Tcl/Tk GUI, it's essentially dead code. The WxPython GUI is the current, officially GRASS GUI and much more capable and complete than any other one. The only exception is 3D visualization, where it has not yet achieved the same feature set as good old NVIZ (but this is being worked on actively at the moment). QGIS also has a decent GUI interface for GRASS, but it has been developing much more slowly. It also exposes only some of GRASS' capabilities. Last time I checked (which was some months ago, so some things may have changed by now), it was missing support for: - voxel processing modules - imagery modules - 3D vector processing (due to QGIS' 2D vector model) - multiple input map modules (e.g. r.patch) So the QGIS GRASS interface is only an option if you can work without the above. Ben - Original Message - Greetings I have sent an email a couple of weeks ago regarding a quick compare/assessment regarding GRASS versions. Now, I need to do the same but for GRASS GUI's. As far as I can see I can identify 3 GUIS: - Tcl/tk - WxPython - QGIS is there any comparison (Wikis, documents, ...) between those in order to assess and identify the most adequate one? Thanks Best regards Jenny ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] export as eps/svg ind grass64rc6 - grass7 ??
GRASS GIS development is currently driven by a relatively small number of people, some of them working on GRASS only in their spare time. And most of them have their focus on areas other than map production GUIs. So your best bet to get new functionality into the system that you/someone you know needs is to raise some funding and hire a programmer to do the job. There seems to be almost unlimited money floating around for renting ridiculously expensive proprietary licenses, so surely, there must be some to invest into open source GIS development? Alternatively, there are many more open source GIS apps that can be used (in combination with GRASS) to cover any functionality gaps. E.g. Quantum GIS, OpenJUMP and gvSIG all have easy-to-use map printing facilities. Quantum GIS already has a GRASS interface and the same is currently in the works for gvSIG (via the SEXTANTE tools). Best, Ben - Original Message - From: Francesco Mirabella mirab...@unipg.it To: Hamish hamis...@yahoo.com Cc: grass-user@lists.osgeo.org Sent: Wednesday, May 26, 2010 11:50:16 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [GRASS-user] export as eps/svg ind grass64rc6 - grass7 ?? Hi, sorry if I came back on this topic a bit late with respect to the messages below, but I think it's a quite crucial one and like to know if users/developers share similar needs. I have just had to struggle with a arc* user for printing an map and to try to convince him/her to switch to GRASS I also recall some dilemma provocative messages in 2008 like: I come here with a question/dilemma... Why ps.map lacks so much user support? A lot of people know about GRASS all over the world, but nearly nobody use it, since nearly any software in the world is less difficult to produce maps. GRASS is a wonderful tool for analysis, but it fails to produce the ultimate result: a map. The point is how one can produce an output map which contains at least: 1. a raster map 2. some vector with labels 3. scale One should be able to decide about: 1. map scale, 2. paper format, 3. file format I think that at the present development level, the user should be able to make such a map from the GUI. The output map vector elements should also be editable in skencil, inkscape, openoffice, etc.. with the raster as a base (e.g. a dem or a raster topography) I am aware that the present-day wxpython map display allows to produce bitmaps (.png, .tif, etc..) and that the things in the list above can be drawn off ps.map - ps.output. However at present one has to load all the info into a mapping instructions file which has to be changed each time one wants to map a different map. In the oldtcltk this issue was overcome by the possibility to create the .txt script file directly from the tcltk display window. I wonder if it is planned to create a sort of printing layout which can allow the user to easily output a map. many thanks in advance Francesco Hamish wrote: Achim wrote: I know that it is not possible in grass65, no my friend, it is available: d.out.file format Graphics file format options: png,ppm,tif,geotiff,jpg,bmp,ps,eps,svg,pdf And of course v.out.svg. See d.mon for details on the Cairo and PS (PostScript) drivers which are another way to go. and of course ps.map or ps.output PostScipt [- PDF] - Inkscape is great if you need print quality output. but can one export the graphics display to svg or eps in grass7 (from gui-display)? there is a save-as pull down menu in the map display. I can't remember what's on it except that GeoTiff is on the planned feature list. Alternatively I would like to load my workspace settings to a xmon in order to export from there. Is that possible? (I really dont want to rebuild the layer settings from the shell again ;-) ) GRASS 7 doesn't have xmons, but the PS and Cairo drivers there are much better than in GRASS 6. (mostly the xmons hold them back in grass 6) good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Francesco Mirabella, Geologia Strutturale e Geofisica Universita' di Perugia, Dipartimento di Scienze della Terra, Piazza Universita' 1, 06100 Perugia (Italy) tel: ++39.(0)75.584.7948 fax: ++39.(0)75.585.2603 skype: francesco.mirabella web: http://www.unipg.it/~mirabell/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user --
Re: [GRASS-user] maps France and Germany
http://www.naturalearthdata.com/ Ben On 05/12/2010 06:23 AM, José Miguel Barrios wrote: Hi list; Can someone indicate me where can I request simple vector layers of Germany and France at municipality level? Thanks! Miguel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.vol.idw
I can only speculate that you are really referring to s.vol.idw (?) As the name implies, this is a module that uses the now outdated site data model for its input data. Some of those modules never made the transition to GRASS 6 and its new vector engine. It was still around in GRASS 5.3. They are generally easy to convert to the new API though. But perhaps someone on this list knows more about it? It would certainly be useful to have IDW in voxel space. IDW is primitive and generally does not give results as good as spline-based interpolation (unless your data is very dense and regularly spaced), but it has the advantage of being simple (so it's easy to make sense of the result data) and fast. Ben On 04/28/2010 12:55 PM, Stefania Merlo wrote: Hi, I was wondering what happened to the above command in the new releases of GRASS. I am quite sure I did use it in GRASS 5 and possibly early versions of 6 but it seems it got lost somewhere along the road. Is there any reason for this? Does anyone remember in what version of GRASS for Mac it was last present? I am in desperate need to use it to interpolate 3d points of subsoil data for comparison with v.vol.rst. All best Stefania Stefania Merlo Department of Archaeology University of Cambridge United Kingdom sm...@cam.ac.uk “Mi piacerebbe che il mio viaggio fosse ancora lungo e costellato di smarrimenti, si mi piacerebbe vivere per molto tempo e commettere ancora mille errori, mille sbagli, ed anche un certo numero di peccati memorabili”! (Amin Maalouf, Il periplo di Baldassarre) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Searching Docs about 3D geological modelisation
Why not just ask Steve what he is concerned about and what he would like us to do so that he can shed his concerns? And then try to find a way to accommodate him? If he got more directly involved into this process, it might make him feel less uneasy about it. Ben - Original Message - From: Dylan Beaudette debeaude...@ucdavis.edu To: grass-user@lists.osgeo.org Cc: Benjamin Ducke benjamin.du...@oxfordarch.co.uk, Graham Fogg ge...@mac.com Sent: Friday, January 22, 2010 9:38:18 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Searching Docs about 3D geological modelisation On Saturday 09 January 2010, Benjamin Ducke wrote: Cheers for these. They are certainly all highly interesting. Do you have an actual link for the T-PROGS software itself? All I can seem to come up with are interfaces from other software and publications mentioning it. I would certainly be interested in taking a look at your GRASS interface. Is T-PROGS open source? My gut feeling is that the T-PROGS approach would give better results than 3D kriging, as it seems better able to to follow 3D shape trends: http://chl.erdc.usace.army.mil/chl.aspx?p=sa=ARTICLES;37g=50 ... but that certainly would need testing. Having said that, I also like this approach for a more heuristic model: http://chl.erdc.usace.army.mil/chl.aspx?p=sa=ARTICLES;41g=50 It's very simple and could easily be implemented directly in GRASS GIS. In fact, I coded something very similar to this for archaeological stratigraphy reconstruction a while back. Cheers, Ben Hi Ben and others, Here are some concerns from the author of the TPROGS software: - Steve is hesitant because he's not sure what the finished product would be. I think he's probably concerned about misapplication or perhaps some kind of ripoff. Can you provide a bit more background on where you see this going? - I think that it would be helpful to put together a small proposal, regarding how the TPROGS source code / ideas would be integrated into GRASS. It seems like the author is worried about use without citation, and once he understands what GRASS developers have in mind, should be for it. To start the discussion, I propose that the methods used within the TPROGS software be integrated (with proper citations) into a GRASS library, so that a series of modules can perform the multi-step process associated with modeling transition probabilities. Furthermore, the GRASS rast3 (voxel) datatype should be used to store the resulting structures-- this will make visualization with NVIZ / Paraview a snap. Alternatively, we may be able to link GRASS with TPROGS with a little bit of python glue. While this may work if there are limitations regarding the use of the TPROGS source, I think that having these algorithms present in the GRASS libraries would be a real benefit. I have CC-ed Graham, so that we can keep him in the conversation. Cheers, Dylan - Original Message - From: Dylan Beaudette dylan.beaude...@gmail.com To: Benjamin Ducke benjamin.du...@oxfordarch.co.uk Cc: GRASS user list grass-user@lists.osgeo.org Sent: Saturday, January 9, 2010 4:30:40 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Searching Docs about 3D geological modelisation Two more ideas: 1. conditional simulation, based on a 3D variogram model 2. transition probability-based interpolation of categories Check out gstat for the conditional simulation, and TPROGS for the transition probability. If anything is interested, I have done some programming to connect GRASS and TPROGS. Cheers! Dylan On Fri, Jan 8, 2010 at 1:24 PM, Benjamin Ducke benjamin.du...@oxfordarch.co.uk wrote: Woohoo, this forum is always a treasure trove of good advice. I had not idea SGemS existed! The Voronoi idea is also good, I am just not sure that the 3D Voronoi diagram is quite what one would instinctively think it is. http://en.wikipedia.org/wiki/Voronoi_diagram says: In general a cross section of a 3D Voronoi tessellation is not a 2D Voronoi tessellation itself. Need to look into that. I don't have much practical experience with Bayes models, so can't really comment on that. Cheers, Ben Christian Kaiser wrote: It seems to me that this is a 3D interpolation problem with categorical variables. Maybe the Bayesian Maximum Entropy approach could help. There are some interesting publications around also for geology and soil sciences, and they can deal with categorical data as well. Look for example here: http://www.enge.ucl.ac.be/staff/curr/Bogaert/biblioBME/BMEbibsubject.htm l#Soil%20Science Or maybe you can have a look at SGeMS (http
Re: [GRASS-user] Searching Docs about 3D geological modelisation
Hey, good news. Please keep us updated! Ben - Original Message - From: Dylan Beaudette debeaude...@ucdavis.edu To: Thomas Adams thomas.ad...@noaa.gov Cc: grass list grass-user@lists.osgeo.org Sent: Wednesday, January 20, 2010 8:10:45 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Searching Docs about 3D geological modelisation Quick update: I recently heard back from Graham Fogg here on campus, and he is in favor of allowing T-PROGS to be used within GRASS. However, he is still waiting for the final go-ahead from the original author. Dylan On Monday 11 January 2010, Thomas Adams wrote: Dylan, Can you tell me how to obtain TPROGS? Is it only available commercially? Thanks, Tom Dylan Beaudette wrote: Two more ideas: 1. conditional simulation, based on a 3D variogram model 2. transition probability-based interpolation of categories Check out gstat for the conditional simulation, and TPROGS for the transition probability. If anything is interested, I have done some programming to connect GRASS and TPROGS. Cheers! Dylan On Fri, Jan 8, 2010 at 1:24 PM, Benjamin Ducke benjamin.du...@oxfordarch.co.uk wrote: Woohoo, this forum is always a treasure trove of good advice. I had not idea SGemS existed! The Voronoi idea is also good, I am just not sure that the 3D Voronoi diagram is quite what one would instinctively think it is. http://en.wikipedia.org/wiki/Voronoi_diagram says: In general a cross section of a 3D Voronoi tessellation is not a 2D Voronoi tessellation itself. Need to look into that. I don't have much practical experience with Bayes models, so can't really comment on that. Cheers, Ben Christian Kaiser wrote: It seems to me that this is a 3D interpolation problem with categorical variables. Maybe the Bayesian Maximum Entropy approach could help. There are some interesting publications around also for geology and soil sciences, and they can deal with categorical data as well. Look for example here: http://www.enge.ucl.ac.be/staff/curr/Bogaert/biblioBME/BMEbibsubject.ht ml#Soil%20Science Or maybe you can have a look at SGeMS (http://sgems.sourceforge.net), a tool for 3D geostatistics. None of them is available through GRASS, but the algorithms are freely available (I think open-source, but not verified). I am not a geologist, so please forgive if it is not adequate... Christian Kaiser On 8 janv. 2010, at 11:04, Benjamin Ducke wrote: Rich Shepard wrote: material. There is no interpolation algorithm in GRASS currently which can handle that sort of data well. So what is needed is a political algorithm. :-) That's actually right: given the presence of n different layer types in the vicinity of an empty voxel, the algorithm would need to decide by some sort of majority vote which type to assign to that voxel. Kidding aside, I suspect that a fuzzy interpolation algorithm would solve the problem. How? You could make the interpolated value depend on a fuzzy set member function, I suppose, but the situation here is actually so well defined that I think a probabilistic approach would be preferable. Since each voxel can only store one value, a second output map could store the classification probability. That may be very useful for visualization (you could show voxels with little probability hazier). Ben Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ 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 -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information
Re: [GRASS-user] Searching Docs about 3D geological modelisation
Cheers for these. They are certainly all highly interesting. Do you have an actual link for the T-PROGS software itself? All I can seem to come up with are interfaces from other software and publications mentioning it. I would certainly be interested in taking a look at your GRASS interface. Is T-PROGS open source? My gut feeling is that the T-PROGS approach would give better results than 3D kriging, as it seems better able to to follow 3D shape trends: http://chl.erdc.usace.army.mil/chl.aspx?p=sa=ARTICLES;37g=50 ... but that certainly would need testing. Having said that, I also like this approach for a more heuristic model: http://chl.erdc.usace.army.mil/chl.aspx?p=sa=ARTICLES;41g=50 It's very simple and could easily be implemented directly in GRASS GIS. In fact, I coded something very similar to this for archaeological stratigraphy reconstruction a while back. Cheers, Ben - Original Message - From: Dylan Beaudette dylan.beaude...@gmail.com To: Benjamin Ducke benjamin.du...@oxfordarch.co.uk Cc: GRASS user list grass-user@lists.osgeo.org Sent: Saturday, January 9, 2010 4:30:40 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Searching Docs about 3D geological modelisation Two more ideas: 1. conditional simulation, based on a 3D variogram model 2. transition probability-based interpolation of categories Check out gstat for the conditional simulation, and TPROGS for the transition probability. If anything is interested, I have done some programming to connect GRASS and TPROGS. Cheers! Dylan On Fri, Jan 8, 2010 at 1:24 PM, Benjamin Ducke benjamin.du...@oxfordarch.co.uk wrote: Woohoo, this forum is always a treasure trove of good advice. I had not idea SGemS existed! The Voronoi idea is also good, I am just not sure that the 3D Voronoi diagram is quite what one would instinctively think it is. http://en.wikipedia.org/wiki/Voronoi_diagram says: In general a cross section of a 3D Voronoi tessellation is not a 2D Voronoi tessellation itself. Need to look into that. I don't have much practical experience with Bayes models, so can't really comment on that. Cheers, Ben Christian Kaiser wrote: It seems to me that this is a 3D interpolation problem with categorical variables. Maybe the Bayesian Maximum Entropy approach could help. There are some interesting publications around also for geology and soil sciences, and they can deal with categorical data as well. Look for example here: http://www.enge.ucl.ac.be/staff/curr/Bogaert/biblioBME/BMEbibsubject.html#Soil%20Science Or maybe you can have a look at SGeMS (http://sgems.sourceforge.net), a tool for 3D geostatistics. None of them is available through GRASS, but the algorithms are freely available (I think open-source, but not verified). I am not a geologist, so please forgive if it is not adequate... Christian Kaiser On 8 janv. 2010, at 11:04, Benjamin Ducke wrote: Rich Shepard wrote: material. There is no interpolation algorithm in GRASS currently which can handle that sort of data well. So what is needed is a political algorithm. :-) That's actually right: given the presence of n different layer types in the vicinity of an empty voxel, the algorithm would need to decide by some sort of majority vote which type to assign to that voxel. Kidding aside, I suspect that a fuzzy interpolation algorithm would solve the problem. How? You could make the interpolated value depend on a fuzzy set member function, I suppose, but the situation here is actually so well defined that I think a probabilistic approach would be preferable. Since each voxel can only store one value, a second output map could store the classification probability. That may be very useful for visualization (you could show voxels with little probability hazier). Ben Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ 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 -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel
[GRASS-user] Re: [GRASS-dev] Some comments on the v.surf.icw add-on
- Hamish hamis...@yahoo.com wrote: how about editing in some small 1 pixel land bridges eg from norway to denmark and the tip of italy to..lots of places. with a the relative cost/risk of sailing to the other side? seems like a lot of walking could be avoided by a small boat trip every now and then. or just apply some high cost value to water cells instead of NULL. ? Yup, that's what we did ;) The cost surface includes cheap costs in the coastal waters within visible distance from the mainland. Also, we allowed for cheap travel along the main rivers. I ran the same calculations with euclidean distances and there is a reasonable difference. If you could add FP support done Excellent! and an option to set the number of input points, that would be superb. I don't think I can set the number of input points; or rather I could but it really wouldn't save you any time as you have to do the main calculation before you can answer the question of what the most local points are. What I can do is add a max_cost= option to feed to r.cost which will save time. Beyond that cost (units: number of cells) the weighting would be set to zero. This will incur at least 1 (maybe more) additional r.mapcalc step if the option is used, but that's still probably faster than waiting for r.cost to search to the ends of the earth (guessing, only testing will tell and it probably depends on the relative speed of your CPU vs. hard drive). Right, I was assuming the n points option in most IDW implementations is there because it saves time with a lot of input points. But that would only be the case if the n closest points can be found efficiently, which as you say, is hard with a cost surface. Max cost would be great in combination with an option to set each output cell to NULL which is located maxcost from any input point. luckily there is a simple polynomial which fits my hand calculated correction almost perfectly. (IIRC the uncorrected versions lead to such tiny numbers that all of the floating point precision was tied up in maintaining fidelity for them which was degrading the of the precision of the useful data range) That is lucky indeed (and probably good prove that your correction factor was sound in the first place)! Cheers, Ben -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Searching Docs about 3D geological modelisation
Rich Shepard wrote: material. There is no interpolation algorithm in GRASS currently which can handle that sort of data well. So what is needed is a political algorithm. :-) That's actually right: given the presence of n different layer types in the vicinity of an empty voxel, the algorithm would need to decide by some sort of majority vote which type to assign to that voxel. Kidding aside, I suspect that a fuzzy interpolation algorithm would solve the problem. How? You could make the interpolated value depend on a fuzzy set member function, I suppose, but the situation here is actually so well defined that I think a probabilistic approach would be preferable. Since each voxel can only store one value, a second output map could store the classification probability. That may be very useful for visualization (you could show voxels with little probability hazier). Ben Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Searching Docs about 3D geological modelisation
Woohoo, this forum is always a treasure trove of good advice. I had not idea SGemS existed! The Voronoi idea is also good, I am just not sure that the 3D Voronoi diagram is quite what one would instinctively think it is. http://en.wikipedia.org/wiki/Voronoi_diagram says: In general a cross section of a 3D Voronoi tessellation is not a 2D Voronoi tessellation itself. Need to look into that. I don't have much practical experience with Bayes models, so can't really comment on that. Cheers, Ben Christian Kaiser wrote: It seems to me that this is a 3D interpolation problem with categorical variables. Maybe the Bayesian Maximum Entropy approach could help. There are some interesting publications around also for geology and soil sciences, and they can deal with categorical data as well. Look for example here: http://www.enge.ucl.ac.be/staff/curr/Bogaert/biblioBME/BMEbibsubject.html#Soil%20Science Or maybe you can have a look at SGeMS (http://sgems.sourceforge.net), a tool for 3D geostatistics. None of them is available through GRASS, but the algorithms are freely available (I think open-source, but not verified). I am not a geologist, so please forgive if it is not adequate... Christian Kaiser On 8 janv. 2010, at 11:04, Benjamin Ducke wrote: Rich Shepard wrote: material. There is no interpolation algorithm in GRASS currently which can handle that sort of data well. So what is needed is a political algorithm. :-) That's actually right: given the presence of n different layer types in the vicinity of an empty voxel, the algorithm would need to decide by some sort of majority vote which type to assign to that voxel. Kidding aside, I suspect that a fuzzy interpolation algorithm would solve the problem. How? You could make the interpolated value depend on a fuzzy set member function, I suppose, but the situation here is actually so well defined that I think a probabilistic approach would be preferable. Since each voxel can only store one value, a second output map could store the classification probability. That may be very useful for visualization (you could show voxels with little probability hazier). Ben Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ 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 -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] CCM2 version 2.1 data available as shapefiles
Apologies if this is already old news, but I have just been informed by Alfred de Jager that the great European river catchments dataset CCM2 is now available for download as shapefiles: http://desert.jrc.ec.europa.eu/water/ccm/php/jrc_getshape.php Mr. de Jager writes: The password to be supplied for the encrypted shapefiles is 'public' Note that the shapefile format is somewhat limited for the storage of names in non Latin character sets. You can find the original names on the various 'manage' functions on the 'catchments and coding' website. He also asks everyone who downloads that data to please register at their website so that they can keep track of their user base: http://ccm.jrc.ec.europa.eu/ Best, Ben -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GIS and GPU
Instead of CUDA, maybe consider using OpenCL, as that is a vendor-independent standard which works on GPUs, CPUs and DSPs. There seem to be several Python wrappers for OpenCL. Ben Pablo Carreira wrote: Hi, I'am curious to know if there is any development is using GPU to accelerate some tasks in GIS, like raster calculations. I have an Nvidia gpu and found pyCUDA parallel computation very interesting. Is there any paper in this subject to read? Thanks. Pablo Torres Carreira Quer conexões de rede mais fácil? Clique e conheça o Windows 7. http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Geospatial Consultant Oxford Archaeology Digital Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oadigital.net http://oadigital.net -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.prominence
It's very simple. It really just averages the values of raster cells for a neighbourhood window of a size m x n. It then determines how much the cell in the window center deviates from that average. Add some normalization and you get a map that shows you which cells stick out most. Use it on a map with elevation values and you can (tentatively) call that topographic prominence. The module lets you choose different window sizes and shapes and whether to use local (within window) or global (over whole map) normalization. Ben - Original Message - From: Bulent Arikan bulent.ari...@gmail.com To: grass-user-requ...@lists.osgeo.org, grass-user@lists.osgeo.org Sent: Monday, November 23, 2009 7:46:52 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [GRASS-user] r.prominence Hi, I have been using r.param.scale and inverting DEM method for identifying peaks. I am specifically interested in finding the high spots on a landscape; not just the highest single cell. It has been suggested that r.prominence may be of help. I realise that this comes in a file that needs to be compiled (.c extension). Before compiling, I will appreciate any insight on what it does. Thank you -- BÜLENT ARIKAN School of Human Evolution and Social Change Arizona State University Tempe - AZ 85287-2402 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Is there any spatial test in v.normal?
Hi all, v.normal's description states: Tests for normality for points. However, out of the 15 test metrics it computes, I can't find a single one that is actually spatial. They all seem to work on the attribute data only. So why does the description state that it is for points? shrug Ben -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
