Re: [GRASS-dev] [GRASS GIS] #3801: r.watershed crashing on large rasters

[GRASS GIS]

#3801: r.watershed crashing on large rasters
---+-
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.6.1
 Component:  Default   |Version:  7.4.1
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  Linux
---+-

Comment (by mmetz):

 Replying to [ticket:3801 dnewcomb]:
 > Attempting to run r.watershed on a 13.7 billion pixel raster elevation
 layer
 >  r.watershed --overwrite elevation=cfsdem05 accumulation=cfs_accum
 drainage=cfs_drain
 > SECTION 1a (of 4): Initiating Memory.
 > WARNING: Subprocess failed with exit code 11
 > WARNING: category information for [cfs_accum] in [PERMANENT] missing or
 >  invalid
 > WARNING: category information for [cfs_drain] in [PERMANENT] missing or
 >  invalid
 >
 > I have tried this with Memory=10 MB

 The memory option has an effect only when using the -m flag. I don't think
 r.watershed in all-in-memory mode (no -m flag) is supporting such large
 input maps.
 >
 > Does r.watershed need more than 100GB of memory to run on a 14 billion
 pixel raster?
 >
 > The raster is linked via r.external, doe it need to be imported ?
 >
 > Looking backwards, the enhancement to run large raster was done for
 GRASS 7.0 , is this a regression, or was it not tested to larger than 9
 billion cells?

-- 
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] #3802: grass77: g.proj compilation fails with proj 5.2.0

[GRASS GIS]

#3802: grass77: g.proj compilation fails with proj 5.2.0
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Default  |Version:  svn-trunk
Resolution:  fixed|   Keywords:  g.proj
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by mmetz):

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


Comment:

 In [changeset:"74314" 74314]:
 {{{
 #!CommitTicketReference repository="" revision="74314"
 g.proj: use format with sprintf, fixes #3802
 }}}

-- 
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] #3074: v.in.ogr / v.overlay: ERROR due to non-SQL-compliant layer names

[GRASS GIS]

#3074: v.in.ogr / v.overlay: ERROR due to non-SQL-compliant layer names
--+
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  v.in.ogr,v.overlay
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mmetz):

 Should be fixed with trunk r74261.

-- 
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] #3790: Cleanup gettext usage for python code

[GRASS GIS]

