Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
Ah ok Glynn, I always meant logical operators. Probably I copied the error from a different test. If logical operator is applied to, sat, Byte data it gives true/false results, e.g. if(A && B,1, 0) behaves correctly even with cell values values greater then 1. That's why I expected it to work with floats operands too. >From a user perspective if it works for a cell with value 2 it should also work for a cell with value 2.0. That'all. giovanni Il 22/ott/2015 02:44, "Glynn Clements" ha scritto: > > G. Allegri wrote: > > > > This isn't about the if() function. The bitand() function (to which > > > the error message refers) corresponds to the bitwise-and operator "&". > > > > > > The if() function accepts either integer or floating-point values for > > > its arguments. > > > > That's what disappointed my client (and me) Glynn: why integer yes and > not > > floats? Is it a technical limitation or there's a ratio behind it? > > Anyway did I miss something from the docs? I couldn't find it. > > What would you expect the value of (x & y) to be if x and/or y were > floating-point values? > > > Why do you that I'm confusing the operators? I've always talked about > > logical operators... > > Because you quote an error message which specifically refers to a > *bitwise* operator: > > > "Incorrect argument types to function bitand()". > > in a message which otherwise only mentions logical operators. > > "bitand()" is the name of the bitwise-and function, which corresponds to > the infix "&" operator. I.e. (x & y) is exactly equivalent to bitand(x, y). > > This is the same as the "&" operator in C or C++: it evaluates to an > integer where each bit in the result is set (one) if the corresponding > bit is set in both operands, and unset (zero) otherwise. E.g. (23 & 34) > is > 00010111 (23) > & 00100010 (34) > > = 0010 ( 2) > > Perhaps it would help if you posted the exact expression which is > causing you problems. > > -- > Glynn Clements > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
G. Allegri wrote: > > This isn't about the if() function. The bitand() function (to which > > the error message refers) corresponds to the bitwise-and operator "&". > > > > The if() function accepts either integer or floating-point values for > > its arguments. > > That's what disappointed my client (and me) Glynn: why integer yes and not > floats? Is it a technical limitation or there's a ratio behind it? > Anyway did I miss something from the docs? I couldn't find it. What would you expect the value of (x & y) to be if x and/or y were floating-point values? > Why do you that I'm confusing the operators? I've always talked about > logical operators... Because you quote an error message which specifically refers to a *bitwise* operator: > "Incorrect argument types to function bitand()". in a message which otherwise only mentions logical operators. "bitand()" is the name of the bitwise-and function, which corresponds to the infix "&" operator. I.e. (x & y) is exactly equivalent to bitand(x, y). This is the same as the "&" operator in C or C++: it evaluates to an integer where each bit in the result is set (one) if the corresponding bit is set in both operands, and unset (zero) otherwise. E.g. (23 & 34) is 00010111 (23) & 00100010 (34) = 0010 ( 2) Perhaps it would help if you posted the exact expression which is causing you problems. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map algebra logical operators on DCELL rasters not admitted? maybe docs should outline it
Moritz Lennert wrote: > >> Doing a logical operation with a DCELL raster within an if(x,a) statement > >> produces an error: "Incorrect argument types to function bitand()". > > > > First, you're confusing bitwise operators and logical operators. & and > > | are bitwise operators, while && and || (and &&& and |||) are logical > > operators. > > > > Second, both bitwise and logical operators only work on integer > > values. If you want to use floating-point values as boolean values, > > you need to explicitly convert them to integers (either via int(x) or > > round(x), or x==0.0, or abs(x)<1e-30, or whatever). > > ??? > > On my grass71 and grass64release, these work (using NC demo data set): > > r.mapcalc "test = if(elevation == 100.0, 1)" > r.mapcalc "test = if(elevation > 100.0, 1)" > > where elevation is FCELL. I would expect those to work. What won't work is using bitwise operators (& and |) or logical operators (&& and ||, &&& and |||) on floats. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Parallel processes
Dylan Beaudette wrote: > My main motivation for asking this question was to determine instances > where parallel operations in GRASS are _not_ safe. From my reading of > the wiki, manual pages, and your recent comments on GRASS-dev, it > would appear that the following operations may not be safe: > > 1. region-altering Commands which modify the WIND or VAR files cannot safely be executed in parallel. Similarly, commands which overwrite maps or modify database tables cannot safely be executed in parallel if they will (or might) modify the same maps, tables, etc. For commands which create new maps (or similar), you need to ensure that they don't concidentally choose the same name for their outputs. In short, GRASS doesn't attempt to "lock" maps, files, or similar entities which it modifies, beyond the fact that each GRASS "session" locks its current mapset. > 2. calculations in the presence of a MASK > > 3. reading "external" (r.external) GDAL sources (?) > > 4. some mapcalc expressions These should be safe if the parallelism is in the form of multiple processes. The known or suspected issues with r.mapcalc are related to using multiple threads within a single process. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.3d -r option not working properly
> I think how it currently works, doesn't make sense for the reverse case, > please create a ticket. The column should be created in the new vector. > Done: https://trac.osgeo.org/grass/ticket/2774 Thanks! Pedro ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.3d -r option not working properly
On Wed, Oct 21, 2015 at 4:15 AM, Pedro Venâncio wrote: > Hi Anna, > > > > Will this be backported to 7.0.x? >> >> I believe I backported it, 7.0.2 RC1 release is just going on now, there >> will be an announcement soon. >> >> > Thanks, I will check! > > > > >>> >>> Then I wanted to transform the z-coordinate to > an attribute column using > v.to.3d -r input=contour_3d col="CONC" output=contour_2d > (I added CONC column to contour_3d before, using v.db.addcol > map=contour_3d > columns="CONC double precision"). > However, the resulting contour_2d column CONC remains empty. No error > is > reported. > > >>> It is not possible to avoid this procedure, of creating the new column >>> in the layer of origin (3d layer), to get the height column in the 2d >>> layer? Something like the 'column' parameter of v.random (Name of column >>> for z values; Writes z values to column), where we just give a name to the >>> height column in the resulting layer? >>> >>> >>> > What do you think about this workflow? > I think how it currently works, doesn't make sense for the reverse case, please create a ticket. The column should be created in the new vector. > > Thanks! > Pedro > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 3D Rectification
Hi, I am wondering if it is possible to do some kind of 3D rectification in GRASS GIS based on multiple simultaneously captured photographs from different positions/angles. In other words, assuming one has 3 photographs of an object from 3 different angles. All of the photographs include common reference points with known coordinates (X,Y,Z). How can one extract get/calculate the 3D-coordinates of a point of the object that is visible in all 3 photographs? Probably this is not a task for GRASS GIS but maybe someone has done something similar before. Any hints are welcome! Best regards, Johannes ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Parallel processes
Dylan A small sidenote on your issue. I also use GNU parallel for operations that have to run on very large scales. Never had problems with it when running it on different mapsets, i.e. I create a temporary mapset in my scripts that are wrapped by the command. Storing the data back to a main mapset or PostgreSQL allows to delete the temporary mapsets at the end of each process. Maybe a kind of hack, but works well for me. Always happy on feedback to optimize these ;-) Greetz, Patrick On 20.10.2015 19:09, grass-user-requ...@lists.osgeo.org wrote: Thank you Glynn, your advice confirms some empirical notes: 1. parallel processes that use data from external USB disks quickly saturate the capacity of the bus or mechanism of the drive 2. parallel processes that use data from an internal SSD can generally saturate all 8 cores of my Intel i7 My main motivation for asking this question was to determine instances where parallel operations in GRASS are_not_ safe. From my reading of the wiki, manual pages, and your recent comments on GRASS-dev, it would appear that the following operations may not be safe: 1. region-altering 2. calculations in the presence of a MASK 3. reading "external" (r.external) GDAL sources (?) 4. some mapcalc expressions In order to simplify my testing, I have disabled pthread support and invoke "parallelization" via backgrounding or GNU parallel. My examples with GNU parallel stem from the tremendous (apparent) utility of this tool, in that most "bash for loops" can be directly converted into "smart" parallel jobs. Thanks, Dylan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.3d -r option not working properly
Hi Anna, Will this be backported to 7.0.x? > > I believe I backported it, 7.0.2 RC1 release is just going on now, there > will be an announcement soon. > > Thanks, I will check! >> >> Then I wanted to transform the z-coordinate to >>> an attribute column using v.to.3d -r input=contour_3d col="CONC" output=contour_2d (I added CONC column to contour_3d before, using v.db.addcol map=contour_3d columns="CONC double precision"). However, the resulting contour_2d column CONC remains empty. No error is reported. >> It is not possible to avoid this procedure, of creating the new column in >> the layer of origin (3d layer), to get the height column in the 2d layer? >> Something like the 'column' parameter of v.random (Name of column for z >> values; Writes z values to column), where we just give a name to the height >> column in the resulting layer? >> >> >> What do you think about this workflow? Thanks! Pedro ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
