[GRASS-dev] Fwd: [Projects] Reminder - OSGeo Minneapolis Code Sprint Coming Up Fast

[Markus Neteler]

FYI

-- Forwarded message -
From: Lime, Steve D (MNIT) 
Date: Wed, Mar 27, 2019 at 5:47 PM
Subject: [Projects] Reminder - OSGeo Minneapolis Code Sprint Coming Up Fast
To: proje...@osgeo.org 


Hi all: In an effort to avoid spamming every OSGeo list I figured I’d reach
out to project leads and let you do as you see fit within your communities…
;-)



Anyway, just a quick note to remind folks that the annual OSGeo Community
Sprint in Minneapolis is only about 7 weeks out – May 14-17 and all
projects are most welcome. We have a great venue at the University of
Minnesota and the weather in Minnesota is finally looking up! Of course it
really helps with planning if have an idea of how many folks might attend.
So if you’re thinking about it – even if you’re not 100% - we’d love to
know about it. You can learn more and sign up at:



  https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2019



Of course events like this are impossible without the generous support of
sponsors:



*Gold Sponsors*

-  GeoCue (http://www.geocue.com/)

-  Safe Software (https://www.safe.com/)



*Silver Sponsors*

-  Hobu Inc (https://hobu.co/)

-  EOX (http://eox.at)

-  Tydac (http://www.tydac.ch/)

-  crunchy data (http://www.crunchydata.com/)



*Bronze Sponsors*

-  Coordinate Solutions (http://www.coordinatesolutions.com/)

-  SharedGeo (https://www.sharedgeo.org/)

-  Greenwood Mapping (https://greenwoodmap.com/)

-  Azavea (https://www.azavea.com/)

-  Bohannan Huston (https://www.bhinc.com/)

-  Extensis (https://www.extensis.com/)



Please contact me with any questions. Many thanks!



--Steve



Steve Lime

OSGeo Community Sprint 2019

Local Organizing Committee


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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 Now multirunner also works with Python 3 and tests for P2 and P3 are more
 or less even...

 However, a new issue pops up:

 {{{
 NameError: global name '_' is not defined
 }}}

 Also, in Py3 I had to deactivate the following tests as the cause
 multirunner to freeze...

 {{{
 
lib/python/pygrass/modules/interface/testsuite/test_pygrass_modules_interface_doctests.py
 lib/python/temporal/testsuite/test_temporal_doctests.py
 temporal/t.vect.algebra/testsuite/test_vector_algebra.py
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3798: Python 3: gunittest multirunner.py crashes

[GRASS GIS]

#3798: Python 3: gunittest multirunner.py crashes
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Tests|Version:  svn-trunk
Resolution:  fixed|   Keywords:  Python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by sbl):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"74327" 74327]:
 {{{
 #!CommitTicketReference repository="" revision="74327"
 fix multirunner.py with Py3; fix #3798; more Py3 fixes see #3771
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 In [changeset:"74327" 74327]:
 {{{
 #!CommitTicketReference repository="" revision="74327"
 fix multirunner.py with Py3; fix #3798; more Py3 fixes see #3771
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 Replying to [comment:47 cmbarton]:
 > Can you give me access to these files so I can test?

 Sent off-public (just to not waste space here) a sample from the Landsat 8
 scene I use(d).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3788: Bug for flag `-n` in r.lake.series

[GRASS GIS]

#3788: Bug for flag `-n` in r.lake.series
---+---
  Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  normal|  Milestone:
 Component:  Addons|Version:  unspecified
Resolution:  fixed |   Keywords:  r.lake.series
   CPU:  Unspecified   |   Platform:  Unspecified
---+---
Changes (by Nikos Alexandris):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed with revision 74324.

-- 
Ticket URL: 
GRASS GIS 

___
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

[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

[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] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 At time the "fatra" server no longer runs, it is frozen at date

 {{{
 2019-03-26 03:01:54 74304   nc_spm_full_v2alpha 93% 98%
 }}}

 @vaclav: could you please check? thanks

 http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

-- 
Ticket URL: 
GRASS GIS 

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