#3790: Cleanup gettext usage for python code
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Disclaimer: The real goal of this refactoring was to get rid of
 {{{os.getenv("GISBASE")}}} calls at the module level. This is a
 prerequisite for #3772. The scripts and the GUI code didn't really need to
 be touched, but I did them too for uniformity.

 Replying to [comment:4 wenzeslaus]:
 > The things in lib/python are potentially (and actually) used as Python
 modules by other applications or scripts. Thus from
 https://pymotw.com/2/gettext/index.html#module-localization, it is
 actually the second option which applies:
 >
 > > //For a library, or individual module, modifying `__builtins__` is not
 a good idea because you don’t know what conflicts you might introduce with
 an application global value. You can import or re-bind the names of
 translation functions by hand at the top of your module.//

 I really like it when things are explicit. I dislike the idea of injecting
 things into builtins and I do found the convention of using {{{_()}}} as
 an alias for {{{gettext.gettext()}}} rather unfortunate. Consequently, I
 don't have any objections with getting rid of {{{gettext.install()}}}
 and/or even {{{_()}}}.

 Regardless, I am not sure that GRASS was actually following Doug Helman's
 advice. More specifically, almost all GRASS modules used to import the
 {{{grass}}} library before actually calling {{{gettext.install()}}} on
 their own ([https://github.com/GRASS-GIS/grass-
 ci/pull/9/commits/0983ca068d6f7363d2fede26f77b8aed76c87bcc source]). The
 {{{grass}}} library was already calling {{{gettext.install}}}
 ([https://github.com/GRASS-GIS/grass-
 ci/pull/9/commits/b589754aa497ac8ad067ed8258b12caaa0bf1e17#diff-
 15e2e35efef103adc7f77c0a3afe4a63 source]). {{{grass.temporal}}} was doing
 the same for no apparent reason though, since it was just re-registering
 the "grasslibs" domain ([https://github.com/GRASS-GIS/grass-
 ci/pull/9/commits/b589754aa497ac8ad067ed8258b12caaa0bf1e17#diff-
 e36b6b10b67c75c0d7c159b273854ef1 source]). Anyway, the end result is that
 most of the time, if not always, as soon as you imported the {{{grass}}}
 lib, the {{{builtins}}} were modified anyway.

 In other words, I don't think that the proposed patch really changes what
 the {{{grass}}} library was doing. The builtin injection continues to
 happen just like it used before.

 That being said, I am completely open to any improvements. I am also
 perfectly fine with following Mr. Helman's advice (i.e. by adding explicit
 imports in each and every {{{grass}}} lib module) if someone wants to
 contribute that. But IMHV the proposed implementation is cleaner than the
 previous one.

 > So far we were relatively successful in keeping the GUI separate
 (whether for performance or code organization reasons).

 I don't really see any coupling of the GUI code with the {{{grass}}}
 library. All the {{{grass}}} library does is registering the "grasswxpy"
 domain. It doesn't import anything.

 TBH, I did consider moving the {{{gettext.install("grasswxpy", ...)}}}
 code inside {{{./gui/wxpython}}}, but the way it is structured doesn't
 allow to do that cleanly and I didn't want to make changes there too. It
 is doable though.

 > Finally, is there any overhead in centralizing the tr string
 installation?

 I haven't measured it. Obviously there is some overhead. Previously when
 you were importing  {{{grass}}} for the first time in a process, you were
 registering 2 domains. "grasslibs" + "grassmods" when using the CLI and
 "grasslibs" + "grasswxpy" when using the GUI. Now 3 domains are being
 registered. So there is overhead.

 TBH I haven't read the whole {{{gettext}}} module line by line, but I
 think that the gist of {{{gettext.install()}}} is
 
[https://github.com/python/cpython/blob/ead15795986972690217e52087eb946b8a5bbcda/Lib/gettext.py#L512-L552
 these lines]. Line 552 calls the method that does the builtin injection
 (check lines 314-316) while line 551 calls the function that registers the
 domain in a "private" dictionary named {{{_translations}}}. AFAI can tell
 from just reading the code, the only overhead to really speak of is the
 parsing of the {{{*.mo}}} files which in GRASS are a few hundred KBs. On
 SSDs this overhead should be negligible while on mechanical drives the
 bottleneck is not going to be the code anyway. Re-registering a domain
 should incur any overhead since the results are cached.

 That being said, if you feel that it is necessary, it should be possible
 to avoid registering "grasswxpy" and "grassmods" inside grass lib. E.g. by
 adding a couple 

Re: [GRASS-dev] [GRASS GIS] #3802: grass77: g.proj compilation fails with proj 5.2.0

[GRASS GIS]

#3802: grass77: g.proj compilation fails with proj 5.2.0
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Default  |Version:  svn-trunk
Resolution:  fixed|   Keywords:  g.proj
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 Great, thanks for quick fix.

-- 
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
--+-
Changes (by pmav99):

 * Attachment "testsuite.patch" added.


-- 
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 pmav99):

 Thank you @wenzeslaus

 @everyone
 I used the attached patch to get the testsuite runner to use the new
 dataset.

-- 
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 neteler):

 I have updated the gunittest docs in r74316 to also mention Travis-CI and
 the new sample dataset.


 Replying to [comment:13 pmav99]:
 > I used the attached patch to get the testsuite runner to use the new
 dataset.

 Patch commited in r74316 (after shallow local testing), thanks.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release] 7.6.1

[Anna Petrášová]

Hi, here is a screenshot:

