Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

2019-04-23 Thread Markus Metz 
On Mon, Apr 22, 2019 at 4:45 AM Facundo Ferrín 
wrote:
>
> Hello!
>
> I don't know if I'm expressing myself well. The use of GRASS is
command-line, in the sense:
>
> rass run --mapset=/some/directory/grassdata/ncspm/practice1 r.lake
elevation=some/file.tiff
>
>
> What I propose is the use of a package to import from any Python script.
For example, read a TIFF with GDAL or GeoPandas, perform some operations
like removing some data and finally simplify the polygon.

GRASS is essentially a toolset consisting of several hundred modules which
are called on the command line or in scripts. If you want to use this
functionality, you need to call GRASS modules as done in e.g.
https://trac.osgeo.org/grass/browser/grass/trunk/scripts
>
> GRASS is something like GDAL's option to create polygons from images:
>
> https://gdal.org/gdal_polygonize.html

The GRASS equivalent is 'r.to.vect type=area'
>
> My idea, or my need, is to use GRASS functions programmatically, as in
this case.
>
>
https://pcjericks.github.io/py-gdalogr-cookbook/raster_layers.html#polygonize-a-raster-band

Convert an OGR File to a Raster
more generic: convert a vector to a raster
The GRASS equivalent is 'v.to.rast'

Clip a GeoTiff with Shapefile
more generic: clip a raster to vector polygons
In GRASS: convert to vector polygons to raster with 'v.to.rast', then
create a MASK with 'r.mask'

Calculate zonal statistics
more precisely here: get raster statistics for each vector polygon
The GRASS equivalent is 'v.rast.stats'

Raster to vector line
In GRASS: use 'r.reclass' or 'r.mapcalc' to select pixel values that need
to be converted to vector lines, then use r.to.vect type=line. BTW, the
green lines in the example are wrong because they don#t go through the
pixel centers.

Create raster from array
The GRASS equivalent is 'r.in.ascii'

Create least cost path
The GRASS equivalent is 'r.cost' + 'r.path'

Replace No Data Value of Raster with new value
The GRASS equivalent is 'r.mapcalc' using "if(isnull(rastermap),
, rastermap)"

>
> Is that among your ideas for the future? If that's the case and you're
interested, let me know. If so, you could make some prototype use to start
migrating the functionalities.

All this can be easily implemented as a GRASS GIS addon in a Python script
with much less code than in your example. Please have a look at
https://trac.osgeo.org/grass/browser/grass/trunk/scripts
to get started.
Alternatively, a QGIS plugin using GRASS GIS functionality would be an
option (QGIS has a GRASS GIS interface that can be used for inspiration).

my2c,
Markus M

>
> Cheers!
>
>
> On 10/04/2019 16:47, Vaclav Petras wrote:
>
> Hello Facundo,
>
> Using the GRASS GIS algorithms in various settings is certainly something
we are aiming for. However, as you probably understood from the
conversation here, it is not clear what exactly you are trying to achieve
considering the already available ways (APIs if you will). Also, to
evaluate your proposal, we need to test your skills for this particular
project. Therefore, I suggest you 1) implement a prototype of what you have
in mind, 2) compare it with the existing approaches (see e.g. email from
Markus M.), and 3) identify what is missing in the existing approaches and
what would you need to add in order to make you prototype work.
>
> Alternatively, or ideally in addition to the above, you can implement
couple of the test and training tasks from the proposal already linked by
Luca:
>
>
https://trac.osgeo.org/grass/wiki/GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS
>
> Best,
> Vaclav
>
> On Thu, Mar 28, 2019 at 4:13 AM Markus Metz 
wrote:
>>
>>
>>
>> On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss 
wrote:
>> >
>> > Hello Facundo,
>> > the easiest way would be moving functions of v.generalize into a
>> > library (e.g. grass_generalize) and thus make available for calling
>> > via ctypes.
>> > In the past I have had a good success manipulating GRASS vectors via
>> > ctypes. It takes more skill than a plain Python implementation but it
>> > is easier than a full blown C code and faster than pure Python one.
>> >
>> > Māris.
>> >
>> > ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
>> > () rakstīja:
>> > >
>> > > Hi Luca!
>> > >
>> > > Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:
>> > >
>> > >
https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
>> > >
>> > > However, polygon simplification does not work very well because it
does not take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.
>>
>> In this particular case, the core of the corresponding python script
would be three lines (import, simplify, export):
>>
>> -->
>> import grass.script as grass
>>
>>

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

2019-04-10 Thread Vaclav Petras 
Hello Facundo,

