Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by mlennert): Replying to [comment:9 nikosa]: O-K, I see. So, not even a flag -v that will work *only* when a vector= and will obtain the bounding box coordinates of the queried vector map/feature(s)? -1 As the others, I do not think that setting region and mask should be mixed in one single module. They are two different things. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/1838#comment:10 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] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by nikosa): O-K, thank you all for your feedback. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1838#comment:11 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] interp_type: cubic | bicubic
Hi, 2013/5/21 Markus Neteler nete...@osgeo.org: It would be important to also update the HTML pages: cd grass70/dist.x86_64-unknown-linux-gnu/docs/html grep 'bilinear\|bicubic' * | wc -l 53 otherwise it becomes inconsistent... I am not sure if we can replace all occurrences in the manual automatically (eg. by `sed`). Probably it will need some extra care(?) Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1976: r.mapcalc: Allow rounding of floating numbers
#1976: r.mapcalc: Allow rounding of floating numbers
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.mapcalc|Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by glynn):
Replying to [comment:2 mmetz]:
The output type of round() is now the same like the input type.
This changes long-standing behaviour in a way which could break scripts.
E.g. if k is an integer,
{{{
round(x) / k
}}}
would always evaluate to an integer, whereas now it may result in a
fraction.
Rounding to a given number of decimal places is supported with round(x,
y)
From the mailing list discussion ...
Rounding to a given number of decimals is unnecessarily limiting. The
algorithm for generalised rounding is essentially:
{{{
roundTo(x, k) = round(x / k) * k.
}}}
Rounding to N decimal places is just a case of using k=1/10^N^. If you
allow k to be specified directly, then you can round to arbitrary
steps (e.g. k=5 would round to the nearest multiple of 5, etc).
However: there's a slight problem with doing it that way: 0.1 isn't
exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it
would be more accurate to use:
{{{
roundTo(x, k) = round(x * k) / k
}}}
where k is the reciprocal of the step, so k=10^N^ to round to N decimal
places (or k=2 to round to 1/2).
The downside is that the interface is less useful if you want to round
to something other than a fixed number of decimal places. E.g. if you
wanted to round to the nearest multiple of 45 degrees, you'd need to
use k=1.0/45, which isn't exactly representable.
Unless someone has a better idea, I plan to change the round() function so
that the second argument is the step value, and add an roundi() (round-
inverse) function where the second argument is the reciprocal of the step
value (to avoid the rounding error when using a step of 10^-N^).
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1976#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] Overflow warning in r.mapcalc calculation
Paulo van Breugel wrote: In case you haven't seen it, Markus Metz has implemented in trunk r56313 http://trac.osgeo.org/grass/changeset/56313 the option to have the same raster type as output of round() as the input type, see ticket 1976 (http://trac.osgeo.org/grass/ticket/). I've seen it. Don't rely upon that behaviour, as I intend to change it: http://trac.osgeo.org/grass/ticket/1976#comment:4 -- 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] Backporting the start_rast option in r.walk
On Tue, May 21, 2013 at 7:39 AM, Pierre Roudier pierre.roud...@gmail.com wrote: I am a happy user the start_rast option in r.walk in GRASS 7, Recently I realised that the option is not available on the stable version of GRASS (6.4.2) when a student here tried one of my scripts. Is there any plan to backport this, or should the student switch to GRASS 7? No current plans, I think (too much work). The student will gain from switching also in terms of the other many improvements: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1976: r.mapcalc: Allow rounding of floating numbers
#1976: r.mapcalc: Allow rounding of floating numbers
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.mapcalc|Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [comment:4 glynn]:
Replying to [comment:2 mmetz]:
The output type of round() is now the same like the input type.
This changes long-standing behaviour in a way which could break scripts.
OK. Restoring the original behaviour for round(x) is easy. But it would be
nice to have a round(x, y) function that preserves the data type of x in
order to have a possibility to avoid integer overflow.
Rounding to a given number of decimal places is supported with
round(x, y)
From the mailing list discussion ...
Rounding to a given number of decimals is unnecessarily limiting. The
algorithm for generalised rounding is essentially:
{{{
roundTo(x, k) = round(x / k) * k.
}}}
Rounding to N decimal places is just a case of using k=1/10^N^. If you
allow k to be specified directly, then you can round to arbitrary
steps (e.g. k=5 would round to the nearest multiple of 5, etc).
I was just looking at the function round() in R which rounds to decimal
places. Generalised rounding makes more sense.
However: there's a slight problem with doing it that way: 0.1 isn't
exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it
would be more accurate to use:
{{{
roundTo(x, k) = round(x * k) / k
}}}
where k is the reciprocal of the step, so k=10^N^ to round to N decimal
places (or k=2 to round to 1/2).
Unless someone has a better idea, I plan to change the round() function
so that the second argument is the step value, and add an roundi() (round-
inverse) function where the second argument is the reciprocal of the step
value (to avoid the rounding error when using a step of 10^-N^).
Sounds good to me.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1976#comment:5
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] #1976: r.mapcalc: Allow rounding of floating numbers
On Tue, May 21, 2013 at 5:00 PM, GRASS GIS t...@osgeo.org wrote:
#1976: r.mapcalc: Allow rounding of floating numbers
-+--
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.mapcalc|Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [comment:4 glynn]:
Replying to [comment:2 mmetz]:
The output type of round() is now the same like the input type.
This changes long-standing behaviour in a way which could break scripts.
OK. Restoring the original behaviour for round(x) is easy. But it would be
nice to have a round(x, y) function that preserves the data type of x in
order to have a possibility to avoid integer overflow.
I am not sure I understand the solution proposed by Glyn, but does it mean
we are back at the results of round always be an integer? That would be
disappointing imho. Preserving the data type does make so much more sense.
Rounding to a given number of decimal places is supported with
round(x, y)
From the mailing list discussion ...
Rounding to a given number of decimals is unnecessarily limiting. The
algorithm for generalised rounding is essentially:
{{{
roundTo(x, k) = round(x / k) * k.
}}}
Rounding to N decimal places is just a case of using k=1/10^N^. If you
allow k to be specified directly, then you can round to arbitrary
steps (e.g. k=5 would round to the nearest multiple of 5, etc).
I was just looking at the function round() in R which rounds to decimal
places. Generalised rounding makes more sense.
However: there's a slight problem with doing it that way: 0.1 isn't
exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it
would be more accurate to use:
{{{
roundTo(x, k) = round(x * k) / k
}}}
where k is the reciprocal of the step, so k=10^N^ to round to N decimal
places (or k=2 to round to 1/2).
Unless someone has a better idea, I plan to change the round() function
so that the second argument is the step value, and add an roundi() (round-
inverse) function where the second argument is the reciprocal of the step
value (to avoid the rounding error when using a step of 10^-N^).
Sounds good to me.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1976#comment:5
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] SQL where= parameter for v.proj ?
Hi devs! Another vector related question: is it possible, and if yes, would it make sense, to have support for SQL condition statements (i.e. a where= parameter) in v.proj? Thank you, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Backporting the start_rast option in r.walk
MarkusN wrote: The student will gain from switching also in terms of the other many improvements: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures fwiw, others may disagree, but IMO development code should never be used for final runs, and while testers are most welcome, they should be prepared and able to dig themselves out of unknown trouble. I can cite times in the past where the dev code silently produced bad data for some months before a bug was caught (saved me a month+ of reprocessing time by using the stable version for the production runs), others in the dev code where `rm -rf $TMP*` deleted all files in someone's home dir when g.tempfile failed on Mac without a check around it, and the general time sink of chasing a moving target. In addition, if the student will want to publish anything, it would look a lot better to the reviewers w.r.t. reproducible results if an official version is cited in the methods section. in the case of the r.walk option it is not new at all; I'm just speaking generally, and with an abundance of caution. Porting raster C code between G6 and G7 takes a bit of work, but typically it's just changing a few function names. As Markus notes this one is a bit too complicated for official backport consideration, but people can do what they like at home. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] interp_type: cubic | bicubic
Martin wrote: I am not sure if we can replace all occurrences in the manual automatically (eg. by `sed`). Probably it will need some extra care(?) perhaps some combination of 'grep -rI' for hits, a quick look at the file it found, then 'sed -i -e' on the file if it's ok? could be pretty quick for something as rare as bilinear. When describing the method it is perhaps good to leave some mention of bilinear and bicubic in the help pages, to aid with web/module description searches where linear and cubic would be too generic terms to get to the right answer quickly. see also the grass-addons/tools/svngrep script to help avoid some false positives in doing the recursive greps. Hamish ps- Martin, any comment on #1971? thanks ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