https://drive.google.com/file/d/1ydqPLLDs85XA3rjXCgt0-TkDgEHCtige/view?usp=sharing

I was wondering what is the status of addons for Windows? No addons for
7.6.1 yet, right? But also addons for 7.6.0 are not compiled, last date is
March 7th?

Thanks!

On Sun, Mar 24, 2019 at 2:33 PM Martin Landa  wrote:

> Hi,
>
> út 19. 3. 2019 v 21:44 odesílatel Martin Landa 
> napsal:
> > 2) write announcement (I can do later)
>
> draft prepared in CMS. Some nice screenshot wanted :-) 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Thank you to our sponsors !

[Moritz Lennert]

Hi everyone,

Just a big thank you to those that sponsor GRASS GIS development, even
with very small amounts. If everyone who uses GRASS GIS gives just 10
Euros / Dollars once a year, then this would already allow us to pay
travel for developers to code sprints which are generally very
productive coding moments, we can pay for some services to overhaul our
outdated website, etc, etc. All things necessary to make GRASS GIS even
better still.

You can find a list of sponsors at

https://grasswiki.osgeo.org/wiki/Sponsors

If you also want to contribute, you can do so very easily via our PayPal
Money Pool:

https://www.paypal.com/pools/c/86YKZiIEPV


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

Re: [GRASS-dev] [GRASS GIS] #3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are failing

[GRASS GIS]

#3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are
failing
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pmav99):

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


-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Import PostGIS vector layer into SQLite database

[Luí­s Moreira de Sousa]

Hi all,

I am working with vector layers (points) composed of more than 100 000 
geometries. These layers are originally in a PostGis database and I import them 
with v.in.ogr, using a formulation like:

v

.

in

.

ogr

\

input

=

"PG:host=127.0.0.1 dbname=gisdb user=user password=secret"

\

layer

=

schema

.

points

\

output

=

points

\

-

o

--overwrite

This command is successful, however, operations with the resulting points layer 
are remarkably slow. For instance, this layer must be later loaded in R and 
that operation alone is taking over 3 hours.

After some back-and-forth testing, I identified the problem: v.in.ogr is not 
saving its output in the internal GRASS SQLite database. Knowing this, I can 
create a copy of the original output, that is automatically inserted into the 
SQLite database, e.g.:

g.copy vector=points,points_mirror

Importing the points_mirror layer to R takes 3 minutes instead of 3 hours, for 
instance.

While mirroring vectors imported with v.in.ogr solves the issue, it is an 
inelegant solution that also takes up unnecessary space. I would prefer to 
instruct v.in.ogr somehow to force it to use the SQLite database. I could not 
find any reference in the manual, is it possible to do?

Thank you.

--
Luís Moreira de Sousa
Email: luis.de.so...@protonmail.ch
RingID: ring:7ca91d83f4f9dec82fec9f1144b8e5c1ef2a110c
URL: https://ldesousa.github.io

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release] 7.6.1

[Stefan Blumentrath]

Hi,

Can move:
https://ninsbl.gitlab.io/r.slope.direction/
to addons …
It is more a prove of concept than an efficient tool, however (should learn 
C/C++)…

Cheers
Stefan

P.S.: BTW, thanks to Vaclav for r.example.plus as a basis for a nice sandbox 
solution.


From: grass-dev  On Behalf Of Anna Petrášová
Sent: onsdag 27. mars 2019 16:34
To: Martin Landa 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] [release] 7.6.1

Hi, here is a screenshot:

https://drive.google.com/file/d/1ydqPLLDs85XA3rjXCgt0-TkDgEHCtige/view?usp=sharing

I was wondering what is the status of addons for Windows? No addons for 7.6.1 
yet, right? But also addons for 7.6.0 are not compiled, last date is March 7th?

Thanks!

On Sun, Mar 24, 2019 at 2:33 PM Martin Landa 
mailto:landa.mar...@gmail.com>> wrote:
Hi,

