Re: [GRASS-dev] new addon

[Francesco Geri]

Thank you very much.

Cloning my fork everything gone ok.

I created a new branch called "r.forcircular", add the new folder and 
then commit/push. Then I did the pull request at the website.


I hope I did everything right this time.

Thanks again.


Il 01/02/22 12:41, Ondřej Pešek ha scritto:
út 1. 2. 2022 v 12:40 odesílatel Francesco Geri > napsal:


/git clone g...@github.com:fra-lab/grass.git
/

///Clone in 'grass' in corso...//
//The authenticity of host 'github.com 
(140.82.121.3)' can't be established.//
//ECDSA key fingerprint is
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.//
//Are you sure you want to continue connecting
(yes/no/[fingerprint])? yes//
//Warning: Permanently added 'github.com
,140.82.121.3' (ECDSA) to the list of known
hosts.//
//g...@github.com : Permission denied
(publickey).//
//fatal: Impossibile leggere dal repository remoto.//
//Assicurati di disporre dei privilegi d'accesso corretti//
//e che il repository esista./

In english:

/fatal: Unable to read from remote repository.
Make sure you have the correct access privileges
and that the repository exists.
/


Did you fork the repository before trying to clone it? I cannot see 
your fork in the list of forks and also not on your profile when 
stalking it.


You can do it interactively at the website by going to [1] or [2] 
(depending on whether you want to fork GRASS itself, or the addons 
repository) and clicking on "Fork" in the upper right corner. If you 
didn't do that, then the repository fra-lab/grass does not exist and 
therefore couldn't be cloned.


[1] https://github.com/OSGeo/grass 
[2] https://github.com/OSGeo/grass-addons 

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

Re: [GRASS-dev] new addon

[Stefan Blumentrath]

Hi Francesco,

And welcome!
Just a little heads up: The right place to add a new module is the grass-addons 
repository (you seem to try to add it to the GRASS GIS core):
grass-addons/CONTRIBUTING.md at grass8 * OSGeo/grass-addons 
(github.com)<https://github.com/OSGeo/grass-addons/blob/grass8/CONTRIBUTING.md>

Please note that there are also some formal, "legal boxes" to tick:
"
The submission must be compliant with the GRASS submission rules as found in 
the GRASS source code and RFC2 (Legal aspects of submission):
https://trac.osgeo.org/grass/wiki/RFC
"
If I remember correctly, you have to confirm towards the Project Steering 
Committee (PSC) that RFC 2 is read and understood and that your contributions 
adhere to the requirements outlined there...

Others, please correct me if that only applies to write access to the repo...

Looking forward to seeing your addon in the repository!

Cheers,
Stefan


From: grass-dev  On Behalf Of Ondrej Pešek
Sent: tirsdag 1. februar 2022 12:41
To: Francesco Geri 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] new addon

út 1. 2. 2022 v 12:40 odesílatel Francesco Geri 
mailto:francescog...@tim.it>> napsal:
git clone 
g...@github.com:fra-lab/grass.git<mailto:g...@github.com:fra-lab/grass.git>

Clone in 'grass' in corso...
The authenticity of host 
'github.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2F=04%7C01%7CStefan.Blumentrath%40nina.no%7Cdd740190d04a4709b35f08d9e577c781%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637793126094887884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ZVIg7aRoZEiV0AEvhGL3HBylLrX6xUDniF3iRNLvvkU%3D=0>
 (140.82.121.3)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 
'github.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2F=04%7C01%7CStefan.Blumentrath%40nina.no%7Cdd740190d04a4709b35f08d9e577c781%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637793126094887884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ZVIg7aRoZEiV0AEvhGL3HBylLrX6xUDniF3iRNLvvkU%3D=0>,140.82.121.3'
 (ECDSA) to the list of known hosts.
g...@github.com<mailto:g...@github.com>: Permission denied (publickey).
fatal: Impossibile leggere dal repository remoto.
Assicurati di disporre dei privilegi d'accesso corretti
e che il repository esista.

In english:

fatal: Unable to read from remote repository.
Make sure you have the correct access privileges
and that the repository exists.

Did you fork the repository before trying to clone it? I cannot see your fork 
in the list of forks and also not on your profile when stalking it.

You can do it interactively at the website by going to [1] or [2] (depending on 
whether you want to fork GRASS itself, or the addons repository) and clicking 
on "Fork" in the upper right corner. If you didn't do that, then the repository 
fra-lab/grass does not exist and therefore couldn't be cloned.

[1] 
https://github.com/OSGeo/grass<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass=04%7C01%7CStefan.Blumentrath%40nina.no%7Cdd740190d04a4709b35f08d9e577c781%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637793126095044121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ojVHPMNpAXTxpze9Fx6jGdSAQx%2BsyqHhCAkPuWkHivc%3D=0>
[2] 
https://github.com/OSGeo/grass-addons<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass-addons=04%7C01%7CStefan.Blumentrath%40nina.no%7Cdd740190d04a4709b35f08d9e577c781%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637793126095044121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=tDDj3kGwVyeCLZFTBW2jdbB9WvU2%2BH2YyT7h2yKIFys%3D=0>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon

[Ondřej Pešek]

út 1. 2. 2022 v 12:40 odesílatel Francesco Geri 
napsal:

> *git clone g...@github.com:fra-lab/grass.git
> *
>
> *Clone in 'grass' in corso...*
> *The authenticity of host 'github.com  (140.82.121.3)'
> can't be established.*
> *ECDSA key fingerprint is
> SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.*
> *Are you sure you want to continue connecting (yes/no/[fingerprint])? yes*
> *Warning: Permanently added 'github.com ,140.82.121.3'
> (ECDSA) to the list of known hosts.*
> *g...@github.com : Permission denied (publickey).*
> *fatal: Impossibile leggere dal repository remoto.*
> *Assicurati di disporre dei privilegi d'accesso corretti*
> *e che il repository esista.*
>
> In english:
>
>
>
>
> *fatal: Unable to read from remote repository. Make sure you have the
> correct access privileges and that the repository exists.*
>

Did you fork the repository before trying to clone it? I cannot see your
fork in the list of forks and also not on your profile when stalking it.

You can do it interactively at the website by going to [1] or [2]
(depending on whether you want to fork GRASS itself, or the addons
repository) and clicking on "Fork" in the upper right corner. If you didn't
do that, then the repository fra-lab/grass does not exist and therefore
couldn't be cloned.

[1] https://github.com/OSGeo/grass
[2] https://github.com/OSGeo/grass-addons
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon

[Francesco Geri]

Thank you very much Markus

If the CONTRIBUTING.md file isn't clear in this regard, please let us
know which line(s) should be improved. A great occasion to make it
better!


in fact, I have difficulty in the very initial stages of set-up. When I 
try to follow the line to fork the repository:


/git clone g...@github.com:your_GH_account/grass.gi/t

and so

/git clone g...@github.com:fra-lab/grass.git/

I obtain this error message:

/git clone g...@github.com:fra-lab/grass.git//
//Clone in 'grass' in corso...//
//The authenticity of host 'github.com (140.82.121.3)' can't be 
established.//
//ECDSA key fingerprint is 
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.//

//Are you sure you want to continue connecting (yes/no/[fingerprint])? yes//
//Warning: Permanently added 'github.com,140.82.121.3' (ECDSA) to the 
list of known hosts.//

//g...@github.com: Permission denied (publickey).//
//fatal: Impossibile leggere dal repository remoto.//
//Assicurati di disporre dei privilegi d'accesso corretti//
//e che il repository esista./

In english:

/fatal: Unable to read from remote repository.
Make sure you have the correct access privileges
and that the repository exists.
/



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

Re: [GRASS-dev] new addon

[Markus Neteler]

Hi Francesco,

On Tue, Feb 1, 2022 at 9:53 AM Francesco Geri  wrote:
>
> Hello everybody.
> I am writing to the grass-dev list because I am having difficulty to
> upload a new add-on called r.forcircuar to the Grass addon repository.
> The add-on is called r.forcircular, it was developed by University of
> Florence inside a research project aiming to the circular bioeconomy and
> sustainability of the forest supply chain.

Great!

> I followed the procedure shown at this link
> https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md , but every
> time I try to push I get an error message related to incorrect access
> privileges. My github account is fra-lab.

The idea is that you open a pull request so that it can be easily
reviewed. Upon approval it will then be merged.

If the CONTRIBUTING.md file isn't clear in this regard, please let us
know which line(s) should be improved. A great occasion to make it
better!

> Thank you very much for helping.
> Francesco

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

[GRASS-dev] new addon

[Francesco Geri]

Hello everybody.
I am writing to the grass-dev list because I am having difficulty to 
upload a new add-on called r.forcircuar to the Grass addon repository. 
The add-on is called r.forcircular, it was developed by University of 
Florence inside a research project aiming to the circular bioeconomy and 
sustainability of the forest supply chain. I followed the procedure 
shown at this link 
https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md , but every 
time I try to push I get an error message related to incorrect access 
privileges. My github account is fra-lab.


Thank you very much for helping.
Francesco


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

[GRASS-dev] new addon

[Paulo van Breugel]

Hi devs,

I added a pull request (#569) to grass-addons for a new add-on
r.suitability.regions. It is a rather simple add-on that based on an input
suitability layer (scores 0-1) finds regions of contiguous cells with
suitability scores above a user-defined threshold and of a user-defined
minimum size. Creating the pull request was a good exercise in formatting,
but at least now all checks pass ;-). Anybody who cares to check if it is
OK and can be submitted/merged?

Cheers,

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

Re: [GRASS-dev] new addon on the way

[Vaclav Petras]

On Mon, Nov 16, 2020 at 8:09 AM Veronica Andreo 
wrote:

> Then, I'll be working on writing (a bit) better code. Is it recommended to
> create classes?
>

Hi Vero,

Classes can be sometimes useful for writing things like scripts and GRASS
modules, but usually in these cases, just writing functions instead of
having everything in one long function does what you need which is
understandable and maintainable code.

A class could be useful to carry some state through your code gluing most
related variables and functions together like this:

p = Process(some, vars, always, needed)
result1 = p.phase_one_of_processing(some, other, vars)
result2 = p.another_phase_of_processing(result1, and, even, more, vars)
...

However, that's nothing you can't do well with just functions or functions
and a class which has only data attributes, but no functions. Sometimes, it
is a matter of taste. Sometimes, you may see that the functions are somehow
not quite fitting to do what you need to do and that's where classes might
come in.

With your current code, I would just run Pylint on in with default settings
and try to make it as happy as possible. Pylint usually forces me to split
big chunks of code into smaller documented functions with more clear inputs
and outputs. You can also run Black on it and forget about details of
formatting. I didn't really look into the logic of your code, but I think
your code looks good and readable, so you don't have much to worry about
even when you start applying some strict tools such as Pylint.

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

Re: [GRASS-dev] new addon on the way

[Stefan Blumentrath]

Ciao Vero,

Nice! Looking forward to testing those modules.
Your draft for i.landsat.download looks already quite good.

Cheers
Stefan

From: grass-dev  On Behalf Of Veronica Andreo
Sent: mandag 16. november 2020 14:09
To: grass-dev 
Subject: [GRASS-dev] new addon on the way

Hi everybody,

I have very slowly started to develop a toolset to search, download and import 
Landsat data based on landsatxplore python library [0]. I went for 
landsatxplore library because among the other options, it was the most active 
in terms of development, i.e., commits in the repo. Currently, I'm working in 
my repo [1], but hopefully, once it's done and reviewed by you, it can be moved 
to addons.

The toolset attempts to be similar to i.modis and i.sentinel, but it is pretty 
raw right now. I have started with i.landsat.download and the basic 
functionality is there (details in the html). I recycled and adapted parts of 
i.sentinel.download to read the settings file and get the region extent. Next 
step is to draft i.landsat.import. Then, I'll be working on writing (a bit) 
better code. Is it recommended to create classes?

Since I'm not a programmer, this is quite a challenge for me, hence I 
appreciate your patience, help and suggestions, either by this means or in the 
repo itself.

Thanks much in advance!
Vero

[0] 
https://github.com/yannforget/landsatxplore<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fyannforget%2Flandsatxplore=04%7C01%7CStefan.Blumentrath%40nina.no%7Ce94daea4e1ea4b32e6c808d88a30d550%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637411289624312544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=g%2FKoj0kptfAJJAfePsnmqsIe8nwm08DiW47%2FKFLVKYM%3D=0>
[1] 
https://github.com/veroandreo/i.landsat<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fveroandreo%2Fi.landsat=04%7C01%7CStefan.Blumentrath%40nina.no%7Ce94daea4e1ea4b32e6c808d88a30d550%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637411289624312544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=vfVRhgDigBw0QB8B6XMZ%2BFAsnAOBjbUVJuyNbrdVNvo%3D=0>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new addon on the way

[Veronica Andreo]

Hi everybody,

I have very slowly started to develop a toolset to search, download and
import Landsat data based on landsatxplore python library [0]. I went for
landsatxplore library because among the other options, it was the most
active in terms of development, i.e., commits in the repo. Currently, I'm
working in my repo [1], but hopefully, once it's done and reviewed by you,
it can be moved to addons.

The toolset attempts to be similar to i.modis and i.sentinel, but it is
pretty raw right now. I have started with i.landsat.download and the basic
functionality is there (details in the html). I recycled and adapted parts
of i.sentinel.download to read the settings file and get the region extent.
Next step is to draft i.landsat.import. Then, I'll be working on writing (a
bit) better code. Is it recommended to create classes?

Since I'm not a programmer, this is quite a challenge for me, hence I
appreciate your patience, help and suggestions, either by this means or in
the repo itself.

Thanks much in advance!
Vero

