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

Vaclav Petras wenzeslaus at gmail.com
Wed Apr 10 07:47:22 PDT 2019


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 <markus.metz.giswork at gmail.com>
wrote:

>
>
> On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss <maris.gis at gmail.com> 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
> > (<facundo.ferrin at gmail.com>) 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 (
> lucadeluge at gmail.com) escribió:
> > >>
> > >> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin <
> facundo.ferrin at 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 at lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/grass-dev
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190410/316e1d68/attachment.html>


More information about the grass-dev mailing list