GRASS add-on sharing and write access

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

GRASS add-on sharing and write access

Nagy Edmond
Dear GRASS-PSC,

Recently, I've been working with least-cost paths in GRASS, and to save up
time, I decided to automate the process by writing an add-on that generates
a vector output resembling a network from a set of input vector points. It
is mostly based on r.cost/r.walk and r.drain.

I would be happy to share it with the community, and include it into the
official repository. To build some trust, I considered uploading the py
script on GitHub for you to look at the code, but I wasn't sure if that
would be acceptable. I can still do it if there is no problem.

I have also read the RFC2 and accept the legal consequences. Unfortunately I
don't have a mentor, but I would appreciate if someone kindly suggested
someone. My "osgeo_id" is "eno91".

Thank you very much for your attention.

Best regards,
Nagy Edmond



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Markus Neteler
Dear Nagy,

On Thu, Dec 14, 2017 at 12:24 PM, Nagy Edmond <[hidden email]> wrote:

> Dear GRASS-PSC,
>
> Recently, I've been working with least-cost paths in GRASS, and to save up
> time, I decided to automate the process by writing an add-on that generates
> a vector output resembling a network from a set of input vector points. It
> is mostly based on r.cost/r.walk and r.drain.
>
> I would be happy to share it with the community, and include it into the
> official repository. To build some trust, I considered uploading the py
> script on GitHub for you to look at the code, but I wasn't sure if that
> would be acceptable. I can still do it if there is no problem.

Feel free to post the link to the repo here.

> I have also read the RFC2 and accept the legal consequences. Unfortunately I
> don't have a mentor, but I would appreciate if someone kindly suggested
> someone.

We'll collectively assist you :)

> My "osgeo_id" is "eno91".

Welcome!

I have now activated the access and added your record to
"grass-addons/contributors.csv" in r71939.

Here some hints: Please, prior to submission, check your code and
manual contributions against the rules defined in the document
Submitting (and its subsections):

https://trac.osgeo.org/grass/wiki/Submitting
--> Submitting rules

This ensures a smooth integration into the standard GRASS code base
and avoids portability problems.

The "What's next" we addressed here:
https://trac.osgeo.org/grass/wiki/HowToContribute#Thenwhat

Happy coding,
Markus

--
Markus Neteler
GRASS GIS PSC Chair
http://grass.osgeo.org
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Markus Metz-3
Dear Nagy,

On Thu, Dec 14, 2017 at 8:47 PM, Markus Neteler <[hidden email]> wrote:

>
> Dear Nagy,
>
> On Thu, Dec 14, 2017 at 12:24 PM, Nagy Edmond <[hidden email]> wrote:
> > Dear GRASS-PSC,
> >
> > Recently, I've been working with least-cost paths in GRASS, and to save up
> > time, I decided to automate the process by writing an add-on that generates
> > a vector output resembling a network from a set of input vector points. It
> > is mostly based on r.cost/r.walk and r.drain.
> >
> > I would be happy to share it with the community, and include it into the
> > official repository. To build some trust, I considered uploading the py
> > script on GitHub for you to look at the code, but I wasn't sure if that
> > would be acceptable. I can still do it if there is no problem.
>
> Feel free to post the link to the repo here.
>
> > I have also read the RFC2 and accept the legal consequences. Unfortunately I
> > don't have a mentor, but I would appreciate if someone kindly suggested
> > someone.
>
> We'll collectively assist you :)

I am quite interested in your contribution and would like to assist you.

Markus M

>

> > My "osgeo_id" is "eno91".
>
> Welcome!
>
> I have now activated the access and added your record to
> "grass-addons/contributors.csv" in r71939.
>
> Here some hints: Please, prior to submission, check your code and
> manual contributions against the rules defined in the document
> Submitting (and its subsections):
>
> https://trac.osgeo.org/grass/wiki/Submitting
> --> Submitting rules
>
> This ensures a smooth integration into the standard GRASS code base
> and avoids portability problems.
>
> The "What's next" we addressed here:
> https://trac.osgeo.org/grass/wiki/HowToContribute#Thenwhat
>
> Happy coding,
> Markus
>
> --
> Markus Neteler
> GRASS GIS PSC Chair
> http://grass.osgeo.org
> _______________________________________________
> grass-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-psc


_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Nagy Edmond
Dear All,

Thank you very much for your support.

The add-on is now on GitHub. https://github.com/NagyEdmond/v.lcp.network
Please feel free to evaluate it. Your feedback will be most welcome.

All the best,
Nagy Edmond



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Markus Metz-3


On Fri, Dec 15, 2017 at 12:03 PM, Nagy Edmond <[hidden email]> wrote:
>
> Dear All,
>
> Thank you very much for your support.
>
> The add-on is now on GitHub. https://github.com/NagyEdmond/v.lcp.network
> Please feel free to evaluate it. Your feedback will be most welcome.