[0] https://github.com/yannforget/landsatxplore
[1] https://github.com/veroandreo/i.landsat
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] New addon: v.what.strds.timestamp

[Stefan Blumentrath]

Dear all,

Just want to inform you that I recently committed a new addon named 
v.what.strds.timestamp, which is a relatively simple wrapper around v.what.rast:
https://grass.osgeo.org/grass74/manuals/addons/v.what.strds.timestamp.html

Purpose of the module is to match point data that have a timestamp column (e.g. 
from temperature loggers, wildlife camera traps or GPS/tracking data) with 
space time raster datasets (STRDS). Raster maps registered in the STRDS are 
sampled with the points whos timestamps are within the corresponding time 
window and values written into a column in the attribute table of the input 
vector map.
It is currently only tested with SQLite backend, that handles data different 
from PostgreSQL, so esp. tests with the latter backend are very welcome...

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

[GRASS-dev] New addon v.rast.bufferstats

[Stefan Blumentrath]

Dear all,

I just uploaded a new addon "v.rast.bufferstats" [1] that extracts different 
raster statistics in multiple buffers around vector geometries.
It is looping over input geometries and thus not very performant with lots of 
input geometries. But it can be convenient for e.g. characterizing the 
surrounding of study sites...

Testing and feedback is very welcome.

Kind regards,
Stefan

1: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.rast.bufferstats

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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Moritz Lennert]

On 14/08/18 10:13, Moritz Lennert wrote:

On 13/08/18 15:30, Markus Neteler wrote:

Hi Moritz,

On Mon, Aug 13, 2018 at 2:04 PM, Moritz Lennert
 wrote:

On 13/08/18 13:41, Markus Neteler wrote:

...

AFAIK, the only moment where i.cutlines potentially reads the whole image
would be in the edge detection part. That's why there is the tiling option
to avoid just that.


I suppose you refer to

tile_width=integer
 Width of tiles for tiled edge detection (pixels)
tile_height=integer
 Height of tiles for tiled edge detection (pixels)
?


So, unless I'm forgetting something, you should be able
to work on large images. If you have seen this crash the module, please file
a bug report.


A colleague working with a large dataset > 10e9 pixels) just reported 
that the module does not crash, but that it seems to take "forever" (he 
stopped the process after a day). I guess this is in the r.cost phase.


An option would be to tile (and parallelize) the entire process which 
would mean finding cutlines in the individual tiles, making sure that 
the start and endpoints of these cutlines match the start and endpoints 
on the neighboring tiles...


Any suggestions are welcome.

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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Moritz Lennert]

On 13/08/18 15:30, Markus Neteler wrote:

Hi Moritz,

On Mon, Aug 13, 2018 at 2:04 PM, Moritz Lennert
 wrote:

On 13/08/18 13:41, Markus Neteler wrote:

...

AFAIK, the only moment where i.cutlines potentially reads the whole image
would be in the edge detection part. That's why there is the tiling option
to avoid just that.


I suppose you refer to

tile_width=integer
Width of tiles for tiled edge detection (pixels)
tile_height=integer
Height of tiles for tiled edge detection (pixels)
?


So, unless I'm forgetting something, you should be able
to work on large images. If you have seen this crash the module, please file
a bug report.


OK, fine, we'll try and report.


Note that for versions < 7.5 (I'll have to check whether Pietro's fix was
backported to 7.4)


I'm not sure either.


Actually you backported it: 
https://trac.osgeo.org/grass/changeset/72541/grass/branches/releasebranch_7_4/lib/python/pygrass


So, yes, it should work with 7.4.1.

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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Markus Neteler]

Hi Moritz,

On Mon, Aug 13, 2018 at 2:04 PM, Moritz Lennert
 wrote:
> On 13/08/18 13:41, Markus Neteler wrote:
...
> AFAIK, the only moment where i.cutlines potentially reads the whole image
> would be in the edge detection part. That's why there is the tiling option
> to avoid just that.

I suppose you refer to

tile_width=integer
   Width of tiles for tiled edge detection (pixels)
tile_height=integer
   Height of tiles for tiled edge detection (pixels)
?

> So, unless I'm forgetting something, you should be able
> to work on large images. If you have seen this crash the module, please file
> a bug report.

OK, fine, we'll try and report.

> Note that for versions < 7.5 (I'll have to check whether Pietro's fix was
> backported to 7.4)

I'm not sure either.

> there is a parameter name conflict between i.zc and the
> GridModule class used for the tiling, so you'd have to use i.edge.

At time we use trunk.

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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Moritz Lennert]

Hi Markus,

On 13/08/18 13:41, Markus Neteler wrote:

Hi Moritz, all,

On Tue, Mar 13, 2018 at 4:06 PM, Moritz Lennert
 wrote:

Hi to all,

A new addon is available [1]: i.cutlines tiles the images into tiles with
irregular borders that avoid cutting through meaningful objects. This allows
tiling an image for parallel processing while avoiding border effects.

...

[1] https://grass.osgeo.org/grass74/manuals/addons/i.cutlines.html


we are currently trying to use this approach on a huge (?) area of 50
gigapixels of aerial images (i.e., the free openNRW 10cm orthophotos)
which we have to classify.

In future the areas we'll have to process may be even bigger. Right
now, as far as I understand, i.cutlines is reading the entire images.
This becomes increasingly difficult with bigger areas due to hardware
limitations.

Do you have a suggestion how to deal with that? Kind of chicken and
egg problem? :)


AFAIK, the only moment where i.cutlines potentially reads the whole 
image would be in the edge detection part. That's why there is the 
tiling option to avoid just that. So, unless I'm forgetting something, 
you should be able to work on large images. If you have seen this crash 
the module, please file a bug report.


Note that for versions < 7.5 (I'll have to check whether Pietro's fix 
was backported to 7.4) there is a parameter name conflict between i.zc 
and the GridModule class used for the tiling, so you'd have to use i.edge.


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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Markus Neteler]

Hi Moritz, all,

On Tue, Mar 13, 2018 at 4:06 PM, Moritz Lennert
 wrote:
> Hi to all,
>
> A new addon is available [1]: i.cutlines tiles the images into tiles with
> irregular borders that avoid cutting through meaningful objects. This allows
> tiling an image for parallel processing while avoiding border effects.
...
> [1] https://grass.osgeo.org/grass74/manuals/addons/i.cutlines.html

we are currently trying to use this approach on a huge (?) area of 50
gigapixels of aerial images (i.e., the free openNRW 10cm orthophotos)
which we have to classify.

In future the areas we'll have to process may be even bigger. Right
now, as far as I understand, i.cutlines is reading the entire images.
This becomes increasingly difficult with bigger areas due to hardware
limitations.

Do you have a suggestion how to deal with that? Kind of chicken and
egg problem? :)

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

Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Roberta Fagandini]

Thank you Martin!

2018-08-11 20:44 GMT+02:00 Martin Landa :

> Hi,
>
> so 11. 8. 2018 v 11:54 odesílatel Markus Neteler 
> napsal:
> > > I confirm that the addons uploaded after Sat Jul 21 20:45:20 UTC 2018
> can
> > > not be installed on Windows (using g.extension).
> >
> > As per other email from yesterday: the Windows server (operated by
> > Martin) has at time a disk full problem. He'll fix that later today.
>
> service is back. Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Martin Landa]

Hi,

so 11. 8. 2018 v 11:54 odesílatel Markus Neteler  napsal:
> > I confirm that the addons uploaded after Sat Jul 21 20:45:20 UTC 2018  can
> > not be installed on Windows (using g.extension).
>
> As per other email from yesterday: the Windows server (operated by
> Martin) has at time a disk full problem. He'll fix that later today.

service is back. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Markus Neteler]

On Thu, Aug 9, 2018 at 12:55 PM, Roberta Fagandini
 wrote:
> Hi all,
> I confirm that the addons uploaded after Sat Jul 21 20:45:20 UTC 2018  can
> not be installed on Windows (using g.extension).

As per other email from yesterday: the Windows server (operated by
Martin) has at time a disk full problem. He'll fix that later today.

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

Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Roberta Fagandini]

Hi all,
I confirm that the addons uploaded after Sat Jul 21 20:45:20 UTC 2018  can
not be installed on Windows (using g.extension).

Roberta


> From : Roberto Marzocchi 
> To : "Markus Neteler", "Martin Landa"<
> landa.mar...@gmail.com>
> Cc : "Helmut Kudrnovsky", "GRASS developers list"<
> grass-dev@lists.osgeo.org>, "Roberta Fagandini"
> Date : gio, 09 ago 2018 09:03:13 +0200
> Subject : Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)
>
>
> Perhaps we can change the subject of this mail?
> I think this problem may affect the overview and the windows installation
> of new addons (but I can write something incorrect)
>
> R
>
> Il giorno mer 8 ago 2018 alle ore 22:49 Markus Neteler 
> ha scritto:
>
> Hi
>
> Helmut Kudrnovsky  schrieb am Mi., 8. Aug. 2018, 10:12:
>
> >I read here [1] that the addons manual pages are updated daily but
> regarding
> i.sentinel.mask the link refers >to the old version of the manual while
> i.sentinel.preproc still doesn't appear.
>
> last update of this site: Sat Jul 21 20:45:20 UTC 2018
>
> @Martin and/or @Markus: could be the update cronjob re-started manually?
>
>
> AFAIK the overview page is generated on Martin's Windows server, so I
> cannot do much here...
>
> Markus
> ___
> 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 i.sentinel.preproc (GSoC 2018)

[Roberto Marzocchi]

Perhaps we can change the subject of this mail?
I think this problem may affect the overview and the windows installation
of new addons (but I can write something incorrect)

R

Il giorno mer 8 ago 2018 alle ore 22:49 Markus Neteler 
ha scritto:

> Hi
>
> Helmut Kudrnovsky  schrieb am Mi., 8. Aug. 2018, 10:12:
>
>> >I read here [1] that the addons manual pages are updated daily but
>> regarding
>> i.sentinel.mask the link refers >to the old version of the manual while
>> i.sentinel.preproc still doesn't appear.
>>
>> last update of this site: Sat Jul 21 20:45:20 UTC 2018
>>
>> @Martin and/or @Markus: could be the update cronjob re-started manually?
>>
>
> AFAIK the overview page is generated on Martin's Windows server, so I
> cannot do much here...
>
> Markus
> ___
> 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 i.sentinel.preproc (GSoC 2018)

[Markus Neteler]

Hi

Helmut Kudrnovsky  schrieb am Mi., 8. Aug. 2018, 10:12:

> >I read here [1] that the addons manual pages are updated daily but
> regarding
> i.sentinel.mask the link refers >to the old version of the manual while
> i.sentinel.preproc still doesn't appear.
>
> last update of this site: Sat Jul 21 20:45:20 UTC 2018
>
> @Martin and/or @Markus: could be the update cronjob re-started manually?
>

AFAIK the overview page is generated on Martin's Windows server, so I
cannot do much here...

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

Re: [GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Helmut Kudrnovsky]

>I read here [1] that the addons manual pages are updated daily but regarding
i.sentinel.mask the link refers >to the old version of the manual while
i.sentinel.preproc still doesn't appear. 

last update of this site: Sat Jul 21 20:45:20 UTC 2018

@Martin and/or @Markus: could be the update cronjob re-started manually?





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new addon i.sentinel.preproc (GSoC 2018)

[Roberta Fagandini]

Hi all,
I uploaded the new GRASS GIS addon i.sentinel.preproc yesterday [0].
The addon has been developed as part of my GSoC project.

I also made some changes to the code and the manual page of i.sentinel.mask.
I read here [1] that the addons manual pages are updated daily but
regarding i.sentinel.mask the link refers to the old version of the manual
while i.sentinel.preproc still doesn't appear.

All the files are correctly updated to the latest version in the SVN
repository.

I would like to have the links to insert them in the final report of my
GSoC project.

Thanks in advance.

Roberta

[0]
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.sentinel.preproc
[1] https://grass.osgeo.org/grass74/manuals/addons
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] New addon r.accumulate calculates weighted flow accumulation using a flow direction map

[Huidae Cho]

Hi All,

I just committed a new addon r.accumulate (
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.accumulate).
Unlike r.watershed, this module calculates weighted flow accumulation
directly from the flow direction map and does not require the original
elevation data. I wrote this module many years ago for GRASS 6, but I
almost forgot about it until I read this question:

https://gis.stackexchange.com/questions/280813/compute-flow-accumulation-only-from-flow-direction

Thanks.
Huidae
-- 
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Markus Neteler]

On Tue, Mar 13, 2018 at 4:06 PM, Moritz Lennert
 wrote:
> Hi to all,
>
> A new addon is available [1]: i.cutlines tiles the images into tiles with
> irregular borders that avoid cutting through meaningful objects. This allows
> tiling an image for parallel processing while avoiding border effects.
>
> Enjoy !

Cool!
It would also be interesting for post-orthophoto mosaiking.

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

[GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Moritz Lennert]

Hi to all,

A new addon is available [1]: i.cutlines tiles the images into tiles 
with  irregular borders that avoid cutting through meaningful objects. 
This allows tiling an image for parallel processing while avoiding 
border effects.


Enjoy !

Moritz


[1] https://grass.osgeo.org/grass74/manuals/addons/i.cutlines.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New addon: i.pysptools.unmix

[Stefan Blumentrath]

Hi Moritz,

We are about to compare results from the two addons...
Unfortunately, I missed some details, so the manual page is not online yet 
(issues should be fixed now).