Using the GRASS GIS algorithms in various settings is certainly something
we are aiming for. However, as you probably understood from the
conversation here, it is not clear what exactly you are trying to achieve
considering the already available ways (APIs if you will). Also, to
evaluate your proposal, we need to test your skills for this particular
project. Therefore, I suggest you 1) implement a prototype of what you have
in mind, 2) compare it with the existing approaches (see e.g. email from
Markus M.), and 3) identify what is missing in the existing approaches and
what would you need to add in order to make you prototype work.

Alternatively, or ideally in addition to the above, you can implement
couple of the test and training tasks from the proposal already linked by
Luca:

https://trac.osgeo.org/grass/wiki/GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS

Best,
Vaclav

On Thu, Mar 28, 2019 at 4:13 AM Markus Metz 
wrote:

>
>
> On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss  wrote:
> >
> > Hello Facundo,
> > the easiest way would be moving functions of v.generalize into a
> > library (e.g. grass_generalize) and thus make available for calling
> > via ctypes.
> > In the past I have had a good success manipulating GRASS vectors via
> > ctypes. It takes more skill than a plain Python implementation but it
> > is easier than a full blown C code and faster than pure Python one.
> >
> > Māris.
> >
> > ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
> > () rakstīja:
> > >
> > > Hi Luca!
> > >
> > > Thanks for replying! In my job, there were things we had to do
> programmatically. For example, to manipulate geometries that reach the
> backend from a GeoJSON we use tools like these:
> > >
> > >
> https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
> > >
> > > However, polygon simplification does not work very well because it
> does not take topology into account. My idea was to port part of the GRASS
> algorithms to be able to use them without needing the graphical interface
> or command line, but only importing a library in a Python script.
>
> In this particular case, the core of the corresponding python script would
> be three lines (import, simplify, export):
>
> -->
> import grass.script as grass
>
> grass.run_command('v.in.ogr', ...)
> grass.run_command('v.generalize', ...)
> grass.run_command('v.out.ogr', ...)
> <--
>
> The import step with v.in.ogr is needed because the vector to be
> simplified must be a native GRASS vector with topology.
>
> How does your proposal differ from the QGIS-GRASS interface?
>
> Markus M
> > >
> > > Is it something that you have in mind to do or that might be useful to
> you?
> > >
> > >
> > > El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
> lucadel...@gmail.com) escribió:
> > >>
> > >> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin <
> facundo.fer...@gmail.com> wrote:
> > >> >
> > >> > Hi there!
> > >>
> > >> Hi Facundo,
> > >> >
> > >> >
> > >> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
> master in Computer Vision in Barcelona, and finally I found my opportunity
> to contribute to OSGeo by applying two things that I really like: Python
> and Backend development . I do not know exactly what I should write in this
> first email, so I'll start by listing the projects I'm interested in.
> > >> >
> > >> > I'm working in a company that is developing a platform for
> precision agriculture called Auravant (https://www.auravant.com/). I work
> as a backend developer and data analyst and I use daily almost every tool
> that you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a
> tool for polygon simplification called topoJSON (
> https://github.com/fferrin/topojson).
> > >> >
> > >> > ---
> > >> > MY MAIN IDEA is to start porting GRASS tools into a python package
> that can be used in other projects (beyond the client to use by command
> line). I don't know if it's something you have in mind but for offline and
> automated analysis it would be very useful. I particularly had problems
> when I tried to simplify geometries since the geometry of polygons was not
> taken into account.
> > >> > ---
> > >>
> > >> Your idea is not clear to me, there are already two Python library to
> > >> work with GRASS. you can find some ideas in the proposal page
> > >> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> > >> Neweasy-to-useCLIandAPIforGRASSGIS) and
> > >> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS
> integration
> > >> in QGIS 3)
> > >>
> > >> > Hope to hear from you soon!
> > >> >
> > >>
> > >> --
> > >> ciao
> > >> Luca
> > >>
> > >> www.lucadelu.org
> > >
> > > ___
> > > 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
> >

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

2019-03-28 Thread Markus Metz 
On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss  wrote:
>
> Hello Facundo,
> the easiest way would be moving functions of v.generalize into a
> library (e.g. grass_generalize) and thus make available for calling
> via ctypes.
> In the past I have had a good success manipulating GRASS vectors via
> ctypes. It takes more skill than a plain Python implementation but it
> is easier than a full blown C code and faster than pure Python one.
>
> Māris.
>
> ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
> () rakstīja:
> >
> > Hi Luca!
> >
> > Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:
> >
> >
https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
> >
> > However, polygon simplification does not work very well because it does
not take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.