Instead of the compiled files, we would need the original files including a Makefile. The html file should be a template (see source of other scripts/modules), the real html file is then generated by make. The contents of the directory v.lcp.network must be

v.lcp.network
├── Makefile
├── v.lcp.network.html
└── v.lcp.network.py

Best,

Markus M


>
> All the best,
> Nagy Edmond
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
> _______________________________________________
> grass-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-psc


_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Nagy Edmond
Markus, thank you very much for helping.

I have now included into the add-on directory the py, html and makefile
files. The last one is an example I found somewhere, but I am not sure how
to adapt it, or how to run it (or from where) to generate the final html.
Could you please tell me how it works, or point me to a working example?

Edmond



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Luca Delucchi
Hi Nagy, 

Il 15 dic 2017 5:42 PM, "Nagy Edmond" <[hidden email]> ha scritto:
Markus, thank you very much for helping.

I have now included into the add-on directory the py, html and makefile
files. The last one is an example I found somewhere, but I am not sure how

You can have a look to makefile for addons in the svn repository [1] 

to adapt it, or how to run it (or from where) to generate the final html.
Could you please tell me how it works, or point me to a working example?

To understand how it works you can read the docs in the wiki about addons compilation [0]
I hope this is helpful 


Edmond

Ciao 
Luca 


_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Anna Petrášová
In reply to this post by Nagy Edmond
Hi Nagy,

On Dec 15, 2017 5:03 AM, "Nagy Edmond" <[hidden email]> wrote:
Dear All,

Thank you very much for your support.

The add-on is now on GitHub. https://github.com/NagyEdmond/v.lcp.network
Please feel free to evaluate it. Your feedback will be most welcome.

If I understand the code correctly, it computes always one way between 2 points, right? With r.walk the path could be different in each direction, because of the walking coefficients - they are not symmetric for walking up and downhill. So that's something which should be probably addressed, either by computing paths in both directions, or documenting this limitation in the manual.

Best,
Anna

All the best,
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc


_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Nagy Edmond
Hi Anna,

Thank you for pointing that out. It always computes one way between two
points indeed, but there is something that I should bring to light.

While I was initially computing least-cost paths with r.drain using r.walk
outputs as inputs I noticed a possible problem. I ran two parallel tests
with the same two points. In the first one, A was the starting position,
while B the stop position. In the second one, B was the start point and A
the stop point. In r.walk, the results were anisotropic indeed, both the
walking cost and the movement direction raster outputs turned out different,
as it would have been expected. But the r.drain module sadly did not
generate different least-cost paths, despite using different inputs. I have
also checked this more than once, just to be sure of it.

At one point I have also come across an article (Gietl et al. 2008 - link
below) where the authors discuss and compare l.c.p. results obtained with
different GIS (including GRASS), and they had also experienced some problem
with the module (page 4), but I am not sure if it's the same I'm having. In
any case, if nothing can be done about it, then I will mention the
limitation in the documentation.

All the best,
Nagy Edmond

article -
http://proceedings.caaconference.org/paper/106_gietl_et_al_caa2007/



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Nagy Edmond
In reply to this post by Luca Delucchi
Hi Luca,

Thank you for the links, I will have a look at that.

All the best,
Edmond



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Anna Petrášová
In reply to this post by Nagy Edmond
Hi Nagy,

On Sat, Dec 16, 2017 at 2:06 PM, Nagy Edmond <[hidden email]> wrote:

> Hi Anna,
>
> Thank you for pointing that out. It always computes one way between two
> points indeed, but there is something that I should bring to light.
>
> While I was initially computing least-cost paths with r.drain using r.walk
> outputs as inputs I noticed a possible problem. I ran two parallel tests
> with the same two points. In the first one, A was the starting position,
> while B the stop position. In the second one, B was the start point and A
> the stop point. In r.walk, the results were anisotropic indeed, both the
> walking cost and the movement direction raster outputs turned out different,
> as it would have been expected. But the r.drain module sadly did not
> generate different least-cost paths, despite using different inputs. I have
> also checked this more than once, just to be sure of it.
>
> At one point I have also come across an article (Gietl et al. 2008 - link
> below) where the authors discuss and compare l.c.p. results obtained with
> different GIS (including GRASS), and they had also experienced some problem
> with the module (page 4), but I am not sure if it's the same I'm having. In
> any case, if nothing can be done about it, then I will mention the
> limitation in the documentation.
>

you are right that r.drain seem to create the same path from A to B
and back, there are some slight differences, but that can be just
numerical cause. I am not sure why is that, if my expectation that the
path for that DEM should be different is incorrect, or there is some
problem in the algorithm. I don't think what the paper refers to is
the same thing though.

Anna

> All the best,
> Nagy Edmond
>
> article -
> http://proceedings.caaconference.org/paper/106_gietl_et_al_caa2007/
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
> _______________________________________________
> grass-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-psc
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Markus Metz-3


On Sun, Dec 17, 2017 at 5:36 AM, Anna Petrášová <[hidden email]> wrote:

>
> Hi Nagy,
>
> On Sat, Dec 16, 2017 at 2:06 PM, Nagy Edmond <[hidden email]> wrote:
> > Hi Anna,
> >
> > Thank you for pointing that out. It always computes one way between two
> > points indeed, but there is something that I should bring to light.
> >
> > While I was initially computing least-cost paths with r.drain using r.walk
> > outputs as inputs I noticed a possible problem. I ran two parallel tests
> > with the same two points. In the first one, A was the starting position,
> > while B the stop position. In the second one, B was the start point and A
> > the stop point. In r.walk, the results were anisotropic indeed, both the
> > walking cost and the movement direction raster outputs turned out different,
> > as it would have been expected. But the r.drain module sadly did not
> > generate different least-cost paths, despite using different inputs. I have
> > also checked this more than once, just to be sure of it.
> >
> > At one point I have also come across an article (Gietl et al. 2008 - link
> > below) where the authors discuss and compare l.c.p. results obtained with
> > different GIS (including GRASS), and they had also experienced some problem
> > with the module (page 4), but I am not sure if it's the same I'm having. In
> > any case, if nothing can be done about it, then I will mention the
> > limitation in the documentation.
> >
>
> you are right that r.drain seem to create the same path from A to B
> and back, there are some slight differences, but that can be just
> numerical cause. I am not sure why is that, if my expectation that the
> path for that DEM should be different is incorrect, or there is some
> problem in the algorithm.

It depends on the slope factor. Here is an example, based on the example in the manual of r.walk (North Carolina sample dataset):

g.region region=swwake_30m -p

# create friction map based on land cover
r.recode input=landclass96 out=friction rules=- << EOF
1:3:0.1:0.1
4:5:10.:10.
6:6:1000.0:1000.0
7:7:0.3:0.3
EOF

r.walk -k elevation=elev_ned_30m friction=friction output=walkcost_ab outdir=walkdir_ab start_coordinates=635576,216485 stop_coordinates=640206,222795 slope_factor=-0.05 lambda=0.5
r.drain -d input=walkcost_ab direction=walkdir_ab output=path_ab drain=path_ab start_coordinates=640206,222795

r.walk -k elevation=elev_ned_30m friction=friction output=walkcost_ba outdir=walkdir_ba start_coordinates=640206,222795 stop_coordinates=635576,216485 slope_factor=-0.05 lambda=0.5
r.drain -d input=walkcost_ba direction=walkdir_ba output=path_ba drain=path_ba start_coordinates=635576,216485

Here, the paths from A to B and from B to A are different. Depending on the settings, the paths can be nearly identical. Small differences can arise because there can be several paths from A to B with equal cumulative costs.

> I don't think what the paper refers to is
> the same thing though.

In this paper, GRASS 6.1.0 was used, and back then r.drain did not have the option to use a direction map as input, therefore r.drain could not be used with the output of r.cost/r.walk.

Right now, r.drain is somewhat overloaded: it creates directions for a DEM same way r.fill.dir does it, or it uses supplied directions, then the module extracts least costly paths. I suggest to have a new module r.path that extracts extract least costly paths from input directions and start points and mark r.drain as deprecated.

Markus M

>

> Anna
>
> > All the best,
> > Nagy Edmond
> >
> > article -
> > http://proceedings.caaconference.org/paper/106_gietl_et_al_caa2007/
> >
> >
> >
> > --
> > Sent from: http://osgeo-org.1560.x6.nabble.com/GRASS-PSC-f4051248.html
> > _______________________________________________
> > grass-psc mailing list
> > [hidden email]
> > https://lists.osgeo.org/mailman/listinfo/grass-psc
> _______________________________________________
> grass-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-psc


_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Markus Neteler
On Sun, Dec 17, 2017 at 9:14 PM, Markus Metz
<[hidden email]> wrote:
...
> Right now, r.drain is somewhat overloaded: it creates directions for a DEM
> same way r.fill.dir does it, or it uses supplied directions, then the module
> extracts least costly paths. I suggest to have a new module r.path that
> extracts extract least costly paths from input directions and start points
> and mark r.drain as deprecated.

Sounds interesting! At time it is a bit confusing.

markusN
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc
Reply | Threaded
Open this post in threaded view
|

Re: GRASS add-on sharing and write access

Moritz Lennert
[CC'ing grass-dev where such discussion should be happening]

On 17/12/17 22:37, Markus Neteler wrote:

> On Sun, Dec 17, 2017 at 9:14 PM, Markus Metz
> <[hidden email]> wrote:
> ...
>> Right now, r.drain is somewhat overloaded: it creates directions for a DEM
>> same way r.fill.dir does it, or it uses supplied directions, then the module
>> extracts least costly paths. I suggest to have a new module r.path that
>> extracts extract least costly paths from input directions and start points
>> and mark r.drain as deprecated.
>
> Sounds interesting! At time it is a bit confusing.

+1

Moritz
_______________________________________________
grass-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-psc