The main additions, compared to i.spec.unmix are 
 - three alternative endmember detection algorithms
 - (at least) two additional algorithms for spectral unmixing (Unconstrained 
least squares and fully constrained least squares (with the latter, pixels 
values in the resulting maps sum up to 1).

I should probably also mention, that i.pysptools.unmix allows to write out 
detected end members in a format that i.spec.unmix understands. So the modules 
can be complementary...

Cheers,
Stefan


-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: torsdag 8. februar 2018 09.06
To: Stefan Blumentrath <stefan.blumentr...@nina.no>; grass-user grass-user 
(grass-u...@lists.osgeo.org) <grass-u...@lists.osgeo.org>; GRASS developers 
list (grass-dev@lists.osgeo.org) <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] New addon: i.pysptools.unmix

On 06/02/18 23:37, Stefan Blumentrath wrote:
> Dear all,
> 
> I just committed a new addon (i.pysptools.unmix) which is a wrapper 
> around the endmember extraction and spectral unmixing functionality in 
> the pysptools python library [1].
> 
> Feedback will be gladly received!

Great, thanks a lot ! How does it compare to i.spec.unmix ? I assume it adds 
more algorithms ?

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

Re: [GRASS-dev] New addon: i.pysptools.unmix

[Moritz Lennert]

On 06/02/18 23:37, Stefan Blumentrath wrote:

Dear all,

I just committed a new addon (i.pysptools.unmix) which is a wrapper 
around the endmember extraction and spectral unmixing functionality in 
the pysptools python library [1].


Feedback will be gladly received!


Great, thanks a lot ! How does it compare to i.spec.unmix ? I assume it 
adds more algorithms ?


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

[GRASS-dev] New addon: i.pysptools.unmix

[Stefan Blumentrath]

Dear all,

I just committed a new addon (i.pysptools.unmix) which is a wrapper around the 
endmember extraction and spectral unmixing functionality in the pysptools 
python library [1].
Feedback will be gladly received!

Cheers
Stefan

[1]: https://pypi.python.org/pypi/pysptools
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] New addon: v.net.curvedarcs

[Moritz Lennert]

There is a new addon in the repository: v.net.curvedarcs.

https://grass.osgeo.org/grass72/manuals/addons/v.net.curvedarcs.html

It is a frontend to v.net and v.segment that creates curved arcs between 
given start and end points, thus allowing to display flows (or 
relations) between points while avoiding overlaps of lines.


Enjoy !

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 10/05/17 23:49, Pierre Roudier wrote:

Thanks Luca, that would be a good idea indeed!

Any pointers to implement this? I'm unfamiliar with parallel processing
in Pygrass.


You can look at i.pansharpen for a simple example:

https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_2/scripts/i.pansharpen/i.pansharpen.py#L151

or for a bit more sophisticated handling using PyGRASS:

https://grass.osgeo.org/grass72/manuals/libpython/pygrass.modules.interface.html#pygrass.modules.interface.module.ParallelModuleQueue

Other examples exist (cf i.segment.uspo for example)

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

[Pierre Roudier]

Hi Paulo,

fl is used to store flags passed to the command.

There was a typo in my code, and Moritz was kind enough to commit a
corrected version of the add-on (thanks Moritz!),

Would be more than happy to merge both addons, they do look similar enough
to be merged.

Cheers,

P

On 9 May 2017 at 19:30, Paulo van Breugel  wrote:

> 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] new addon: v.what.rast.multi

[Pierre Roudier]

Thanks Luca, that would be a good idea indeed!

Any pointers to implement this? I'm unfamiliar with parallel processing in
Pygrass.

Cheers,

P

On 9 May 2017 at 18:36, 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
>
> >
> > Cheers,
> >
> > Pierre
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
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] 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] new addon: v.what.rast.multi

[Moritz Lennert]

On 09/05/17 07:26, pablo zader wrote:

Very Nice!!

I have one question: Because it is called v.what.rast.multi and not
r.what.rast.multi?


It is a frontend to v.what.rast which loads information from a raster 
map into the attribute table of a point vector map. As it is the vector 
map which is modified, it is considered a vector module.


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

[Luca Delucchi]

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

>
> Cheers,
>
> Pierre
>


-- 
ciao
Luca

www.lucadelu.org
___
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

[pablo zader]

Very Nice!!

I have one question: Because it is called v.what.rast.multi and not
r.what.rast.multi?

Best



2017-05-08 18:25 GMT-03:00 Pierre Roudier :

> Done -- thanks for the heads-up Moritz!
>
> On 8 May 2017 at 23:05, Moritz Lennert 
> wrote:
>
>> On 08/05/17 07:16, Pierre Roudier wrote:
>>
>>> Hi all,
>>>
>>> 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:
>>>
>>> v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
>>> columns=elevation,slope,aspect
>>>
>>
>> Very useful, thanks !
>>
>> Don't forget to add the addon to the Makefile in the
>> grass-addons/grass7/vector directory.
>>
>> Moritz
>>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
*Pablo J. Zader*
*Universidad Nacional de Córdoba*

*GIS and remote sensing developer--*
*Lic. en Cs. de la Computación*
*Mgtr. en Aplicaciones  Espaciales de Alerta y Respuesta Temprana a
Emergencias*
*--*
*pablo.za...@gmail.com *





*"Los Grandes Hombres hablan sobre ideas... Los Hombres Promedio hablan
sobre cosas... Los Hombres Pequeños hablan.. de otros Hombres.*
*del libro Matemática estas ahi? A. Paenza "*
___
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

[Pierre Roudier]

Done -- thanks for the heads-up Moritz!

On 8 May 2017 at 23:05, Moritz Lennert  wrote:

> On 08/05/17 07:16, Pierre Roudier wrote:
>
>> Hi all,
>>
>> 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:
>>
>> v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
>> columns=elevation,slope,aspect
>>
>
> Very useful, thanks !
>
> Don't forget to add the addon to the Makefile in the
> grass-addons/grass7/vector directory.
>
> 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 08/05/17 07:16, Pierre Roudier wrote:

Hi all,

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:

v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
columns=elevation,slope,aspect


Very useful, thanks !

Don't forget to add the addon to the Makefile in the 
grass-addons/grass7/vector directory.


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

[Pierre Roudier]

I guess I probably should have added the URL:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.what.rast.multi

Apologies!

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

> Hi all,
>
> 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:
>
> v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
> columns=elevation,slope,aspect
>
> Cheers,
>
> Pierre
>
> [0]: https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> vector/v.what.rast.multi
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Pierre Roudier]

Hi all,

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:

v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect
columns=elevation,slope,aspect

Cheers,

Pierre

[0]:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.what.rast.multi
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: i.variance

[Markus Neteler]

On Fri, May 5, 2017 at 10:37 AM, Moritz Lennert
 wrote:
> Le Thu, 4 May 2017 19:26:12 +0200, > Markus Neteler  a 
> écrit :
...
>> Would you mind to add a note on how to interprete the "peak values of
>> variance" in the examples?
>> Say, what to deduce from it in terms of the size of detectable
>> objects?
>
> Does r71023 correspond to what you are after ?

Perfetto!

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

Re: [GRASS-dev] new addon: i.variance

[Moritz Lennert]

Le Thu, 4 May 2017 19:26:12 +0200,
Markus Neteler  a écrit :

> Hi Moritz,
> 
> On Tue, Mar 21, 2017 at 1:49 PM, Moritz Lennert
>  wrote:
> > Hi all,
> >
> > FYI, I uploaded a simple new addon, i.variance [1], which
> > calculates local variance in an image for successively degraded
> > resolution in order to detect whether there are certain scales
> > corresponding to specific, well-represented objects in that image.
> > It is based on [2].  
> 
> 
> Very interesting!
> 
> Would you mind to add a note on how to interprete the "peak values of
> variance" in the examples?
> Say, what to deduce from it in terms of the size of detectable
> objects?

Does r71023 correspond to what you are after ?

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

Re: [GRASS-dev] new addon: i.variance

[Markus Neteler]

Hi Moritz,

On Tue, Mar 21, 2017 at 1:49 PM, Moritz Lennert
 wrote:
> Hi all,
>
> FYI, I uploaded a simple new addon, i.variance [1], which calculates local
> variance in an image for successively degraded resolution in order to detect
> whether there are certain scales corresponding to specific, well-represented
> objects in that image. It is based on [2].


Very interesting!

Would you mind to add a note on how to interprete the "peak values of
variance" in the examples?
Say, what to deduce from it in terms of the size of detectable objects?

thanks
Markus

> Enjoy !
>
> Moritz
>
> [1] https://grass.osgeo.org/grass72/manuals/addons/i.variance.html
> [2] Curtis E. Woodcock, Alan H. Strahler, The factor of scale in remote
> sensing, Remote Sensing of Environment, Volume 21, Issue 3, April 1987,
> Pages 311-332, ISSN 0034-4257,
> http://dx.doi.org/10.1016/0034-4257(87)90015-0.
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new addon: i.variance

[Moritz Lennert]

Hi all,

FYI, I uploaded a simple new addon, i.variance [1], which calculates 
local variance in an image for successively degraded resolution in order 
to detect whether there are certain scales corresponding to specific, 
well-represented objects in that image. It is based on [2].


Enjoy !

Moritz

[1] https://grass.osgeo.org/grass72/manuals/addons/i.variance.html
[2] Curtis E. Woodcock, Alan H. Strahler, The factor of scale in remote 
sensing, Remote Sensing of Environment, Volume 21, Issue 3, April 1987, 
Pages 311-332, ISSN 0034-4257, 
http://dx.doi.org/10.1016/0034-4257(87)90015-0.



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

Re: [GRASS-dev] new addon module: i.superpixels.slic - image segmentation using the SLIC segmentation method

[Moritz Lennert]

On 07/02/17 08:30, Moritz Lennert wrote:

On 07/02/17 05:09, Vaclav Petras wrote:

Congratulations to the authors of i.superpixels.slic to a great
achievement! I've noticed lot of promising commits.

I've a suggestion to rename the one of the option called `k`. I think we
were recently changing a lot of options in modules from a letter to a
more descriptive name (num, number, pixels, num_pixels, ...?).


+1


Done. I chose num_pixels.

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

Re: [GRASS-dev] new addon module: i.superpixels.slic - image segmentation using the SLIC segmentation method

[Moritz Lennert]

On 07/02/17 05:09, Vaclav Petras wrote:

Congratulations to the authors of i.superpixels.slic to a great
achievement! I've noticed lot of promising commits.

I've a suggestion to rename the one of the option called `k`. I think we
were recently changing a lot of options in modules from a letter to a
more descriptive name (num, number, pixels, num_pixels, ...?).


+1



I've also added an example, so please review or add.


Perfect, thanks a lot !


(I suppose
combination with i.segment can be included in another example.)


Yes.

Plus potentially an example with i.superpixels.slic + i.segment.stats + 
v.class.mlR.


I think it is also time to write a more extensive wiki page on OBIA in 
GRASS... :-)


Moritz


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

Re: [GRASS-dev] new addon module: i.superpixels.slic - image segmentation using the SLIC segmentation method

[Vaclav Petras]

Congratulations to the authors of i.superpixels.slic to a great
achievement! I've noticed lot of promising commits.

I've a suggestion to rename the one of the option called `k`. I think we
were recently changing a lot of options in modules from a letter to a more
descriptive name (num, number, pixels, num_pixels, ...?).

k=integer
Number of super pixels
Default: 200

I've also added an example, so please review or add. (I suppose combination
with i.segment can be included in another example.)

Vaclav


On Tue, Jan 31, 2017 at 1:19 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Dear all,
>
> Thanks to initial work by Rashad, extensively completed by Markus Metz,
> we now have a new addon module which allows to segment images into
> so-called superpixels, using the SLIC algorithm as proposed by Achanta
> et al [1].
>
> The module uses a spatially constrained kmeans algorithm to group
> neighboring pixels into larger ensemble, the "superpixels". These
> superpixels can be used as a specific form of segmentation by itself,
> or they can be used as seed input to i.segment's region-growing
> algorithm.
>
> Thank you very much to the two authors for the great work !
>
> Moritz
>
>
>
> [1] http://ivrl.epfl.ch/research/superpixels
> ___
> 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

[GRASS-dev] new addon module: i.superpixels.slic - image segmentation using the SLIC segmentation method

[Moritz Lennert]

Dear all,

Thanks to initial work by Rashad, extensively completed by Markus Metz,
we now have a new addon module which allows to segment images into
so-called superpixels, using the SLIC algorithm as proposed by Achanta
et al [1].

The module uses a spatially constrained kmeans algorithm to group
neighboring pixels into larger ensemble, the "superpixels". These
superpixels can be used as a specific form of segmentation by itself,
or they can be used as seed input to i.segment's region-growing
algorithm.

Thank you very much to the two authors for the great work !

Moritz



[1] http://ivrl.epfl.ch/research/superpixels
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.faultdirections

[Helmut Kudrnovsky]

Moritz Lennert wrote
>>
>> but I get an error when using
>>
>> -aUse absolute values in legend, instead of percentages
>>
>>   v.faultdirections -a map=test@user1 column=vazimuth
>> Traceback (most recent call last):
>>   File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
>> /v.faultdirections.py", line 100, in 
> 
>> sys.exit(main())
>>   File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
>> /v.faultdirections.py", line 87, in main
>> labelradii = [x for x in np.arange(0,
>> int(np.ceil(max(radii))), labelstep) if x > 0]
>> ZeroDivisionError: division by zero
>>
>>
> 
> This was due to the fact that in your example there are only very few 
> lines per direction. I believe I solved this issue in r69786.
> 
> Thanks for testing !

confirmed, it works now.




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/new-addon-v-faultdirections-tp5294302p5294779.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.faultdirections

[Moritz Lennert]

On 07/11/16 10:25, Helmut Kudrnovsky wrote:

Moritz Lennert wrote


maybe some issue with the matplotlib backend?

see

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.width.funct/r.width.funct.py#L46
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.hypso/r.hypso.py#L52

where I've added some lines that it works also on windows.


Thanks Helmut ! I've just committed the same. Could you try if that
makes it work ?


https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/

it compiles now also on windows.

a quick test with

v.report map=test@user1 option=length
cat|vazimuth|length
1|244.950779|9348.35400342
2|221.312441|9951.01054944
3|199.83213|9730.81864487
4|175.322582|9600.70580563
5|141.98849|3207.86482835
6|94.698681|2123.01170046
7|277.507347|3772.31624213
8|285.610989|2051.88943075
9|71.113913|1169.71795667
10|78.146996|2419.67219737
11|90|2231.6347053
12|164.298026|7512.31179866
13|213.13561|7509.69092987
14|241.484453|8406.23126945
15|247.890552|7014.05058479
16|251.482848|6388.22365365

v.faultdirections map=test@user1 column=vazimuth
C:\OSGEO4~1\apps\Python27\lib\site-
packages\matplotlib-1.3.1-py2.7-win-
amd64.egg\matplotlib\cbook.py:1711:
VisibleDeprecationWarning: using a non-integer number
instead of an integer will result in an error in the future
  result = np.zeros(new_shape, a.dtype)

some matplotlib warning, but a nice polar barplot is created.


I don't see these warnings, but then again, I have matplotlib 1.5.3...



polar barplot  polar barplot


but I get an error when using

-aUse absolute values in legend, instead of percentages

  v.faultdirections -a map=test@user1 column=vazimuth
Traceback (most recent call last):
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.faultdirections.py", line 100, in 
sys.exit(main())
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.faultdirections.py", line 87, in main
labelradii = [x for x in np.arange(0,
int(np.ceil(max(radii))), labelstep) if x > 0]
ZeroDivisionError: division by zero




This was due to the fact that in your example there are only very few 
lines per direction. I believe I solved this issue in r69786.


Thanks for testing !

Moritz

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

Re: [GRASS-dev] new addon: v.faultdirections

[Helmut Kudrnovsky]

Moritz Lennert wrote
>> 
>> maybe some issue with the matplotlib backend?
>> 
>> see
>> 
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.width.funct/r.width.funct.py#L46
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.hypso/r.hypso.py#L52
>> 
>> where I've added some lines that it works also on windows.
> 
> Thanks Helmut ! I've just committed the same. Could you try if that
> makes it work ?

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/

it compiles now also on windows.

a quick test with

v.report map=test@user1 option=length   
cat|vazimuth|length
1|244.950779|9348.35400342
2|221.312441|9951.01054944
3|199.83213|9730.81864487
4|175.322582|9600.70580563
5|141.98849|3207.86482835
6|94.698681|2123.01170046
7|277.507347|3772.31624213
8|285.610989|2051.88943075
9|71.113913|1169.71795667
10|78.146996|2419.67219737
11|90|2231.6347053
12|164.298026|7512.31179866
13|213.13561|7509.69092987
14|241.484453|8406.23126945
15|247.890552|7014.05058479
16|251.482848|6388.22365365

v.faultdirections map=test@user1 column=vazimuth
C:\OSGEO4~1\apps\Python27\lib\site-
packages\matplotlib-1.3.1-py2.7-win-
amd64.egg\matplotlib\cbook.py:1711:
VisibleDeprecationWarning: using a non-integer number
instead of an integer will result in an error in the future
  result = np.zeros(new_shape, a.dtype)

some matplotlib warning, but a nice polar barplot is created.

polar barplot  polar barplot
  

but I get an error when using 

-aUse absolute values in legend, instead of percentages

  v.faultdirections -a map=test@user1 column=vazimuth   
  
Traceback (most recent call last):
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.faultdirections.py", line 100, in 
sys.exit(main())
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.faultdirections.py", line 87, in main
labelradii = [x for x in np.arange(0,
int(np.ceil(max(radii))), labelstep) if x > 0]
ZeroDivisionError: division by zero




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/new-addon-v-faultdirections-tp5294302p5294559.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon: v.faultdirections

[Moritz Lennert]

Le Sat, 5 Nov 2016 14:37:22 -0700 (MST),
Helmut Kudrnovsky  a écrit :

> Hi Moritz,
> 
> 
> Moritz Lennert wrote
> > Dear all,
> > 
> > As a result of some work with a student, I've just committed a
> > small and very simple addon that takes azimuths of lines from the
> > attribute table and draws a polar bar frequency plot in order to be
> > able to visually determine the dominant direction(s).
> > 
> > As this is generally used for geological faults, I called it 
> > v.faultdirections.
> > 
> > It is really in a very simple and basic state, but I thought that
> > I'd better upload it before I forget it. Hope it might be useful to
> > some. If anyone wants to work on it, please feel free...  
> 
> just wanted to test it on windows, but see:
> 
> https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/v.faultdirections.log
> 
> [snip]
> Traceback (most recent call last):
>   File
> "C:/Users/landa/grass_packager/grass73/x86_64/addons/v.faultdirections/scripts/v.faultdirections.py",
> line 50, in 
> import matplotlib.pyplot as plt
>   File
> "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\pyplot.py",
> line 98, in 
> _backend_mod, new_figure_manager, draw_if_interactive, _show =
> pylab_setup()
>   File
> "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\__init__.py",
> line 28, in pylab_setup
> globals(),locals(),[backend_name],0)
>   File
> "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\backend_qt4agg.py",
> line 13, in 
> from backend_qt4 import QtCore, QtGui, FigureManagerQT,
> FigureCanvasQT,\ File
> "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\backend_qt4.py",
> line 25, in 
> from qt4_compat import QtCore, QtGui, _getSaveFileName,
> __version__ File
> "C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\qt4_compat.py",
> line 36, in 
> import sip
> ImportError: No module named sip
> [snip]
> 
> maybe some issue with the matplotlib backend?
> 
> see
> 
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.width.funct/r.width.funct.py#L46
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.hypso/r.hypso.py#L52
> 
> where I've added some lines that it works also on windows.

Thanks Helmut ! I've just committed the same. Could you try if that
makes it work ?

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

Re: [GRASS-dev] new addon: v.faultdirections

[Helmut Kudrnovsky]

Hi Moritz,


Moritz Lennert wrote
> Dear all,
> 
> As a result of some work with a student, I've just committed a small and 
> very simple addon that takes azimuths of lines from the attribute table 
> and draws a polar bar frequency plot in order to be able to visually 
> determine the dominant direction(s).
> 
> As this is generally used for geological faults, I called it 
> v.faultdirections.
> 
> It is really in a very simple and basic state, but I thought that I'd 
> better upload it before I forget it. Hope it might be useful to some. If 
> anyone wants to work on it, please feel free...

just wanted to test it on windows, but see:

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/logs/v.faultdirections.log

[snip]
Traceback (most recent call last):
  File
"C:/Users/landa/grass_packager/grass73/x86_64/addons/v.faultdirections/scripts/v.faultdirections.py",
line 50, in 
import matplotlib.pyplot as plt
  File
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\pyplot.py",
line 98, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show =
pylab_setup()
  File
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\__init__.py",
line 28, in pylab_setup
globals(),locals(),[backend_name],0)
  File
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\backend_qt4agg.py",
line 13, in 
from backend_qt4 import QtCore, QtGui, FigureManagerQT, FigureCanvasQT,\
  File
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\backend_qt4.py",
line 25, in 
from qt4_compat import QtCore, QtGui, _getSaveFileName, __version__
  File
"C:\OSGeo4W64\apps\Python27\lib\site-packages\matplotlib-1.3.1-py2.7-win-amd64.egg\matplotlib\backends\qt4_compat.py",
line 36, in 
import sip
ImportError: No module named sip
[snip]

maybe some issue with the matplotlib backend?

see

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.width.funct/r.width.funct.py#L46
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.hypso/r.hypso.py#L52

where I've added some lines that it works also on windows.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/new-addon-v-faultdirections-tp5294302p5294461.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] new addon: v.faultdirections

[Moritz Lennert]

Dear all,

As a result of some work with a student, I've just committed a small and 
very simple addon that takes azimuths of lines from the attribute table 
and draws a polar bar frequency plot in order to be able to visually 
determine the dominant direction(s).


As this is generally used for geological faults, I called it 
v.faultdirections.


It is really in a very simple and basic state, but I thought that I'd 
better upload it before I forget it. Hope it might be useful to some. If 
anyone wants to work on it, please feel free...


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

[GRASS-dev] New addon: v.in.pygbif from Code Sprint Bonn

[Blumentrath, Stefan]

Dear Code-sprinters (and others),

Thanks for the awesome event and the great time in Bonn!
It was really exciting and a lot of fun working together with all of you. The 
experience definitely - more than - compensated travel costs and conference fee!

With the kind support from Lucca and Vero, the v.in.pygbif addon I was working 
on in Bonn is now finally usable and committed to addons.
v.in.pygbif builds upon Helmuts v.in.gbif addon and adds the possibility to 
query and fetch species occurrence data directly from GBIF.
In fact, it is more or less a graphical frontend to the pygbif package 
(http://pygbif.readthedocs.io/en/latest/index.html), which thus is a dependency 
of v.in.pygbif.

The GBIF data which is provided in WGS84 is re-projected into the projection of 
the current location at import. Import of global occurrences is by default 
limited to current computational region. This limit can be skipped in latlon 
locations.
Here my question is: Should I allow for unlimited/restricted import also in 
other CRS with global application? If yes, could you point me to EPSG codes of 
CRS you like me to add?

v.in.pygbif offers most of the relevant filter options from pygbif. I did some 
more testing yesterday, but still not all options are fully tested (also 
because the content of the returns from GBIF API are hard to predict)...
Anyway, I just pushed v.in.pygbif to addons together with a basic 
documentation. So, I would be glad for any test and report of issues / 
enhancements.

Many thanks again to Lucca and Vero for extensive testing and help along the 
way.

Known toDo`s are:

-Code clean up (e.g. some lines are a bit long)

-Add a cleanup routing when the user cancels / kills the process

-Handle layers in input mask map

-Proper implement shell script output for matching of taxon names

I hope it is of use for some of you...

Kind regards,
Stefan

P.S.: I would wish that the GBIF API would also provide information about the 
coordinate precision, which should be available in GBIF. Unfortunately this 
information does not seem to be available through the GBIF API :(.


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

[GRASS-dev] New addon: i.segment.uspo for unsupervised segmentation parameter optimization

[Moritz Lennert]

Hi all,

I justed posted a new addon: i.segment.uspo for unsupervised 
segmentation parameter optimization. It runs i.segment (in some 
configurations via i.segment.hierarchical) on a given number of test 
regions to extract the "best" combination of threshold and minsize for 
the given image.


Enjoy, and don't hesitate to give feedback for improvement.

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

[GRASS-dev] New addon module: i.segment.stats

[Moritz Lennert]

Hello everyone,

I've added a new module to the addons repository: i.segment.stats [1] 
which calculates spectral and form statistics for raster segments, 
typically coming from i.segment or possibly r.clump.


It is meant as one part of the general toolchain for object-based image 
segmentation.


It is a simple fronted to v.to.db and r.univar and as such a more KISS 
complement to Pietro's highly sophisticated v.class.ml.


Thanks also to MarkusM for significantly accelerating v.to.db !

The biggest ToDo is to add more variables to characterise segments...

Moritz


[1] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment.stats

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

[GRASS-dev] New addon: v.centerline

[Moritz Lennert]

FYI

I just added a new module to the GRASS7 addons [1] which I called 
v.centerline. It is somewhat of an experimental module and I invite 
anyone with other ideas of how to solve this problem to add to the module.


Below a description of the module and the two implemented algorithms.

Enjoy !

Moritz

***

v.centerline creates a new map with a line representing an approximation 
of the central tendency of a series of input lines. This can for 
example, be the central line of a river represented by its two sides, or 
a line representing the general direction of a series of flight paths, 
etc.


Two algorithms are proposed in the module, both based on the idea of 
using a reference line, creating a series of reference points along this 
line and then finding the coordinates of corresponding points on all the 
input lines. The default algorithm uses closest distance to identify 
corresponding points, while the second algorithm draws perpendicular 
transversals at the reference points and uses the intersections of these 
transversals with the other lines as corresponding points.


[1] 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.centerline

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

[GRASS-dev] New addon in svn: v.db.calc

[Massimiliano Cannata]

I just added the new script for field calculation.
It basically applies a python expression allowing the usage of field 
names as variables and update the selected column values.


It is useful for advanced field updates with DBF files.

An example:
Add a new column named EXP and populate it with the values of column 
VAL elevated at 0.25:

 v.db.addcol map=myvector columns=EXP double
 v.db.calc input=myvector field=EXP exp=math.pow([VAL], 0.25)

if the field is text:
Add a new text column named TXT and populte it concatenating em Dr. 
/em and the text values of the column NAME where the TITLE is phd:

v.db.addcol map=owners columns=TXT varchar(25)
v.db.calc input=owners field=TXT exp='Dr. '+'[NAME]' where=TITLE=phd

It should virtually works with all the python libs, but I've just tested 
with math and common functions.

Please test and comment.

Maxi

--
-
Dr. Massimiliano Cannata
Environmental  Geomatic Engineer

Institute of Earth Sciences - SUPSI
Trevano, C.P. 72, CH-6952 Canobbio, SWITZERLAND

Tel:+41 (0)58 / 666 62 14  
Fax:+41 (0)58 / 666 62 09

E-mail: massimiliano.cann...@supsi.ch

Web: 
http://www.ist.supsi.ch

http://istgis.ist.supsi.ch:8001/geomatica/
---


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