In this particular case, the core of the corresponding python script would
be three lines (import, simplify, export):

-->
import grass.script as grass

grass.run_command('v.in.ogr', ...)
grass.run_command('v.generalize', ...)
grass.run_command('v.out.ogr', ...)
<--

The import step with v.in.ogr is needed because the vector to be simplified
must be a native GRASS vector with topology.

How does your proposal differ from the QGIS-GRASS interface?

Markus M
> >
> > Is it something that you have in mind to do or that might be useful to
you?
> >
> >
> > El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
lucadel...@gmail.com) escribió:
> >>
> >> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin 
wrote:
> >> >
> >> > Hi there!
> >>
> >> Hi Facundo,
> >> >
> >> >
> >> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
master in Computer Vision in Barcelona, and finally I found my opportunity
to contribute to OSGeo by applying two things that I really like: Python
and Backend development . I do not know exactly what I should write in this
first email, so I'll start by listing the projects I'm interested in.
> >> >
> >> > I'm working in a company that is developing a platform for precision
agriculture called Auravant (https://www.auravant.com/). I work as a
backend developer and data analyst and I use daily almost every tool that
you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
for polygon simplification called topoJSON (
https://github.com/fferrin/topojson).
> >> >
> >> > ---
> >> > MY MAIN IDEA is to start porting GRASS tools into a python package
that can be used in other projects (beyond the client to use by command
line). I don't know if it's something you have in mind but for offline and
automated analysis it would be very useful. I particularly had problems
when I tried to simplify geometries since the geometry of polygons was not
taken into account.
> >> > ---
> >>
> >> Your idea is not clear to me, there are already two Python library to
> >> work with GRASS. you can find some ideas in the proposal page
> >> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> >> Neweasy-to-useCLIandAPIforGRASSGIS) and
> >> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
> >> in QGIS 3)
> >>
> >> > Hope to hear from you soon!
> >> >
> >>
> >> --
> >> ciao
> >> Luca
> >>
> >> www.lucadelu.org
> >
> > ___
> > 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 mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

2019-03-28 Thread Maris Nartiss 
Hello Facundo,
the easiest way would be moving functions of v.generalize into a
library (e.g. grass_generalize) and thus make available for calling
via ctypes.
In the past I have had a good success manipulating GRASS vectors via
ctypes. It takes more skill than a plain Python implementation but it
is easier than a full blown C code and faster than pure Python one.

Māris.

ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
() rakstīja:
>
> Hi Luca!
>
> Thanks for replying! In my job, there were things we had to do 
> programmatically. For example, to manipulate geometries that reach the 
> backend from a GeoJSON we use tools like these:
>
> https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
>
> However, polygon simplification does not work very well because it does not 
> take topology into account. My idea was to port part of the GRASS algorithms 
> to be able to use them without needing the graphical interface or command 
> line, but only importing a library in a Python script.
>
> Is it something that you have in mind to do or that might be useful to you?
>
>
> El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi 
> (lucadel...@gmail.com) escribió:
>>
>> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin  
>> wrote:
>> >
>> > Hi there!
>>
>> Hi Facundo,
>> >
>> >
>> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a master 
>> > in Computer Vision in Barcelona, and finally I found my opportunity to 
>> > contribute to OSGeo by applying two things that I really like: Python and 
>> > Backend development . I do not know exactly what I should write in this 
>> > first email, so I'll start by listing the projects I'm interested in.
>> >
>> > I'm working in a company that is developing a platform for precision 
>> > agriculture called Auravant (https://www.auravant.com/). I work as a 
>> > backend developer and data analyst and I use daily almost every tool that 
>> > you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool 
>> > for polygon simplification called topoJSON 
>> > (https://github.com/fferrin/topojson).
>> >
>> > ---
>> > MY MAIN IDEA is to start porting GRASS tools into a python package that 
>> > can be used in other projects (beyond the client to use by command line). 
>> > I don't know if it's something you have in mind but for offline and 
>> > automated analysis it would be very useful. I particularly had problems 
>> > when I tried to simplify geometries since the geometry of polygons was not 
>> > taken into account.
>> > ---
>>
>> Your idea is not clear to me, there are already two Python library to
>> work with GRASS. you can find some ideas in the proposal page
>> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
>> Neweasy-to-useCLIandAPIforGRASSGIS) and
>> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
>> in QGIS 3)
>>
>> > Hope to hear from you soon!
>> >
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>
> ___
> 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] GSoC Proposal: Python package for topology tools

2019-03-27 Thread Facundo Ferrin 
Hi Luca!

