Re: [GRASS-dev] Is grass70b4 compiling on FreeBSD ?
(@64055) Additional stuff # portmaster databases/py-sqlite3 textproc/xmlcatmgr x11-toolkits/wxgtk28 x11-toolkits/py-wxPython28 (default options all around - takes a while and pulls in a lot of stuff) then I removed the /usr/local/include/iconv.h $ ./configure ... $ gmake Errors in: /usr/home/diasf/grass70_release/gui/wxpython/iclass ImportError: Numeric,numarray or NumPy not found. Which is weird, because math/py-numpy is already installed. F -- -=--=-=- Fábio Augusto Salve Dias ICMC - USP http://sites.google.com/site/fabiodias/ On Sat, Jan 10, 2015 at 6:51 PM, Glynn Clements gl...@gclements.plus.com wrote: Fábio Dias wrote: Full installation log, fresh system: http://pastebin.com/ARDd1HQv /usr/include/iconv.h http://pastebin.com/yf6ycz66 /usr/local/include/iconv.h (installed by cairo afaik) http://pastebin.com/7BMNAMYA gmake on lib/gis http://pastebin.com/PAgAfnfh IOW, libgis is fine, but libgrass_cairodriver (which presumably pulls in /usr/local/include/iconv.h) has a libiconv dependency. I don't see any easy solution other than to remove or hide /usr/local/include/iconv.h while building GRASS. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by cmbarton):
Replying to [comment:183 neteler]:
While checking all QGIS processing files
(https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7)
I have cleaned up lib/gis/renamed_options (r64056 + r64057, r64062 +
r64063).
A few thoughts
The following issues are open (TODO):
* r.mapcalculator: outfile - output? (any implications in the wxGUI?)
Yes. This will break the GUI map calculator. Why the change? Doesn't the
map calculator always create a new file?
* r.param.scape: param - method?
* r.walk; percent_memory - memory?
These seem OK
Then here I suggest to update for consistency:
{{{
v.lidar.correction
sce Interpolation spline step value in east direction
default: 25
scn Interpolation spline step value in north direction
default: 25
-- ew_step/ns_step (as in v.surf.bspline)
v.lidar.edgedetection
see Interpolation spline step value in east direction
default: 4
sen Interpolation spline step value in north direction
default: 4
-- ew_step/ns_step (as in v.surf.bspline)
These are definitely an improvement
No idea if the default values should be the same?
If this works like v.surf.bspline, the defaults are almost always wrong.
Some multiple of the current resolution (2X or 10X) would be better than
the current default of 4. It is much better for this number to be larger
than optimum than smaller than optimum.
v.surf.bspline has an option to calculate a reasonable spline step that
runs very quickly. I assume that this is the same algorithm found in the
lidar processing modules. A note suggesting using this option would be
good to add to the spline step description for all modules.
Michael
}}}
Eventually a potential issue in file lib/gis/renamed_options:
{{{
# r.reclass.area
r.reclass.area|lesser,greater:value, mode
-- syntax ok?
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:184
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] integrate v.concave.hull into v.hull [was point cloud analysis: new features]]
On Fri, Jan 9, 2015 at 9:35 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 08/01/15 23:46, Markus Metz wrote: On Mon, Jan 5, 2015 at 12:17 PM, Benjamin Ducke bendu...@fastmail.fm wrote: Thanks Markus, this is excellent progress. It seems to me that the approximation of cluster shapes from grouped points is a generic problem that would best be solved with a separate module. As long as the shapes are roughly convex, the existing v.hull should work fine. For concave shapes, AFAIK things become messy because common methods such as alpha shapes require the user to provide threshold values. This is true, but v.concave.hull [0] could help ;-) All these great addons ! For this particular one: would it be interesting / possible to integrate it directly into v.hull ? No, because v.hull is a C module and v.concave.hull a script which does not use v.hull at all. Instead, v.concave.hull cleans the output of v.delaunay to create concave hulls. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unifing naming of 3D rasters
On Sun, Jan 11, 2015 at 6:05 AM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, I've tried to unify usage of 3D raster (map) in the most visible parts of documentation and interface, namely 3D raster intro, 3D view and menu (and module tree). There are few things missing. For example, keyword link is dead because it goes to raster3d.html but the family page is raster3D.html. All occurrences of raster3D, including the one in PyGRASS, should be probably replaced by raster3d or another appropriate form (3D raster or raster_3d). I suppose it should all become raster_3d for consistency. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by neteler):
While checking all QGIS processing files
(https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/grass7)
I have cleaned up lib/gis/renamed_options (r64056 + r64057, r64062 +
r64063).
The following issues are open (TODO):
* r.mapcalculator: outfile - output? (any implications in the wxGUI?)
* r.param.scape: param - method?
* r.walk; percent_memory - memory?
Then here I suggest to update for consistency:
{{{
v.lidar.correction
sce Interpolation spline step value in east direction
default: 25
scn Interpolation spline step value in north direction
default: 25
-- ew_step/ns_step (as in v.surf.bspline)
v.lidar.edgedetection
see Interpolation spline step value in east direction
default: 4
sen Interpolation spline step value in north direction
default: 4
-- ew_step/ns_step (as in v.surf.bspline)
No idea if the default values should be the same?
}}}
Eventually a potential issue in file lib/gis/renamed_options:
{{{
# r.reclass.area
r.reclass.area|lesser,greater:value, mode
-- syntax ok?
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:183
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] point cloud analysis: new features
On Fri, Jan 9, 2015 at 11:45 AM, Benjamin Ducke bendu...@fastmail.fm wrote:
On 08/01/15 23:46, Markus Metz wrote:
[..]
Thanks Markus, this is excellent progress.
It seems to me that the approximation of cluster shapes from grouped
points is a generic problem that would best be solved with a separate
module. As long as the shapes are roughly convex, the existing v.hull
should work fine. For concave shapes, AFAIK things become messy because
common methods such as alpha shapes require the user to provide
threshold values.
This is true, but v.concave.hull [0] could help ;-)
Markus M
[0]
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.concave.hull
Wow. And it's been there for a while. How could I not see that?
I think it's high time that I switch from GRASS 6 to 7.
Indeed.
Nevertheless, since you did all that work on v.cluster in GRASS 6,
maybe it would be worth implementing this:
v.cluster exists only in GRASS 7.1. It can not even be backported ti
GRASS 7.0 because it relies on a new (new to GRASS) spatial index that
is only available in GRASS 7.1.
http://grasswiki.osgeo.org/wiki/Create_concave_hull
... in a GRASS 6 shell script?
If you know Python and shell scripting, translating v.concave.hull to
a shell script is easy. Otherwise, chances are good that the Python
script v.concave.hull also runs with GRASS 6. Maybe some option names
need to be modified.
Markus M
I am looking forward to trying the new clustering algorithms,
especially density and optics2
Many thanks,
Ben
--
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-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by annakrat):
Replying to [comment:183 neteler]:
The following issues are open (TODO):
* r.mapcalculator: outfile - output? (any implications in the wxGUI?)
what is r.mapcalculator?
* r.param.scape: param - method?
* r.walk; percent_memory - memory?
+1
Eventually a potential issue in file lib/gis/renamed_options:
{{{
# r.reclass.area
r.reclass.area|lesser,greater:value, mode
-- syntax ok?
}}}
I would remove it from there, because the logic of the parameters changed
so you cannot easily map the old name to a new name.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:185
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by neteler): Replying to [comment:184 cmbarton]: Replying to [comment:183 neteler]: * r.mapcalculator: outfile - output? (any implications in the wxGUI?) Yes. This will break the GUI map calculator. Why the change? Doesn't the map calculator always create a new file? I propose the change for consistency. Isn't the result a map rather than a file (we use that for eg ASCII file output)? So the parameter name should be output then. Replying to [comment:185 annakrat]: Replying to [comment:183 neteler]: The following issues are open (TODO): * r.mapcalculator: outfile - output? (any implications in the wxGUI?) what is r.mapcalculator? No idea, I found it in the QGIS processing scripts being used. In GRASS, it is here: scripts/r.mapcalculator/r.mapcalculator -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:186 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by glynn): Replying to [comment:187 wenzeslaus]: `r.mapcalculator` may create some confusion because is not part of standard GRASS GIS distribution (compilation switched off by default). It is also not in the documentation. I don't know if the confusion is also on the QGIS site. Another issue is that it is in Shell, not Python, so it should not work in GRASS 7 on MS Windows as far as I understand. Finally, so revision of messages is needed, error message Calculating $GIS_OPT_OUTFILE. Try expert mode. shown after `r.mapcalc` failed just caught my eye. r.mapcalculator was never converted to Python. It was deemed unnecessary now that r.mapcalc uses G_parser(). r.mapcalculator was created when r.mapcalc didn't use G_parser() which meant that it couldn't generate a GUI option dialog. If there's some situation where it's useful, it should be converted to Python. Otherwise, it should be removed from the 7.0 tree. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:189 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by wenzeslaus): Replying to [comment:186 neteler]: Replying to [comment:184 cmbarton]: Replying to [comment:183 neteler]: * r.mapcalculator: outfile - output? (any implications in the wxGUI?) Yes. This will break the GUI map calculator. Perhaps some !Tcl/Tk one, I don't know. wxGUI raster map calculator is using `r.mapcalc`. `r.mapcalculator` is not used anywhere in GRASS GIS according to my knowledge and `grep` search. Why the change? Doesn't the map calculator always create a new file? I propose the change for consistency. Isn't the result a map rather than a file (we use that for eg ASCII file output)? So the parameter name should be output then. It should be changed to output. Any option which is name of some kind of output should be named output by default. Reason to name it different would be for example more than one option which is a name of something on output. Also, we are not using file to denote raster map (for various reasons). Replying to [comment:185 annakrat]: Replying to [comment:183 neteler]: The following issues are open (TODO): * r.mapcalculator: outfile - output? (any implications in the wxGUI?) what is r.mapcalculator? No idea, I found it in the QGIS processing scripts being used. In GRASS, it is here: scripts/r.mapcalculator/r.mapcalculator QGIS processing needs to use `r.mapcalculator` instead of `r.mapcalc` because it needs to convert input maps and output maps to and from GRASS GIS but in case of `r.mapcalc`, map names are hidden in the expression. `r.mapcalculator` on the other hand, has several options which are map names and output is not part of the expression but also an option as it would be for other modules. Similar issues applies to more modules as I posted here or to the basename/prefix ticket. I recently fixed `r.ros`. I learned about these issues and `r.mapcalculator` in [http://lists.osgeo.org/pipermail/grass- dev/2014-August/070342.html GRASS-dev QGIS Processing GRASS]. `r.mapcalculator` may create some confusion because is not part of standard GRASS GIS distribution (compilation switched off by default). It is also not in the documentation. I don't know if the confusion is also on the QGIS site. Another issue is that it is in Shell, not Python, so it should not work in GRASS 7 on MS Windows as far as I understand. Finally, so revision of messages is needed, error message Calculating $GIS_OPT_OUTFILE. Try expert mode. shown after `r.mapcalc` failed just caught my eye. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:187 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: QGIS Processing GRASS
Well, this email is older but was never answered. I guess in most cases the situation is still the same. On Thu, Aug 7, 2014 at 3:45 PM, Markus Neteler nete...@osgeo.org wrote: Forwarded message from Giovanni Manghi: Hi all, as you may know GRASS modules are available in QGIS through the QGIS/GRASS plugin but also through Processing (ex Sextante), that makes it particularly easy to use them because users don't need to know about locations/mapsets. A few GRASS modules are not available in the Processing toolbox, but with a little help this would be probably possible. We are looking for help (a not too advanced python knowledge should be enough) in adding them. As it stands now Processing always expects a GRASS module to create one (or more outputs) from one (or more) inputs. There are obvious exceptions to this, examples: * r.ros (maybe others): the output in this GRASS module is just a prefix for 3/4 output maps with an hardcoded name. Processing does not actually support such case. I've modified r.ros and r.rgb in r63777 and r63796 but there are other which needs the same, I named at least some of them in #2409, comment 182: I cannot work on this more but similar change as I did for r.rgb could be done for r.blend too. It also has an output option which is a basename for red, green and blue output raster maps. There are some other modules I'm not completely sure about such as i.pansharpen and i.topo.corr. Some other seems that they don't need this change (e.g., i.pca, i.landsat.toar, i.landsat.acca, and i.tasscap) because the number of outputs is variable. However, I'm not sure how the suffixes are generated, sometimes it seems that they are even expected on the input. Standard basename separator (underscore, #2136) should be used in all cases otherwise it is not really standard, now many of them are probably using dot. Last issue I know about is r.texture where the number of outputs depends on number of requested textures. r.neighbors actually solves this issue by using output not as a basename but as multiple and requesting as many outputs as requested methods Please read the following to understand more about the issues and possible possible solutions: http://trac.osgeo.org/grass/ticket/2409#comment:12 http://trac.osgeo.org/grass/ticket/2409#comment:13 http://trac.osgeo.org/grass/ticket/2409#comment:14 http://trac.osgeo.org/grass/ticket/2409#comment:17 http://trac.osgeo.org/grass/ticket/2409#comment:179 http://trac.osgeo.org/grass/ticket/2409#comment:182 http://trac.osgeo.org/grass/ticket/2136 *r.null/v.distance: this modules modify the input layer instead of creating a new output In case of r.null it seems like a purpose of the module but maybe it's just point of view. In case of vector modules, they modify very often, especially attribute table. * r.mapcalc: in Processing there is already r.mapcalculator, but it is limited to 6 inputs. R.mapcalc is missing because it uses real map name instead of parameters like A, because it is not limited to 6 inputs and because Processing uses random names for temporary input GRASS layers See the following for discussion: http://trac.osgeo.org/grass/ticket/2409#comment:187 http://trac.osgeo.org/grass/ticket/2409#comment:190 * a few modules would benefit from a coordinate picker from the QGIS map canvas. There is already something similar that allows to choose (from canvas) the region size, so it should be relatively simple In case of coordinates, this should be able to guess from: gisprompt: old,coords,coords The rest is up to the wrapper. However, there are some other places where GRASS GIS could do a better job. Namely, there are standard options but they are write only, i.e. you create an option in standard way but then the information is lost. This is issue in GRASS itself, for example --script will not give you standard options, you have to go to the source code which in this case throws away convenience of --script. * support GRASS layers as input: at the moment Processing imports vector/raster data (non GRASS) and place them on the fly in a temporary mapset, then runs the GRASS module against them. As QGIS can use GRASS data it would be nice to support them also in Processing, it would obviously necessary to skip the import (and eventually export) phase. ...and the other layers could be linked rather than imported (+- projection). This is not something which GRASS can help with unless we decide to build some addition interface which would call GRASS modules from command line and would import/export/link the maps/layers on the fly. Something like: grass70 r.lake elevation=file:///some/file.tiff water_level=10 lake=file:///some/new/file.tiff coordinates=100,520 This idea could be modified to some git/svn/sqlite3/geogig approach with `grass init EPSG:...`, `grass r.external ...`, `grass r.lake elevation=map...` but that's another story. Perhaps a GSoC idea? Vaclav for who may be interested this
Re: [GRASS-dev] Is grass70b4 compiling on FreeBSD ?
Fábio Dias wrote: Errors in: /usr/home/diasf/grass70_release/gui/wxpython/iclass ImportError: Numeric,numarray or NumPy not found. Which is weird, because math/py-numpy is already installed. This is a known issue with the wx.lib.plot module: http://lists.osgeo.org/pipermail/grass-dev/2014-November/071713.html -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by wenzeslaus): Replying to [comment:189 glynn]: Replying to [comment:187 wenzeslaus]: `r.mapcalculator` may create some confusion because is not part of standard GRASS GIS distribution (compilation switched off by default). It is also not in the documentation. I don't know if the confusion is also on the QGIS site. Another issue is that it is in Shell, not Python, so it should not work in GRASS 7 on MS Windows as far as I understand. Finally, so revision of messages is needed, error message Calculating $GIS_OPT_OUTFILE. Try expert mode. shown after `r.mapcalc` failed just caught my eye. r.mapcalculator was never converted to Python. It was deemed unnecessary now that r.mapcalc uses G_parser(). r.mapcalculator was created when r.mapcalc didn't use G_parser() which meant that it couldn't generate a GUI option dialog. If there's some situation where it's useful, it should be converted to Python. Otherwise, it should be removed from the 7.0 tree. I think it is needed for QGIS and perhaps other things wrapping GRASS modules. Although I don't know much, the issue appears to be that they don't know what maps needs to be prepared. I've never really studied the problem. There might be some other way for callers to deal with the expression. For example, temporal framework also wraps `r.mapcalc` and its quite successful. Or `r.mapcalc` or some module derived from it (similarly as `r3.mapcalc` is) can just parse the expression and output the names in some key-value/parseable form, or there can be a Python function for it. Some inside from application developers using GRASS GIS would be helpful. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:190 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by cmbarton): Indeed. I was confused. I assumed that r.mapcalculator was a renaming of r.mapcalc. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:188 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