út 19. 3. 2019 v 21:44 odesílatel Martin Landa 
mailto:landa.mar...@gmail.com>> napsal:
> 2) write announcement (I can do later)

draft prepared in CMS. Some nice screenshot wanted :-) 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
___
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 pmav99):

 Note 1: Some tests require certain compilation options to be enabled (e.g.
 pdal, liblas etc). If support is missing the tests are failing. Ideally
 these tests should be skipped instead.

 Note 2: I did run the tests on an ubuntu VM where all the options were
 configured (except opencl and dwg). I did get several more failures than
 the ones reported
 [http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
 here]. More specifically on my VM:
 {{{
 (SVN revision 74319)
 Executed 233 test files in 0:29:16.353563.
 From them 194 files (83%) were successful and 39 files (17%) failed.
 }}}
 For comparison, the latest results from the test server are:
 {{{
 (SVN revision 74304)
 Executed 233 test files in 0:36:57.428963.
 From them 216 files (93%) were successful and 17 files (7%) failed.
 }}}
 I guess that this difference implies that the server is configured in a
 specific way which needs to be documented before we can replicate it on
 Travis.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release] 7.6.1

[Martin Landa]

Hi,

st 27. 3. 2019 v 16:33 odesílatel Anna Petrášová  napsal:
> https://drive.google.com/file/d/1ydqPLLDs85XA3rjXCgt0-TkDgEHCtige/view?usp=sharing

great, thanks. I added your screenshot to the announcement draft.

> I was wondering what is the status of addons for Windows? No addons for 7.6.1 
> yet, right? But also addons for 7.6.0 are not compiled, last date is March 
> 7th?

Yes, well, that's bad. Build server is working, the problem is that
results are not transferred to publish server (wingrass.fsv.cvut.cz)
since IIS is broken on build server. I copied latest build manually
now, so latest builds are available [1]. Will fix IIS on build server
or set up opposite communication (build -> publish) ASAP.

Ma

[1] https://wingrass.fsv.cvut.cz/grass76/x86_64/addons/

-- 
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

[GRASS-dev] [GRASS GIS] #3803: g.extension: Import requests for python3, too

[GRASS GIS]

#3803: g.extension: Import requests for python3, too
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 This is in continuation of #74116

 The patch is attached

-- 
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] #3803: g.extension: Import requests for python3, too

[GRASS GIS]

#3803: g.extension: Import requests for python3, too
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pmav99):

 * Attachment "g.extension.patch" added.


-- 
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] #3230: lib/raster/gdal.c – missing libgdal.20.dylib in the GDAL library names list

[GRASS GIS]

#3230: lib/raster/gdal.c – missing libgdal.20.dylib in the GDAL library names 
list
--+-
  Reporter:  vince|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  LibRaster|Version:  svn-releasebranch72
Resolution:   |   Keywords:  macosx
   CPU:  Unspecified  |   Platform:  MacOSX
--+-

Comment (by vince):

 Yes, I could probably do that within a few days, if you’re willing to
 integrate it.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Import PostGIS vector layer into SQLite database

[Markus Metz]

On Wed, Mar 27, 2019 at 5:42 PM Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
>
> Hi all,
>
> I am working with vector layers (points) composed of more than 100 000
geometries. These layers are originally in a PostGis database and I import
them with v.in.ogr, using a formulation like:
>
> v.in.ogr \
> input="PG:host=127.0.0.1 dbname=gisdb user=user password=secret" \
> layer=schema.points \
> output=points \
> -o --overwrite
>
> This command is successful, however, operations with the resulting points
layer are remarkably slow. For instance, this layer must be later loaded in
R and that operation alone is taking over 3 hours.
>
> After some back-and-forth testing, I identified the problem: v.in.ogr is
not saving its output in the internal GRASS SQLite database. Knowing this,
I can create a copy of the original output, that is automatically inserted
into the SQLite database, e.g.:
>
> g.copy vector=points,points_mirror
>
> Importing the points_mirror layer to R takes 3 minutes instead of 3
hours, for instance.