Thanks for replying! In my job, there were things we had to do
programmatically. For example, to manipulate geometries that reach the
backend from a GeoJSON we use tools like these:

https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt

However, polygon simplification does not work very well because it does not
take topology into account. My idea was to port part of the GRASS
algorithms to be able to use them without needing the graphical interface
or command line, but only importing a library in a Python script.

Is it something that you have in mind to do or that might be useful to you?


El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi (
lucadel...@gmail.com) escribió:

> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin 
> wrote:
> >
> > Hi there!
>
> Hi Facundo,
> >
> >
> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a
> master in Computer Vision in Barcelona, and finally I found my opportunity
> to contribute to OSGeo by applying two things that I really like: Python
> and Backend development . I do not know exactly what I should write in this
> first email, so I'll start by listing the projects I'm interested in.
> >
> > I'm working in a company that is developing a platform for precision
> agriculture called Auravant (https://www.auravant.com/). I work as a
> backend developer and data analyst and I use daily almost every tool that
> you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
> for polygon simplification called topoJSON (
> https://github.com/fferrin/topojson).
> >
> > ---
> > MY MAIN IDEA is to start porting GRASS tools into a python package that
> can be used in other projects (beyond the client to use by command line). I
> don't know if it's something you have in mind but for offline and automated
> analysis it would be very useful. I particularly had problems when I tried
> to simplify geometries since the geometry of polygons was not taken into
> account.
> > ---
>
> Your idea is not clear to me, there are already two Python library to
> work with GRASS. you can find some ideas in the proposal page
> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
> Neweasy-to-useCLIandAPIforGRASSGIS) and
> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
> in QGIS 3)
>
> > Hope to hear from you soon!
> >
>
> --
> 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] GSoC Proposal: Python package for topology tools

2019-03-27 Thread Luca Delucchi 
On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin  wrote:
>
> Hi there!

Hi Facundo,
>
>
> My name is Facundo Ferrin. I am a nuclear engineer who is taking a master in 
> Computer Vision in Barcelona, and finally I found my opportunity to 
> contribute to OSGeo by applying two things that I really like: Python and 
> Backend development . I do not know exactly what I should write in this first 
> email, so I'll start by listing the projects I'm interested in.
>
> I'm working in a company that is developing a platform for precision 
> agriculture called Auravant (https://www.auravant.com/). I work as a backend 
> developer and data analyst and I use daily almost every tool that you post in 
> the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool for polygon 
> simplification called topoJSON (https://github.com/fferrin/topojson).
>
> ---
> MY MAIN IDEA is to start porting GRASS tools into a python package that can 
> be used in other projects (beyond the client to use by command line). I don't 
> know if it's something you have in mind but for offline and automated 
> analysis it would be very useful. I particularly had problems when I tried to 
> simplify geometries since the geometry of polygons was not taken into account.
> ---

Your idea is not clear to me, there are already two Python library to
work with GRASS. you can find some ideas in the proposal page
https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
Neweasy-to-useCLIandAPIforGRASSGIS) and
https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
in QGIS 3)

> Hope to hear from you soon!
>

-- 
ciao
Luca

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

[GRASS-dev] GSoC Proposal: Python package for topology tools

2019-03-25 Thread Facundo Ferrin 
Hi there!

My name is Facundo Ferrin. I am a nuclear engineer who is taking a master
in Computer Vision in Barcelona, and finally I found my opportunity to
contribute to OSGeo by applying two things that I really like: Python and
Backend development . I do not know exactly what I should write in this
first email, so I'll start by listing the projects I'm interested in.

I'm working in a company that is developing a platform for precision
agriculture called Auravant (https://www.auravant.com/). I work as a
backend developer and data analyst and I use daily almost every tool that
you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool
for polygon simplification called topoJSON (
https://github.com/fferrin/topojson).

---
*MY MAIN IDEA* is to start porting GRASS tools into a python package that
can be used in other projects (beyond the client to use by command line). I
don't know if it's something you have in mind but for offline and automated
analysis it would be very useful. I particularly had problems when I tried
to simplify geometries since the geometry of polygons was not taken into
account.
---

If it's not a viable project at this point, there are two projects that
also caught my attention:
- Create new rules for the Topology Framework in gvSIG Desktop

- QGIS 3D Improvements


I think that maybe I can apply some of the things that I learned from
topoJSON for the first project, and things that I learned from the master
to the second project. Learn C++ is in my schedule (because for Computer
Vision is really important) so it will be really useful for me to program
in C++, and in case that the project is hard enough, I could make it in
Python (which has support for Qt) and it could be translated into C++ as a
GSoC 2020 project.

Hope to hear from you soon!
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev