[GRASS-dev] Fixed: GRASS-GIS/grass-ci#2158 (master - 959c675)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #2158
Status: Fixed

Duration: 6 minutes and 15 seconds
Commit: 959c675 (master)
Author: Anna Petrášová
Message: r.random: fix broken build

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@71075 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/68f9d4bd6545...959c6758db73

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/230595573?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Broken: GRASS-GIS/grass-ci#2157 (master - 68f9d4b)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #2157
Status: Broken

Duration: 5 minutes and 41 seconds
Commit: 68f9d4b (master)
Author: Anna Petrášová
Message: r.random: use long long when available

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@71074 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/f549c8f99775...68f9d4bd6545

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/230564605?utm_source=email&utm_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Veronica Andreo]

Now it works! Thanks a lot for such a quick fix :)

best,
Vero

2017-05-09 15:25 GMT+02:00 Moritz Lennert :

> On 09/05/17 15:13, Moritz Lennert wrote:
>
>> On 09/05/17 15:03, Moritz Lennert wrote:
>>
>>> On 09/05/17 14:37, Veronica Andreo wrote:
>>>
 Hello Pierre,

 Thanks for this new add-on! Comes on time for me :)

 I'm testing it and I have observed something odd.
 I'm querying integer maps but v.what.rast.multi gives me float values. I
 run v.what.rast and I get the proper integer values. Does it have
 anything to do with what Paulo just pointed out?

>>>
>>>
>>> The module just loops over a series of v.what.rast calls, so results
>>> should not be different. If any, Paulo's point reinforces this as the
>>> '-i' flag (i.e.interpolate nearest points) is never used...
>>>
>>
>> Sorry, I take that back: the -i flag is always set as what is passed on
>> to v.what.rast is 'flags' and without the '-i' flag set still is
>> non-null (it contains "{'i': False}") and so
>>
>> 'if (interp_flag->answer)'
>>
>> in v.what.rast/main.c returns true.
>>
>> So, yes the issue is linked to Paulo's remark.
>>
>
> Fixed in r71072.
>
> But
>
> v.what.rast.multi map=test raster=elev_srtm_30m,elev_ned_30m,srtm,ned
> columns=srtm_float_nofl,ned_float_nofl,srtm_int_nofl,ned_int_nofl
>
> v.what.rast.multi -i map=test raster=elev_srtm_30m,elev_ned_30m,srtm,ned
> columns=srtm_float_fl,ned_float_fl,srtm_int_fl,ned_int_fl
>
> cat|srtm_float_nofl|ned_float_nofl|srtm_int_nofl|ned_int_nof
> l|srtm_float_fl|ned_float_fl|srtm_int_fl|ned_int_fl
> 1|88.40672|84.94218|88|84|88.74082|85.08109|88|84
> 2|109.1437|98.23732|109|98|108.8838|98.40421|108|98
> 3|121.3047|117.567|121|117|121.5324|117.8318|121|117
> 4|142.1468|131.73|142|131|142.0981|131.7365|141|131
> 5|121.9686|122.3212|121|122|122.9578|123.2583|122|122
> 6|80.502|82.1487|80|82|81.29526|82.14999|80|81
>
> So, integer remains integer...
>
> Moritz
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Moritz Lennert]

On 09/05/17 15:13, Moritz Lennert wrote:

On 09/05/17 15:03, Moritz Lennert wrote:

On 09/05/17 14:37, Veronica Andreo wrote:

Hello Pierre,

Thanks for this new add-on! Comes on time for me :)

I'm testing it and I have observed something odd.
I'm querying integer maps but v.what.rast.multi gives me float values. I
run v.what.rast and I get the proper integer values. Does it have
anything to do with what Paulo just pointed out?



The module just loops over a series of v.what.rast calls, so results
should not be different. If any, Paulo's point reinforces this as the
'-i' flag (i.e.interpolate nearest points) is never used...


Sorry, I take that back: the -i flag is always set as what is passed on
to v.what.rast is 'flags' and without the '-i' flag set still is
non-null (it contains "{'i': False}") and so

'if (interp_flag->answer)'

in v.what.rast/main.c returns true.

So, yes the issue is linked to Paulo's remark.