Which GRASS version are you using? This should not happen with recent
versions of GRASS 7.4 and 7.6.

Markus M

>
> While mirroring vectors imported with v.in.ogr solves the issue, it is an
inelegant solution that also takes up unnecessary space. I would prefer to
instruct v.in.ogr somehow to force it to use the SQLite database. I could
not find any reference in the manual, is it possible to do?
>
> Thank you.
>
> --
> Luís Moreira de Sousa
> Email: luis.de.so...@protonmail.ch
> RingID: ring:7ca91d83f4f9dec82fec9f1144b8e5c1ef2a110c
> URL: https://ldesousa.github.io
>
> Sent with ProtonMail Secure Email.
>
> ___
> 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] #3230: lib/raster/gdal.c – missing libgdal.20.dylib in the GDAL library names list

[GRASS GIS]

#3230: lib/raster/gdal.c – missing libgdal.20.dylib in the GDAL library names 
list
--+-
  Reporter:  vince|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  LibRaster|Version:  svn-releasebranch72
Resolution:   |   Keywords:  macosx
   CPU:  Unspecified  |   Platform:  MacOSX
--+-

Comment (by neteler):

 Replying to [comment:18 vince]:
 > Yes, I could probably do that within a few days, if you’re willing to
 integrate it.

 Problem solving contributions are always welcome :-)

-- 
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] #3803: g.extension: Import requests for python3, too

[GRASS GIS]

#3803: g.extension: Import requests for python3, too
--+--
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  python3, g.extension
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by neteler):

 * keywords:   => python3, g.extension
 * version:  unspecified => svn-trunk
 * component:  Default => Python
 * milestone:   => 7.8.0


Old description:

> This is in continuation of #74116
>
> The patch is attached

New description:

 This is in continuation of r74116

 The patch is attached

--

-- 
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] #3803: g.extension: Import requests for python3, too

[GRASS GIS]

#3803: g.extension: Import requests for python3, too
--+--
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  python3, g.extension
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by neteler):

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


Comment:

 In [changeset:"74323" 74323]:
 {{{
 #!CommitTicketReference repository="" revision="74323"
 g.extension: import requests for python3 as well as continuation of r74116
 (fixes #3803) (contributed by pmav99)
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Passed: GRASS-GIS/grass-ci#3409 (master - 707af0e)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3409
Status: Passed

Duration: 9 mins and 2 secs
Commit: 707af0e (master)
Author: Markus Neteler
Message: g.extension: import requests for python3 as well as continuation of 
r74116 (fixes #3803) (contributed by pmav99)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@74323 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/1d67489dec31...707af0e7e232

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/512254900?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the GRASS-GIS/grass-ci repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=5458449&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

___
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

[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

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

[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] [release] 7.6.1

[Anna Petrášová]

On Wed, Mar 27, 2019 at 2:49 PM Martin Landa  wrote:

> Hi,
>
> st 27. 3. 2019 v 16:33 odesílatel Anna Petrášová 
> napsal:
> >
> https://drive.google.com/file/d/1ydqPLLDs85XA3rjXCgt0-TkDgEHCtige/view?usp=sharing
>
> great, thanks. I added your screenshot to the announcement draft.
>
> > I was wondering what is the status of addons for Windows? No addons for
> 7.6.1 yet, right? But also addons for 7.6.0 are not compiled, last date is
> March 7th?
>
> Yes, well, that's bad. Build server is working, the problem is that
> results are not transferred to publish server (wingrass.fsv.cvut.cz)
> since IIS is broken on build server. I copied latest build manually
> now, so latest builds are available [1]. Will fix IIS on build server
> or set up opposite communication (build -> publish) ASAP.
>

I see, thank you!

>
> Ma
>
> [1] https://wingrass.fsv.cvut.cz/grass76/x86_64/addons/
>
> --
> 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