Re: [GRASS-user] Run a GRASS module from a custom module (C language)
José María Michia Roberts wrote: I'm still learning! I have found that a simple call to function system() is enough. But I was curious to learn how to use fork / exec, and was a bit difficult for me. Note that system() is rather error-prone if you need to be able to pass variable parameters to the command, as you need to quote or escape characters which are significant to the shell (of which there are many). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Unable create DBF database (in GRASS-GIS 7.0)
Hi, I am getting following error while using the t.* commands in GRASS-GIS 7.0 (I have installed the latest snapshot of it) DBMI-DBF driver error: Unable create DBF database: home/grass_location/user1/dbf/ DBMI-DBF driver error: Unable create DBF database: home/grass_location/user1/dbf/ ERROR: Unable to open database home/grass_location/user1/dbf/ Kindly help. Regards, Manish ___ 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
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? 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
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
[GRASS-user] grass prompt default working directory
Hello list, when launching grass64, the working directory of the process (I mean the grass prompt in the terminal window) is located at user's home (e.g pwd command returns: /home/vincent). I did not find if this path was stored in a Grass environment variable ? is it possible to change the default path ? The point is I often need to cd to the current mapset directory, it could be convenient to have the ability to set this default path at grass startup in a given location/mapset. Has anyone any advice/idea for this ? Thanks, Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.transform reports erroneous values in the transformation matrix
Hi all! I've found that values of transformation matrix reported by v.transform are erroneous after using this values in ST_Affine (a PostGIS's function). The values that seems to be erroneous are x_offset and y_offset. The rotation values seems to are fine. The transformed elements are ok (it is, their coordinates are in the right place). Values reported by v.transform: xoff = -139153.031250 yoff = 8352534.450195 The correct values must be (aproximately): xoff = 5461371 yoff = 6321181 The complete session's log with one test element is there (same results with a whole layer): http://pastebin.com/FUtnePvb Local map: tmp Transformed map: tmp_geo Take a look at the map region for tmp/tmp_geo (reported by v.info), and compare these values with those of x_off / y_off (reported by v.transform). Maybe I'm not interpreting this correctly. Thanks all! Jose ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
On Tuesday 26 of February 2013 14:13:02 Vincent Bain wrote: Hello list, Hi Vincent. when launching grass64, the working directory of the process (I mean the grass prompt in the terminal window) is located at user's home (e.g pwd command returns: /home/vincent). I did not find if this path was stored in a Grass environment variable ? You work in a linux-box, right? I think the GRASS-working-directory (if I can name it like that as per the pwd command) it just remains there from where you actually launching grass. Try launching from a different directory. is it possible to change the default path ? I think there is no GRASS_HOME variable! Not sure however -- maybe check here: http://grass.osgeo.org/grass64/manuals/variables.html. The point is I often need to cd to the current mapset directory, it could be convenient to have the ability to set this default path at grass startup in a given location/mapset. Me too! Has anyone any advice/idea for this ? It sounds easy to do!? Something like using GRASS' existing environment variables GISDBASE, LOCATION_NAME, MAPSET and instructing inside the GRASS initialization (Python) script to navigate to this directory? Don't know if this breaks anything... Sorry, no time to test myself. Best, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
More about my previous post, as a kind of self-answer: I understand grass64 launched from a terminal shell is a child process which inherits from the shell's working directory. Sometimes paths are quite annoying to type (even with the help of autocompletion, I'm lazy!). For the time being I wrote a little script, located in my home directory (~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv, then changes directory to the current mapset. In order to take into account the cd command in the parent process, I source the script from grass prompt : . g.cd It's quite straight. Any better/cleaner solution is welcome, Vincent Le mardi 26 février 2013 à 14:13 +0100, Vincent Bain a écrit : Hello list, when launching grass64, the working directory of the process (I mean the grass prompt in the terminal window) is located at user's home (e.g pwd command returns: /home/vincent). I did not find if this path was stored in a Grass environment variable ? is it possible to change the default path ? The point is I often need to cd to the current mapset directory, it could be convenient to have the ability to set this default path at grass startup in a given location/mapset. Has anyone any advice/idea for this ? Thanks, Vincent ___ 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] grass prompt default working directory
Thank you Nikos for your reply, I let you read my previous message as an answer. The thing is I mostly run grass in text mode. Yours, Vincent Le mardi 26 février 2013 à 15:29 +0200, Nikos Alexandris a écrit : On Tuesday 26 of February 2013 14:13:02 Vincent Bain wrote: Hello list, Hi Vincent. when launching grass64, the working directory of the process (I mean the grass prompt in the terminal window) is located at user's home (e.g pwd command returns: /home/vincent). I did not find if this path was stored in a Grass environment variable ? You work in a linux-box, right? I think the GRASS-working-directory (if I can name it like that as per the pwd command) it just remains there from where you actually launching grass. Try launching from a different directory. is it possible to change the default path ? I think there is no GRASS_HOME variable! Not sure however -- maybe check here: http://grass.osgeo.org/grass64/manuals/variables.html. The point is I often need to cd to the current mapset directory, it could be convenient to have the ability to set this default path at grass startup in a given location/mapset. Me too! Has anyone any advice/idea for this ? It sounds easy to do!? Something like using GRASS' existing environment variables GISDBASE, LOCATION_NAME, MAPSET and instructing inside the GRASS initialization (Python) script to navigate to this directory? Don't know if this breaks anything... Sorry, no time to test myself. Best, Nikos ___ 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
2013/2/26 Benjamin Ducke bendu...@fastmail.fm: 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). Yes, I know. But I think that there are some cases, like this, where the overlaps between polygons are part of the information and need to be preserved. And I understand that a situation like this would limit the application of other modules. Maybe I'm totally wrong: I still have so much to study about GRASS! (english too... right?) :D Thanks, Jose ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.transform reports erroneous values in the transformation matrix
On Tue, Feb 26, 2013 at 2:17 PM, José María Michia Roberts jose.maria.mic...@gmail.com wrote: Hi all! I've found that values of transformation matrix reported by v.transform are erroneous after using this values in ST_Affine (a PostGIS's function). The values that seems to be erroneous are x_offset and y_offset. The rotation values seems to are fine. The transformed elements are ok (it is, their coordinates are in the right place). Values reported by v.transform: xoff = -139153.031250 yoff = 8352534.450195 The correct values must be (aproximately): xoff = 5461371 yoff = 6321181 The complete session's log with one test element is there (same results with a whole layer): http://pastebin.com/FUtnePvb Local map: tmp Transformed map: tmp_geo Take a look at the map region for tmp/tmp_geo (reported by v.info), and compare these values with those of x_off / y_off (reported by v.transform). Note that there are two transformation matrices, one for forward transformation, one for backward transformation. Can the PostGIS ST_Affine function print both matrices? If possible, rather use v.rectify in GRASS 7 instead of v.transform in GRASS 6. With a recent version of GDAL/OGR, you can also add GCPs to a datasource with ogr2ogr -gcp which should then automatically transform the coordinates. Markus M Maybe I'm not interpreting this correctly. Thanks all! Jose ___ 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] Apply v.transform in polygons with overlays
On Tue, Feb 26, 2013 at 2:36 PM, Jose M Michia Roberts jose.maria.mic...@gmail.com wrote: 2013/2/26 Benjamin Ducke bendu...@fastmail.fm: 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). Yes, I know. But I think that there are some cases, like this, where the overlaps between polygons are part of the information and need to be preserved. The overlaps between polygons are only preserved if you do not use the -c flag for v.in.ogr. Each original polygon can then be recreated with v.extract -d cat=X. If you use the -c flag with v.in.ogr, you are on your own. BTW, v.transform simply transforms coordinates, it does not do any cleaning. v.transform should actually work without topology, building topology on the output is optional (in GRASS 7). And I understand that a situation like this would limit the application of other modules. Maybe I'm totally wrong: I still have so much to study about GRASS! For this particular problem (georectifying overlapping polygons) there is probably an easier solution outside GRASS. Maybe QGIS supports coordinate transformation/rectification using GCPs? Markus M (english too... right?) :D Thanks, Jose ___ 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] Apply v.transform in polygons with overlays
On 26/02/13 13:50, Benjamin Ducke wrote: 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). -1 I'm strongly opposed to that option. As you mention, this would fundamentally undermine the data logic in GRASS. To answer José's issue: If you want to keep on working in GRASS, you should not try to do so with overlapping polygones. If all you want to do in GRASS is v.transform, you should be able to import with cleaning. Wherever there is overlap, you will get new polygones which have all the category numbers of the original polygones. You can then v.transform the file and if you need to get the original polygones you should be able reconstruct them based on the common category numbers. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
On 26/02/13 14:26, Vincent Bain wrote: More about my previous post, as a kind of self-answer: I understand grass64 launched from a terminal shell is a child process which inherits from the shell's working directory. Sometimes paths are quite annoying to type (even with the help of autocompletion, I'm lazy!). For the time being I wrote a little script, located in my home directory (~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv, then changes directory to the current mapset. I would not recommend using the GISDBASE as your working directoy. My general advice: let GRASS handle everything in there and create your own files elsewhere. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Vincent: Thank you Nikos for your reply, I let you read my previous message as an answer. I guess I was writing while it hit my inbox! :-p The thing is I mostly run grass in text mode. Me too -- and I truly understand your need(s), I think. For your interest, you might want to read the threads Bash aliases in GRASS and Simple bash auto-completion for GRASS in grass- dev's ML. Thanks, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Vincent Bain wrote: More about my previous post, as a kind of self-answer: I understand grass64 launched from a terminal shell is a child process which inherits from the shell's working directory. Sometimes paths are quite annoying to type (even with the help of autocompletion, I'm lazy!). For the time being I wrote a little script, located in my home directory (~/g.cd). It evals GISDBASE, LOCATION_NAME, GISMAPSET with g.gisenv, then changes directory to the current mapset. Moritz: I would not recommend using the GISDBASE as your working directoy. My general advice: let GRASS handle everything in there and create your own files elsewhere. Moritz, if I understand Vincent's need(s), and if they coincide with mine, I think it's about checking map names, colr rules, maybe check the subgroups which is not easy via the g.list type=group nor the i.group group=yourGroup -l commands, etc. It is not about manipulating files in the GRASS db. Imagine, that I just want to d.rast some map among the cm_fmap_2006_ellas cm_fmap_2006_ellas_forested_areas cm_fmap_2006_tile_51 cm_fmap_2006_tile_52 cm_ftype_2006_tile_51 cm_ftype_2006_tile_52 (here only a few -- imagine hundreds). Why do I need to g.list first, mark- copy-paste (via the middle mouse-button or Ctrl + Shift + C and +V respectively in the keyboard)? I simply want quick access and the awesome autocompletion feature to all of my map(name)s and don't need to re-type the complete name. Luckily, the history functions of bash are very handy (e.g. Ctrl + R and more). I simply navigate inside the respective CELL or FCELL or DCELL or cell_misc directory sometimes... Just my old 2 drachmas, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
I would not recommend using the GISDBASE as your working directoy. My general advice: let GRASS handle everything in there and create your own files elsewhere. Hello Moritz, two reasons I use to cd to mapset directory : - general - that described by Nikos, like browsing data via bash commands; - particular - the wish to keep a mapset-specific directory I usually call ps; it contains settings files for my recursive ps.map runs, refering each to a saved region. To my mind this kind of data is strongly linked to the geodatabase structure, particularly in long-term cartographic projects. Another point is that working on a bunch of gisdbases, I am trying to avoid data scattering, for archiving convenience mainly. But files are mainly stored at the gisdbase level. Concerning my first issue: the home-made g.cd script suits me well. Thank you both for your points of view ! Vincent. ___ 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
2013/2/26 Markus Metz markus.metz.gisw...@gmail.com: BTW, v.transform simply transforms coordinates, it does not do any cleaning. v.transform should actually work without topology, building topology on the output is optional (in GRASS 7). [...] For this particular problem (georectifying overlapping polygons) there is probably an easier solution outside GRASS. Maybe QGIS supports coordinate transformation/rectification using GCPs? Looks like you're right. I will try a newer version of GDAL / OGR. I will also update GRASS, to use v.rectify, so I can check the values of the transformation matrix, and explore the possibility of working without topology. In QGIS, I could not find an equivalent function. Maybe it exist, but I have looked very little. I know there is a plugin for GCP based transformations, but it is for rasters. Anyway, some of the above alternatives will surely solve my problem. 2013/2/26 Moritz Lennert mlenn...@club.worldonline.be: -1 I'm strongly opposed to that option. As you mention, this would fundamentally undermine the data logic in GRASS. To answer José's issue: If you want to keep on working in GRASS, you should not try to do so with overlapping polygones. Thanks Moritz, I hope fully understand all implications of this topic someday! For now, I promise to not propose something like that anymore. If all you want to do in GRASS is v.transform, you should be able to import with cleaning. Wherever there is overlap, you will get new polygones which have all the category numbers of the original polygones. You can then v.transform the file and if you need to get the original polygones you should be able reconstruct them based on the common category numbers. I considered doing this at first. But when I checked the maps imported, I could not find all the information necessary to perform the task. I will follow your instructions if only as an exercise to learn a little more. Thank you very much! Jose ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
On 26 February 2013 15:29, Vincent Bain b...@toraval.fr wrote: I would not recommend using the GISDBASE as your working directoy. My general advice: let GRASS handle everything in there and create your own files elsewhere. Hello Moritz, two reasons I use to cd to mapset directory : - general - that described by Nikos, like browsing data via bash commands; - particular - the wish to keep a mapset-specific directory I usually call ps; it contains settings files for my recursive ps.map runs, refering each to a saved region. To my mind this kind of data is strongly linked to the geodatabase structure, particularly in long-term cartographic projects. Another point is that working on a bunch of gisdbases, I am trying to avoid data scattering, for archiving convenience mainly. But files are mainly stored at the gisdbase level. Concerning my first issue: the home-made g.cd script suits me well. Thank you both for your points of view ! Vincent. Hi, you all made some interesting points. Please consider creating wiki page on this topic. Something like Using GRASS from shell effectively or Ps.map files management/workflow could be interesting not only for newbies to understand why cmd like is good but also for advanced users. I guess there is no such wiki page. Vaclav ___ 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] Apply v.transform in polygons with overlays
Hello all, I am a member of a group of farmers and agribusinesses that would like to explore using grass or other open source gis as a replacement for the commercial ag gis platforms out there. Most of the desktop software is not being updated and the new systems are web based. These require us to allow sensitive data to leave our control. We are located around the Midwest but concentrated in eastern iowa. We would like to find some talented developers to help us explore/develop this (on a paid basis). Is grass fairly adaptable? If anyone has any advice I would love to hear from you Thank you, John. Mcgillicuddy Sent from my iPad On Feb 26, 2013, at 2:51 AM, José María Michia Roberts jose.maria.mic...@gmail.com wrote: Hi all! I need to use v.transform over layers that are topologically incorrect (so they have overlapped polygons, and it is not a problem). Of course, many elements disappear after importing the layer, and more elements disappear after applying v.transform. To solve this, I wrote a python script very configurable, that import/transform/export the elements one-on-one , from/to a non-topological data source. Problem: I am not satisfied with the performance. The datasource has hundreds of thousands of elements and the process takes many hours to complete. Question: is there a better approach to solve the overlapped polygons processing? Note that I have to keep overlapping polygons. Thanks in advance! José ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.transform reports erroneous values in the transformation matrix
2013/2/26 Markus Metz markus.metz.gisw...@gmail.com: Note that there are two transformation matrices, one for forward transformation, one for backward transformation. Can the PostGIS ST_Affine function print both matrices? AFAIK, PostGIS cannot print neither calculate transformation matrices. User must obtain matrices values from somewhere. [sorry if this thread became off-topic] If possible, rather use v.rectify in GRASS 7 instead of v.transform in GRASS 6. With a recent version of GDAL/OGR, you can also add GCPs to a datasource with ogr2ogr -gcp which should then automatically transform the coordinates. I will try it. Thank you for update me! Salud! Jose ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Geomorphons and extension manager
To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have posted below. Any Suggestions? # g.extension extension=r.geomorphon/ operation=add Fetching r.geomorphon/ from GRASS-Addons SVN (be patient)... Compiling... In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' lipo: can't figure out the architecture type of: /var/folder s/wc/2dv9njw93k3bfyy5ppkw022hgn/T//ccESKY4a.out make: *** [OBJ.x86_64-apple-darwin12.2.0/geom.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. (Tue Feb 26 09:40:18 2013) Command finished (3 sec) # Your help is much appreciated! Sincerely, Robert Brown All messages comes from compiler informing you haven't installed standard librarires. This is however the issue of g.extension, which do not work well with Apple systems. Please contact grass dev team how to resolve this issue regards Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable create DBF database (in GRASS-GIS 7.0)
On Tue, Feb 26, 2013 at 1:08 PM, Manish Gautam manish.gauta...@gmail.com wrote: Hi, I am getting following error while using the t.* commands in GRASS-GIS 7.0 (I have installed the latest snapshot of it) DBMI-DBF driver error: Unable create DBF database: home/grass_location/user1/dbf/ DBMI-DBF driver error: Unable create DBF database: home/grass_location/user1/dbf/ ERROR: Unable to open database home/grass_location/user1/dbf/ The easiest solution will be to switch the DB backend to SQLite: http://grass.osgeo.org/grass70/manuals/db.connect.html # set to SQLite default database backend db.connect -d Then it should work. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable create DBF database (in GRASS-GIS 7.0)
Hi, 2013/2/26 Manish Gautam manish.gauta...@gmail.com: DBMI-DBF driver error: Unable create DBF database: home/grass_location/user1/dbf/ should start with '/', ie. /home/... What says db.connect -p ? 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] Geomorphons and extension manager
I'm having similar problems with the extension manage on the Mac currently and filed a bug report. 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 On Feb 26, 2013, at 10:40 AM, grass-user-requ...@lists.osgeo.orgmailto:grass-user-requ...@lists.osgeo.org wrote: From: Robert Andrew Brown brown...@purdue.edumailto:brown...@purdue.edu Subject: [GRASS-user] Geomorphons and extension manager Date: February 26, 2013 10:20:42 AM MST To: grass-user@lists.osgeo.orgmailto:grass-user@lists.osgeo.org Cc: Phillip Owens prow...@purdue.edumailto:prow...@purdue.edu To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.plmailto:jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edumailto:brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edumailto:brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have posted below. Any Suggestions? # g.extension extension=r.geomorphon/ operation=add Fetching r.geomorphon/ from GRASS-Addons SVN (be patient)... Compiling... In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' lipo: can't figure out the architecture type of: /var/folder s/wc/2dv9njw93k3bfyy5ppkw022hgn/T//ccESKY4a.out make: *** [OBJ.x86_64-apple-darwin12.2.0/geom.o]
Re: [GRASS-user] grass prompt default working directory
Le mardi 26 février 2013 à 16:49 +0100, Vaclav Petras a écrit : Hi, you all made some interesting points. Please consider creating wiki page on this topic. Something like Using GRASS from shell effectively or Ps.map files management/workflow could be interesting not only for newbies to understand why cmd like is good but also for advanced users. I guess there is no such wiki page. Vaclav, writing a few lines on the wiki about ps.map workflow solutions is on my todo list (to the truth, it's been for quite a long time...) Scripting ps.map in combination with other command-line tools (convert, ps2pdf, latex/pstricks, pure postscript instructions, etc.) opens a wide variety of methods to design accurate, sophisticated and efficient production flows (OK, everyone here knows it... sorry ;-)) I'll try to spend some time on it soon. Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Geomorphons and extension manager
Thank you. I am thinking about trying to re-compile GRASS from source code and see if it will resolve the issue. Also, I found some documentation on using python to acquire add-ons with the g.extension manager. Sincerely, -robert brown On Feb 26, 2013, at 1:40 PM, Michael Barton michael.bar...@asu.edu wrote: I'm having similar problems with the extension manage on the Mac currently and filed a bug report. 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 On Feb 26, 2013, at 10:40 AM, grass-user-requ...@lists.osgeo.org wrote: From: Robert Andrew Brown brown...@purdue.edu Subject: [GRASS-user] Geomorphons and extension manager Date: February 26, 2013 10:20:42 AM MST To: grass-user@lists.osgeo.org Cc: Phillip Owens prow...@purdue.edu To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have posted below. Any Suggestions? # g.extension extension=r.geomorphon/ operation=add Fetching r.geomorphon/ from GRASS-Addons SVN (be patient)... Compiling... In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin'
Re: [GRASS-user] grass prompt default working directory
Hi,
a couple of points,
firstly, you can add this to ~/.grass.bashrc:
g.cd()
{
MAPSET=`g.gisenv get=MAPSET`
LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
GISDBASE=`g.gisenv get=GISDBASE`
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
cd $LOCATION
}
(as I just did, nice idea, thanks!)
these used to be enviro vars in earlier versions of GRASS, but
were changed to g.gisenv enviro vars as changing context needs
to happen for the whole GIS. Once the GUI is launched, any changes
to enviro vars in either it or the command prompt only propogate
to children of each, not to siblings or past-spawned children
processes. So the command prompt and GUI would get out of sync
wrt which mapset or location you are in and it would be a big
mess.
Note that the mapset dir is (in a way) set to be the home dir
in a soft way, so that .bash_history for the grass command
session is written to the mapset dir, not real $HOME. Using
that, the above g.cd could be simplifiled to:
alias g.home='cd `dirname $HISTFILE`'
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Nikos wrote: if I understand Vincent's need(s), and if they coincide with mine, I think it's about checking map names, colr rules, maybe check the subgroups which is not easy via the g.list type=group nor the i.group group=yourGroup -l commands, etc. fwiw, g.findfile might be useful for that (mostly for use by scripts). It is not about manipulating files in the GRASS db. Imagine, that I just want to d.rast some map among the cm_fmap_2006_ellas cm_fmap_2006_ellas_forested_areas cm_fmap_2006_tile_51 cm_fmap_2006_tile_52 cm_ftype_2006_tile_51 cm_ftype_2006_tile_52 (here only a few -- imagine hundreds). Why do I need to g.list first, mark-copy-paste (via the middle mouse-button or Ctrl + Shift + C and +V respectively in the keyboard)? g.mlist? :) I simply want quick access and the awesome autocompletion feature to all of my map(name)s and don't need to re-type the complete name. Luckily, the history functions of bash are very handy (e.g. Ctrl + R and more). re. and more, fwiw, I find adding this to ~/.inputrc is much nicer to use than ^r, # Bind page up/down wih history search - \e[5~: history-search-backward \e[6~: history-search-forward type the first few letters, then PgUp to see earlier matches.. hoping the recent work on command line completion continues, :) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Hamish wrote:
firstly, you can add this to ~/.grass.bashrc:
g.cd()
{
MAPSET=`g.gisenv get=MAPSET`
LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
GISDBASE=`g.gisenv get=GISDBASE`
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
cd $LOCATION
}
(as I just did, nice idea, thanks!)
here is a slight modification so you can also do g.cd colr/,
or even g.cd .. to get to the LOCATION's dir:
g.cd()
{
MAPSET=`g.gisenv get=MAPSET`
LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
GISDBASE=`g.gisenv get=GISDBASE`
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
cd $LOCATION/$1
}
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Hi,
2013/2/26 Hamish hamis...@yahoo.com:
Hamish wrote:
firstly, you can add this to ~/.grass.bashrc:
g.cd()
{
MAPSET=`g.gisenv get=MAPSET`
LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
GISDBASE=`g.gisenv get=GISDBASE`
LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
cd $LOCATION
}
cool, as Vaclav noted please add such useful notes on the wiki.
Otherwise it will be lost in ML jungle.
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] grass prompt default working directory
Nikos wrote: if I understand Vincent's need(s), and if they coincide with mine, I think it's about checking map names, colr rules, maybe check the subgroups which is not easy via the g.list type=group nor the i.group group=yourGroup -l commands, etc. Hamish: fwiw, g.findfile might be useful for that (mostly for use by scripts). That to be honest, I use(d) that rarely. .. (here only a few -- imagine hundreds). Why do I need to g.list first, mark-copy-paste (via the middle mouse-button or Ctrl + Shift + C and +V respectively in the keyboard)? g.mlist? :) Yes, very frequently, every day actually. In one-liners and scripts -- can't live without it. .. Luckily, the history functions of bash are very handy (e.g. Ctrl + R and more). re. and more, fwiw, I find adding this to ~/.inputrc is much nicer to use than ^r, So cool!! -- ...hey, that's not fair :-/ Will test it for some time to see if it fits to my habits :-p # Bind page up/down wih history search - \e[5~: history-search-backward \e[6~: history-search-forward type the first few letters, then PgUp to see earlier matches.. I guess this replicates the continuous Ctrl + R functionality. hoping the recent work on command line completion continues, :) Happy cli user here :-). Recent additions in the wxGUI are, however, very nice and necessary. Thanks, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Martin wrote: cool, as Vaclav noted please add such useful notes on the wiki. done @ http://grasswiki.osgeo.org/wiki/GRASS_and_Shell Otherwise it will be lost in ML jungle. the distributed backup method ;) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Geomorphons and extension manager
When I tried to compile r.geomorphon, I got the errors you see below. I just tried g.extensions with similar results. $ make MODULE_TOPDIR=/home/bob/dev/gis/grass70 test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grassmods\ -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/geom.o -c geom.c geom.c: In function ‘ternary_rotate’: geom.c:21:5: warning: unused variable ‘res’ [-Wunused-variable] geom.c: In function ‘radial2cartesian’: geom.c:188:21: warning: ordered comparison of pointer with integer zero [-Wextra] geom.c: In function ‘extends’: geom.c:198:37: warning: unused parameter ‘pattern_size’ [-Wunused-parameter] geom.c: At top level: geom.c:2:15: warning: ‘dirs’ defined but not used [-Wunused-variable] gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grassmods\ -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/main.o -c main.c main.c: In function ‘main’: main.c:177:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:198:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:207:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:213:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:220:3: warning: format not a string literal and no format arguments [-Wformat-security] main.c:234:3: warning: format not a string literal and no format arguments [-Wformat-security] main.c:310:8: warning: format not a string literal and no format arguments [-Wformat-security] main.c:366:5: error: implicit declaration of function ‘radial2cartesian’ [-Werror=implicit-function-declaration] main.c:401:2: error: implicit declaration of function ‘write_contrast_colors’ [-Werror=implicit-function-declaration] main.c:268:20: warning: unused variable ‘formC’ [-Wunused-variable] main.c:268:13: warning: unused variable ‘formB’ [-Wunused-variable] main.c:268:6: warning: unused variable ‘formA’ [-Wunused-variable] main.c:76:22: warning: unused variable ‘radius’ [-Wunused-variable] main.c:74:11: warning: unused variable ‘n’ [-Wunused-variable] main.c:74:8: warning: unused variable ‘j’ [-Wunused-variable] main.c:463:1: warning: control reaches end of non-void function [-Wreturn-type] cc1: some warnings being treated as errors make: *** [OBJ.x86_64-unknown-linux-gnu/main.o] Error 1 From: grass-user-boun...@lists.osgeo.org [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Robert Andrew Brown Sent: Tuesday, February 26, 2013 9:21 AM To: grass-user@lists.osgeo.org Cc: Phillip Owens Subject: [GRASS-user] Geomorphons and extension manager To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.plmailto:jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edumailto:brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edumailto:brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have posted below. Any Suggestions? # g.extension extension=r.geomorphon/ operation=add Fetching r.geomorphon/ from GRASS-Addons SVN (be patient)... Compiling... In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or
[GRASS-user] 3-D plane workflow
I would like to be able to put some surfaces in the space over a DEM. In other words, I have a DEM, and then I need to calculate some regions that are keep-out zones in space above. I can calculate where these surfaces are fairly easily in Python, for example. So the output of my calculation would be some points. In the easiest example, it would just be 4 sets of x,y,z that represent the four corners of a plane. I would then like to be able to visually show this plane (or multiple planes), over the DEM, and show that the DEM does, or doesn't, penetrate this surface. If it does penetrate, I would like to be able to calculate the penetration height. The kind of thing that I would like to do, would end up looking like the examples of Slovakia precipitation that Mitasova has done. Some of those examples show a DEM, and then a surface that is being penetrated by the DEM. I have been reading some of the examples for 3D visualization (such as here: http://grasswiki.osgeo.org/wiki/Help_with_3D), but figured that a post here, but might get me a little more guidance about a general suggested workflow. In those examples, are the isosurfaces does as 3D rasters? If I just want a plane in space, and I have the four corner points, is a 3D raster seem like the best way to draw it? Are those examples displayed with NVIZ or paraview? Is the following a reasonable approach: Calculate the surfaces in some code and export as faces: F 4 0 100 10 50 50 80 0 0 10 0 100 10 Then, import into Grass with v.in.ascii. Next, I would have to convert to a raster: v.to.rast. Then, I would have to convert to an elevation: r.to.rast3elev Finally, I could export both the surfaces and the ground DEM with r3.out.vtk, and visualize with paraview. Is this a reasonable workflow? If I just need a semitransparent surface, is it necessary for it to be 3D, or can it be done with 2.5D (all I really need is x,y and elevation, like a DEM). For, example, I might be able to just skip the raster version and use v.out.vtk?Or maybe I can just use nviz to visualize what I need, if I can get it to the right format. If I do convert the plane to a raster, I suppose I can then use mapcalc to calculate the height difference between the plane and the ground DEM? I am just looking for some general workflow guidance for a good overall approach to get going. It seems like there are some things that are not as clear about 3D work in GRASS, and I am just trying to get a reasonable picture. Any thoughts are greatly appreciate. Thanks much, --Adam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Fwd: problems running grass7 on Ubuntu 12.04
I am trying to run GRASS 7 on Ubuntu 12.04. I am new to both GRASS and Ubuntu. I believe I have it installed, but can't get version 7 to run. When I search my Ubuntu Software Center it shows grass70 as installed. In a terminal when I type 'grass' I am prompted to run v. 6.4.3. When I type grass70 I receive the following message. /usr/bin/grass70: 25: exec: /usr/lib/grass70/etc/Init.sh: not found I need to run GRASS 7 as I am trying to investigate the functionality of an add-on that is specific to this version. Certainly I have missed something along the way. Can anyone help get me on track? Thanks. Chad ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Fwd: problems running grass7 on Ubuntu 12.04
Chad Ferguson wrote: I am trying to run GRASS 7 on Ubuntu 12.04. I am new to both GRASS and Ubuntu. I believe I have it installed, but can't get version 7 to run. Hi Chad! How did you proceed in getting the software installed? If I am not wrong, the current version in the official Ubuntu repositories should (still) be 6.4.2-2build1 -- this is what you should normally see in Ubuntu's Software Center. If you see 6.4.3 and version 7 as well, does this mean that you added the some Ubuntu-GIS repository? Following links are recommended: * https://wiki.ubuntu.com/UbuntuGIS * https://launchpad.net/~ubuntugis/+archive/ppa/ When I search my Ubuntu Software Center it shows grass70 as installed. O-kay. In a terminal when I type 'grass' I am prompted to run v. 6.4.3. When I type grass70 I receive the following message. /usr/bin/grass70: 25: exec: /usr/lib/grass70/etc/Init.sh: not found Confused... :-/ I need to run GRASS 7 as I am trying to investigate the functionality of an add-on that is specific to this version. Certainly I have missed something along the way. Can anyone help get me on track? Try this from the scratch (if you want): 1. remove any installed grass package, e.g. by executing in a terminal sudo dpkg -r grass OR, simply search remove it within from the Software Center! 2. Add the ubuntugis-testing repository available in Launchpad: https://launchpad.net/~ubuntugis/+archive/ubuntugis-testing. The easiest way is to launch a Terminal, and execute the following: sudo add-apt-repository ppa:ubuntugis/ubuntugis-testing sudo apt-get update 3. Install grass7 from either the Terminal by instructing; sudo apt-get install grass70 OR via the Software Center (it should appear!) 4. Launch grass70 via the terminal OR via Ubuntu's menu (should be also easy to trace once installed!) Gd Luck, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Geomorphons and extension manager
Hi, missing function definitions added in svn with r55235 now it builds. I'll leave the other compiler warnings for the authors to look at ... Hamish --- On Tue, 2/26/13, Moskovitz, Bob@DOC bob.moskov...@conservation.ca.gov wrote: From: Moskovitz, Bob@DOC bob.moskov...@conservation.ca.gov Subject: Re: [GRASS-user] Geomorphons and extension manager To: Robert Andrew Brown brown...@purdue.edu, grass-user@lists.osgeo.org grass-user@lists.osgeo.org Cc: Phillip Owens prow...@purdue.edu, jar...@amu.edu.pl jar...@amu.edu.pl Date: Tuesday, February 26, 2013, 3:38 PM When I tried to compile r.geomorphon, I got the errors you see below. I just tried g.extensions with similar results. $ make MODULE_TOPDIR=/home/bob/dev/gis/grass70 test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grassmods\ -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/geom.o -c geom.c geom.c: In function ‘ternary_rotate’: geom.c:21:5: warning: unused variable ‘res’ [-Wunused-variable] geom.c: In function ‘radial2cartesian’: geom.c:188:21: warning: ordered comparison of pointer with integer zero [-Wextra] geom.c: In function ‘extends’: geom.c:198:37: warning: unused parameter ‘pattern_size’ [-Wunused-parameter] geom.c: At top level: geom.c:2:15: warning: ‘dirs’ defined but not used [-Wunused-variable] gcc -g -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\grassmods\ -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/bob/dev/gis/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/main.o -c main.c main.c: In function ‘main’: main.c:177:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:198:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:207:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:213:2: warning: format not a string literal and no format arguments [-Wformat-security] main.c:220:3: warning: format not a string literal and no format arguments [-Wformat-security] main.c:234:3: warning: format not a string literal and no format arguments [-Wformat-security] main.c:310:8: warning: format not a string literal and no format arguments [-Wformat-security] main.c:366:5: error: implicit declaration of function ‘radial2cartesian’ [-Werror=implicit-function-declaration] main.c:401:2: error: implicit declaration of function ‘write_contrast_colors’ [-Werror=implicit-function-declaration] main.c:268:20: warning: unused variable ‘formC’ [-Wunused-variable] main.c:268:13: warning: unused variable ‘formB’ [-Wunused-variable] main.c:268:6: warning: unused variable ‘formA’ [-Wunused-variable] main.c:76:22: warning: unused variable ‘radius’ [-Wunused-variable] main.c:74:11: warning: unused variable ‘n’ [-Wunused-variable] main.c:74:8: warning: unused variable ‘j’ [-Wunused-variable] main.c:463:1: warning: control reaches end of non-void function [-Wreturn-type] cc1: some warnings being treated as errors make: *** [OBJ.x86_64-unknown-linux-gnu/main.o] Error 1 From: grass-user-boun...@lists.osgeo.org [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Robert Andrew Brown Sent: Tuesday, February 26, 2013 9:21 AM To: grass-user@lists.osgeo.org Cc: Phillip Owens Subject: [GRASS-user] Geomorphons and extension manager To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have
Re: [GRASS-user] 3-D plane workflow
Adam wrote: I would like to be able to put some surfaces in the space over a DEM. in NVIZ, add a new raster surface, and set the map to a constant value instead of a map name. You can either change the value of the constant or the z-position offset to move it around. For a finite surface area, use r.plane or like r.mapcalc constmap = 100 and load a second raster surface in NVIZ's raster controls. You can also set its transparency level to make it translucent for a nice see-through effect. 3D vector faces may work as well, but they are not as mature. Hamish ps- Helena/Carla: re. the shading I think there is some bug in at least tcl/tk NVIZ where one of the light sources (the direct one?) gets turned off and does not go back on. the only way back is to save the state and restart NVIZ. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 3-D plane workflow
On 2/26/13 9:56 PM, Hamish hamis...@yahoo.com wrote: Adam wrote: I would like to be able to put some surfaces in the space over a DEM. in NVIZ, add a new raster surface, and set the map to a constant value instead of a map name. You can either change the value of the constant or the z-position offset to move it around. That won't do what I need. The problem is that the planes I want are finite and not horizontal. Instead they are polygons where I have the corner points defined. For example, just picture an arbitrarily oriented square floating in space over the DEM based ground. For a finite surface area, use r.plane or like r.mapcalc constmap = 100 and load a second raster surface in NVIZ's raster controls. I suppose I could calculate out the dip and azimuth for r.plane, or the equivalent equations for r.mapcalc. Then, I would need to generate a mask as well. Another thought that I had was to import the points as vectors, then to use r.surf.nnbathy to generate the raster surface values. You can also set its transparency level to make it translucent for a nice see-through effect. 3D vector faces may work as well, but they are not as mature. Hamish ps- Helena/Carla: re. the shading I think there is some bug in at least tcl/tk NVIZ where one of the light sources (the direct one?) gets turned off and does not go back on. the only way back is to save the state and restart NVIZ. Thanks for the info. It is helpful. --Adam ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass prompt default working directory
Le mardi 26 février 2013 à 12:30 -0800, Hamish a écrit : re. and more, fwiw, I find adding this to ~/.inputrc is much nicer to use than ^r, # Bind page up/down wih history search - \e[5~: history-search-backward \e[6~: history-search-forward type the first few letters, then PgUp to see earlier matches.. So nice ! Thx a lot Hamish, Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