Fixed in r71072.

But

v.what.rast.multi map=test raster=elev_srtm_30m,elev_ned_30m,srtm,ned 
columns=srtm_float_nofl,ned_float_nofl,srtm_int_nofl,ned_int_nofl


v.what.rast.multi -i map=test raster=elev_srtm_30m,elev_ned_30m,srtm,ned 
columns=srtm_float_fl,ned_float_fl,srtm_int_fl,ned_int_fl


cat|srtm_float_nofl|ned_float_nofl|srtm_int_nofl|ned_int_nofl|srtm_float_fl|ned_float_fl|srtm_int_fl|ned_int_fl
1|88.40672|84.94218|88|84|88.74082|85.08109|88|84
2|109.1437|98.23732|109|98|108.8838|98.40421|108|98
3|121.3047|117.567|121|117|121.5324|117.8318|121|117
4|142.1468|131.73|142|131|142.0981|131.7365|141|131
5|121.9686|122.3212|121|122|122.9578|123.2583|122|122
6|80.502|82.1487|80|82|81.29526|82.14999|80|81

So, integer remains integer...

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Moritz Lennert]

On 09/05/17 15:03, Moritz Lennert wrote:

On 09/05/17 14:37, Veronica Andreo wrote:

Hello Pierre,

Thanks for this new add-on! Comes on time for me :)

I'm testing it and I have observed something odd.
I'm querying integer maps but v.what.rast.multi gives me float values. I
run v.what.rast and I get the proper integer values. Does it have
anything to do with what Paulo just pointed out?



The module just loops over a series of v.what.rast calls, so results
should not be different. If any, Paulo's point reinforces this as the
'-i' flag (i.e.interpolate nearest points) is never used...


Sorry, I take that back: the -i flag is always set as what is passed on 
to v.what.rast is 'flags' and without the '-i' flag set still is 
non-null (it contains "{'i': False}") and so


'if (interp_flag->answer)'

in v.what.rast/main.c returns true.

So, yes the issue is linked to Paulo's remark.

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.ortho.photo/lib/ref_points.c and making a REF_POINTS file

[Yann]

Thanks Markus,

now I can see the missing link.

Ciao,

Yann


On 09/05/2017 08:45, Markus Metz wrote:

Hi Yann,

On Mon, May 8, 2017 at 10:12 PM, Yann  wrote:

Hi,

Looking for some lore from i.ortho.photo days in GRASS 6 and before...

Within i.image.2target, i.ortho.transform requires a REF_POINTS (image E,

image N, photo X, photo Y) file as part of its RMS error computation,
before using a CONTROL_POINTS (photo X, photo Y, photo Z, control X,
control Y, control Z) file made by i.image.2target interactive GCP creation
module.

the i.photo.2image module, to my understanding is from (photo X, photo Y)

to (image X, image Y), i.e. we keep in the non-map units, we only find the
proper coordinates of the camera within the camera absolute dimensions
(i.e. mm or other). So I do not believe it is related to generating a
REF_POINTS file.

the i.photo.2image module does generate a REF_POINTS file. This is needed
to translate from sensor (mm) to image (xy, pixels) and back. The sensor is
e.g. the CCD in a DSLR, e.g. for Canon EOS-1Ds the sensor would be 35.8 mm
× 23.8 mm.

HTH,

Markus M



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Moritz Lennert]

On 09/05/17 14:37, Veronica Andreo wrote:

Hello Pierre,

Thanks for this new add-on! Comes on time for me :)

I'm testing it and I have observed something odd.
I'm querying integer maps but v.what.rast.multi gives me float values. I
run v.what.rast and I get the proper integer values. Does it have
anything to do with what Paulo just pointed out?



The module just loops over a series of v.what.rast calls, so results 
should not be different. If any, Paulo's point reinforces this as the 
'-i' flag (i.e.interpolate nearest points) is never used...


And I cannot confirm:

g.region rast=elev_ned_30m
v.random test npoints=500
r.mapcalc "srtm = int(elev_srtm_30m)"
r.mapcalc "ned = int(elev_ned_30m)"
v.what.rast.multi map=test raster=elev_srtm_30m,elev_ned_30m,srtm,ned 
columns=srtm_float,ned_float,srtm_int,ned_int

v.db.select test col=srtm_float,ned_float,srtm_int,ned_int
[...]
105.1695|103.4447|104|102
124.6583|122.6958|124|122
104.6636|93.28199|104|93
81.77528|79.49014|81|78
90.53698|86.29738|89|85
80.44241|76.85014|79|76
127.8045|125.4002|127|124
106.0921|104.8796|105|104
151.5683|148.3245|150|148
121.2332|116.3521|120|116
123.2887|115.1104|123|114

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Veronica Andreo]

Hello Pierre,

Thanks for this new add-on! Comes on time for me :)

I'm testing it and I have observed something odd.
I'm querying integer maps but v.what.rast.multi gives me float values. I
run v.what.rast and I get the proper integer values. Does it have anything
to do with what Paulo just pointed out?

Thanks much!
Vero

2017-05-09 9:30 GMT+02:00 Paulo van Breugel :

> Hi Pierre,
>
> I have one question about the code. In lines 126-130 you create an object
> 'fl', which you subsequently do not seem to use. Perhaps in line 150 it
> should be flags=fl ?
>
> Something else, last year I wrote an addon r.what.rastlabel (
> https://github.com/ecodiv/GRASS-scripts/tree/master/v.what.rastlabel)
> which can be used to (multiple) raster values and labels. Optionally, it
> can also upload raster values only, like your addon (that part uses the
> same approach you use). I have not yet added it to the grass addon
> repository. I might do that later, at which point we can also see if it
> makes sense to merge the two.
>
> Cheers,
>
> Paulo
>
>
> On 5/9/17 8:36 AM, Luca Delucchi wrote:
>
>> On 8 May 2017 at 07:16, Pierre Roudier  wrote:
>>
>>> Hi all,
>>>
>>> Hi,
>>
>> FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi
>>> [0].
>>>
>>> It is a super simple Python wrapper around v.what.rast, and allows to
>>> query
>>> a suite of rasters in one go:
>>>
>>> thanks, it is useful
>> to improve a little bit, you add multiprocessing to the module, for
>> example a process for each raster
>>
> Interesting, could help to speed up with large point data layers.
>
>>
>> Cheers,
>>>
>>> Pierre
>>>
>>>
>>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.what.rast.multi

[Paulo van Breugel]

Hi Pierre,

I have one question about the code. In lines 126-130 you create an 
object 'fl', which you subsequently do not seem to use. Perhaps in line 
150 it should be flags=fl ?


Something else, last year I wrote an addon r.what.rastlabel 
(https://github.com/ecodiv/GRASS-scripts/tree/master/v.what.rastlabel) 
which can be used to (multiple) raster values and labels. Optionally, it 
can also upload raster values only, like your addon (that part uses the 
same approach you use). I have not yet added it to the grass addon 
repository. I might do that later, at which point we can also see if it 
makes sense to merge the two.


Cheers,

Paulo


On 5/9/17 8:36 AM, Luca Delucchi wrote:

On 8 May 2017 at 07:16, Pierre Roudier  wrote:

Hi all,


Hi,


FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi [0].

It is a super simple Python wrapper around v.what.rast, and allows to query
a suite of rasters in one go:


thanks, it is useful
to improve a little bit, you add multiprocessing to the module, for
example a process for each raster

Interesting, could help to speed up with large point data layers.



Cheers,

Pierre





___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3301: r.seasons: add option to use an input map with per-cell thresholds

[GRASS GIS]

#3301: r.seasons: add option to use an input map with per-cell thresholds
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Addons   |Version:  7.2.0
Resolution:   |   Keywords:  r.seasons
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3301 veroandreo]:
 > The possibility to use an input map with per-cell thresholds in
 r.seasons would be very useful (not necesarily to replace the current
 threshold parameter, but as a different parameter). This would allow  to
 pass a map of thresholds representing the median of the input time series
 in each pixel, for example.

 A new option `tmap` to use a raster map with per-cell threshold values has
 been added in r71070. The `threshold` option has been renamed to `tval`.
 Either `tval` or `tmap` must be provided.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev