Re: [GRASS-dev] [GRASS GIS] #2074: r3.mapcalc neighborhood modifier hash table and tile errors
#2074: r3.mapcalc neighborhood modifier hash table and tile errors
-+--
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster3D | Version: svn-trunk
Keywords: r3.mapcalc |Platform: All
Cpu: Unspecified |
-+--
Comment(by huhabla):
I will try an answer, Glynn, please correct me if i am wrong.
As far as i understand set's {{{putenv(WORKERS=1)}}} the number of
worker threads that have parallel read access to raster 3d maps (reading
values) and perform mapcalc sub-expression evaluation. Since the raster 3d
library was not designed to allow parallel access, a race condition
happens when several threads try to read values in parallel. In this case
the raster 3d map specific tile index gets corrupted.
The environment variable WORKERS will be analysed in lib/gis/worker.c that
implements the creation and execution of pthread based worker threads. The
default number of workers is 8, but can be overwritten using the
environment variable WORKERS.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2074#comment:6
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] #2091: r.series error in GRASS7 wxGUI
#2091: r.series error in GRASS7 wxGUI -+-- Reporter: richardc | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: r.series, wxGui |Platform: Linux Cpu: x86-32 | -+-- Comment(by richardc): I discovered r.series in wxgui works if 7 maps are input, but not 8? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2091#comment:4 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] #2093: --interface-description option broken for some commands
#2093: --interface-description option broken for some commands --+- Reporter: twsmith | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Default | Version: Resolution: wontfix |Keywords: Platform: Linux| Cpu: x86-32 --+- Changes (by martinl): * status: new = closed * resolution: = wontfix * milestone: = 6.4.4 Comment: Modules `r.mapcalc` and `r3.mapcalc` are the exceptions in GRASS 6. They don't use the parser. Options are automatically treated as an expression. In GRASS 7 they use the parser as other commands. Similarly to `g.parser`, it's the only exception in GRASS 7 which do not use parser from obvious reasons. Closing as wontfix. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2093#comment:1 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] #2093: --interface-description option broken for some commands
#2093: --interface-description option broken for some commands --+- Reporter: twsmith | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Default | Version: Resolution: wontfix |Keywords: Platform: Linux| Cpu: x86-32 --+- Comment(by neteler): Sidenote: twsmith, if you need that for anything specific, please contact the grass-dev list to find a solution. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2093#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Video Flashback 1987: Shatner Tells You Where You Can Stick Your Maps
Dear GRASS people, you must see this piece of history :-) (thanks to Peter Loewe who discovered it on the web) http://www.wired.com/wiredscience/2013/08/shatner-loves-digital-maps/ cheers, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Video Flashback 1987: Shatner Tells You Where You Can Stick Your Maps
On Sat, Oct 5, 2013 at 1:23 PM, Margherita Di Leo direg...@gmail.com wrote: Dear GRASS people, you must see this piece of history :-) (thanks to Peter Loewe who discovered it on the web) http://www.wired.com/wiredscience/2013/08/shatner-loves-digital-maps/ You can also enjoy it on our site: http://grass.osgeo.org/home/history/documents/ --- The GRASS Story Video http://grass.osgeo.org/uploads/grass/history_docs/grass_movie_CERL_1987.mov Watch the video (64 MB, 14 minutes, USA CERL, 1987) The U.S. Army Corps of Engineers Construction Engineering Research Laboratory produced this video to explain basic concepts and potential applications of geographic information systems to land managers at Army installations. Although the GRASS GIS is mentioned, the overall presentation of GIS topics is fairly generic. The video present a good, basic introduction to GIS that makes reference to GRASS (GRASS-GIS). --- Years ago we asked Jim Westervelt (CERL) if we could publish it and they agreed. Now a viral video? :-) cheers Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2074: r3.mapcalc neighborhood modifier hash table and tile errors
#2074: r3.mapcalc neighborhood modifier hash table and tile errors
-+--
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster3D | Version: svn-trunk
Keywords: r3.mapcalc |Platform: All
Cpu: Unspecified |
-+--
Comment(by glynn):
Replying to [comment:5 wenzeslaus]:
I would like to understand. Does the
{{{
putenv(WORKERS=1)
}}}
mean that there will be no parallel computation in `r3.mapcalc`?
Yes. When I added pthread support to r.mapcalc, I largely overlooked the
fact that it shares most of its code with !r3.mapcalc, and the raster3d
library doesn't appear to be thread-safe.
I had to make a few changes to libgis and libraster to allow for multiple
threads (e.g. r3), but (as with so many other invasive, project-wide
changes) libraster3d was deemed too much trouble and was left alone.
One alternative would be to use a single mutex for all of the functions in
map3.c. This would allow calculations to be parallelised, but not I/O
(unfortunately, I/O accounts for most of the execution time).
The more complex option is to make libraster3d thread-safe, at least for
accessing different maps from different threads, and have a mutex for each
map to prevent concurrent access from multiple threads (this is what
r.mapcalc does). That would require eliminating some or all of its static
data, or protecting it with mutexes (the functions in lib/gis/counter.c
can be used to safely perform one-shot initialisation).
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2074#comment:7
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] #2092: v.category option=del doesn't delete any categories
#2092: v.category option=del doesn't delete any categories
-+--
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.category |Platform: Linux
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [ticket:2092 marisn]:
According to v.category documentation, option=del should result in
deleting all categories, still it does nothing - all categories are
present after module run.
option=del deletes all categories with the value set with the cat option.
The cat option is by default set to 1, thus only categories with value 1
will be deleted, as happened in the example:
{{{
v.category input=augstumi_merged output=augstumi_merged2 option=del
layer=1
v.category izpildīts. 1 features modified.
}}}
In order to delete all categories of the given layer, cat must be set to
-1. This was nmot clear in the documentation, fixed in r57940.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2092#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2094: v.category GUI doesn't accept category ranges and lists
#2094: v.category GUI doesn't accept category ranges and lists -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Keywords: v.category |Platform: Unspecified Cpu: Unspecified | -+-- v.category option=del operates only on categories provided by cat option (for details see #2092) but GUI allows only to provide single category contrary to other modules that allow to specify category lists and ranges. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2094 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] #2092: v.category option=del doesn't delete any categories
#2092: v.category option=del doesn't delete any categories -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed |Keywords: v.category Platform: Linux | Cpu: Unspecified -+-- Changes (by marisn): * status: new = closed * resolution: = fixed Comment: Replying to [comment:1 mmetz]: option=del deletes all categories with the value set with the cat option. The cat option is by default set to 1, thus only categories with value 1 will be deleted, as happened in the example: Ahhh. This slipped my mind as cat option only accepts single integer and no ranges or lists of categories. Opened a new bug for it: #2094 Closing as issue is fixed, still I would vote for not having cat=1 as default for delete action as it endangers 1st cat to accidental deletion. (Read - why 1st is more special than others? If user forgot to specify cat, let's punish him by nuking 1st cat :P ) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2092#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
