Re: [GRASS-dev] [GRASS GIS] #3509: g.region grow with negative number limited because of top and bottom

[GRASS GIS]

#3509: g.region grow with negative number limited because of top and bottom
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  minor   |  Milestone:  7.6.0
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  grow, shrink, g.region, expand
   CPU:  |  computational region, extent, 3D
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 What about just ignoring the request for decrease when the minimal range
 is reached? Not sure if that makes sense for X and Y, but it seems OK for
 Z.

-- 
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] #3509: g.region grow with negative number limited because of top and bottom

[GRASS GIS]

#3509: g.region grow with negative number limited because of top and bottom
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  minor   |  Milestone:  7.6.0
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  grow, shrink, g.region, expand
   CPU:  |  computational region, extent, 3D
  Unspecified|   Platform:  Unspecified
-+-

Comment (by lucadelu):

 I create this "workaround", I don't think a true fix could exist. It is
 something like if a user decide to set the Top smaller then Bottom.

 The same problem could append with extent

 {{{
 g.region -p raster=elevation
 g.region nsres=13480 ewres=14980 rows=1 cols=1 -p
 g.region -p grow=-1
 ERROR: North must be larger than South
 }}}

 Should we also try to fix something like the error above? Or we should
 just improve the output message?
 I think this is not a bug but a user error or misunderstanding.

 What do you think about the attached patch?

-- 
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] #3509: g.region grow with negative number limited because of top and bottom

[GRASS GIS]

#3509: g.region grow with negative number limited because of top and bottom
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  minor   |  Milestone:  7.6.0
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  grow, shrink, g.region, expand
   CPU:  |  computational region, extent, 3D
  Unspecified|   Platform:  Unspecified
-+-
Changes (by lucadelu):

 * Attachment "gregion.diff" added.

 proposed patch

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.ortho.transform output

[Markus Metz]

On Mon, Mar 12, 2018 at 2:40 PM, Luca Delucchi  wrote:
>
> Hi devs,
>
> A students is working with i.ortho.photo suite and he come to me with
> the wish of an improvement of
> g.gui.image2target.
>
> So I looked into i.ortho.transform code and I have few questions:
> - what is returned values of fwd format option? because the first
> value seems to be a coordinate but the second no...

When you do coordinate transformation with format = fwd or rev, the output
format is "x y z" of the transformed coordinates. Why do you think the
second value is not a coordinate?

> - could the output format be improved? right now there is no
> differences between different values of different formats option and
> two values of the same format

Can you provide an example with the command and options and the
corresponding output?

Markus M
>
> --
> 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] pygrass: How to allow Ctrl-C to stop all subprocesses of GridModule

[Glynn Clements]

Moritz Lennert wrote:

> Any hint how to allow Ctrl-C to stop all subprocesses ?

If you can get their PIDs, you should be able to use os.setpgid() to
move them into the same process group as the main script. Ctrl-C (by
default) sends SIGINT to all processes in the foreground process
group.

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

Re: [GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Markus Neteler]

On Tue, Mar 13, 2018 at 4:06 PM, Moritz Lennert
 wrote:
> Hi to all,
>
> A new addon is available [1]: i.cutlines tiles the images into tiles with
> irregular borders that avoid cutting through meaningful objects. This allows
> tiling an image for parallel processing while avoiding border effects.
>
> Enjoy !

Cool!
It would also be interesting for post-orthophoto mosaiking.

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

[GRASS-dev] new addon: i.cutlines - Creates semantically meaningful tile borders

[Moritz Lennert]

Hi to all,

A new addon is available [1]: i.cutlines tiles the images into tiles 
with  irregular borders that avoid cutting through meaningful objects. 
This allows tiling an image for parallel processing while avoiding 
border effects.


Enjoy !

Moritz


[1] https://grass.osgeo.org/grass74/manuals/addons/i.cutlines.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Margherita Di Leo]

Ciao Pietro and all,

On Mon, Mar 12, 2018 at 11:05 AM, Pietro  wrote:

>
>>
> I'm available to co-mentoring this GSoC.
>
>
>  may I remind to subscribe as a mentor filling the form https://goo.gl/
forms/kddSWrLkna84oXyb2 , it's not too late for new mentors, but the sooner
the better. Thanks!



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

Re: [GRASS-dev] [GRASS GIS] #3496: v.in.pdal: does not compile with PDAL 1.6.0

[GRASS GIS]

#3496: v.in.pdal: does not compile with PDAL 1.6.0
--+
  Reporter:  felixg   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Vector   |Version:  svn-releasebranch74
Resolution:  fixed|   Keywords:  v.in.pdal, PDAL, lidar
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by wenzeslaus):

 In [changeset:"72363" 72363]:
 {{{
 #!CommitTicketReference repository="" revision="72363"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496, #3243, #3101, #2732
 (author: felixg, backport of trunk r72246) + GPL header added in r72245
 }}}

-- 
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] #2732: Read lidar data as vector points using PDAL

[GRASS GIS]

#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  (none)
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.4.1
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-

Comment (by wenzeslaus):

 In [changeset:"72363" 72363]:
 {{{
 #!CommitTicketReference repository="" revision="72363"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496, #3243, #3101, #2732
 (author: felixg, backport of trunk r72246) + GPL header added in r72245
 }}}

-- 
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] #3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module expects them

[GRASS GIS]

#3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module
expects them
---+
  Reporter:  msieczka  |  Owner:  wenzeslaus
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.2.3
 Component:  Vector|Version:  7.2.0
Resolution:|   Keywords:
   CPU:  All   |   Platform:  All
---+

Comment (by wenzeslaus):

 In [changeset:"72363" 72363]:
 {{{
 #!CommitTicketReference repository="" revision="72363"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496, #3243, #3101, #2732
 (author: felixg, backport of trunk r72246) + GPL header added in r72245
 }}}

-- 
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] #3101: v.in.pdal compilation issue

[GRASS GIS]

#3101: v.in.pdal compilation issue
+-
  Reporter:  martinl|  Owner:  wenzeslaus
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.2.3
 Component:  Compiling  |Version:  unspecified
Resolution: |   Keywords:  v.in.pdal
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by wenzeslaus):

 In [changeset:"72363" 72363]:
 {{{
 #!CommitTicketReference repository="" revision="72363"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496, #3243, #3101, #2732
 (author: felixg, backport of trunk r72246) + GPL header added in r72245
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Vaclav Petras]

On Tue, Mar 13, 2018 at 2:56 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> Would it be a good idea to schedule a virtual meeting during the code
sprint next week ?

Yes, please. I plan to be available on Monday to do calls.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module expects them

[GRASS GIS]

#3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module
expects them
---+
  Reporter:  msieczka  |  Owner:  wenzeslaus
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.2.3
 Component:  Vector|Version:  7.2.0
Resolution:|   Keywords:
   CPU:  All   |   Platform:  All
---+

Comment (by mlennert):

 Replying to [comment:7 wenzeslaus]:
 > Assigning to myself for clarity, but should be fixed in r72253 from
 #3496 by felixg for 7.4. Do we need/want to backport?

 Yes, please. For me v.in.pdal compilation fails in 7.2.3RC1 because of
 this.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Is automatic compilation of addons currently working ?

[Moritz Lennert]

On 13/03/18 11:20, Martin Landa wrote:

Hi,

2018-03-13 10:22 GMT+01:00 Moritz Lennert :

At https://grass.osgeo.org/addons/grass7/logs/ I see "logs generated Mon, 29
Jan 2018".

This seems to lead to the fact that recently added addons are not in the
list of addon manual pages...


not sure why cronjobs stopped working. I run script manually for now.
But we need to investigate if the cronjobs starts to work. Basically
in less than 30min the logs/manual should be updated after each
grass_addons commit. Ma




Great, thanks ! Will try to keep an eye on it.

Moritz

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

Re: [GRASS-dev] [GRASS GIS] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

[GRASS GIS]

#3331: ctypes: ValueError: invalid literal for int() with base 8:
'08420217248550443400745280086994171'
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Python   |Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by lucadelu):

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


Comment:

 Ok, backported in r72361.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Is automatic compilation of addons currently working ?

[Markus Neteler]

On Tue, Mar 13, 2018 at 11:20 AM, Martin Landa  wrote:
> 2018-03-13 10:22 GMT+01:00 Moritz Lennert :
>> At https://grass.osgeo.org/addons/grass7/logs/ I see "logs generated Mon, 29
>> Jan 2018".
>>
>> This seems to lead to the fact that recently added addons are not in the
>> list of addon manual pages...

(FWIW, here is the procedure
 https://trac.osgeo.org/grass/browser/grass-addons/tools/addons/README.txt
)

> not sure why cronjobs stopped working. I run script manually for now.
> But we need to investigate if the cronjobs starts to work. Basically
> in less than 30min the logs/manual should be updated after each
> grass_addons commit.

Perhaps a change in the trac server does no longer trigger the job at your end?

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

Re: [GRASS-dev] Is automatic compilation of addons currently working ?

[Martin Landa]

Hi,

2018-03-13 10:22 GMT+01:00 Moritz Lennert :
> At https://grass.osgeo.org/addons/grass7/logs/ I see "logs generated Mon, 29
> Jan 2018".
>
> This seems to lead to the fact that recently added addons are not in the
> list of addon manual pages...

not sure why cronjobs stopped working. I run script manually for now.
But we need to investigate if the cronjobs starts to work. Basically
in less than 30min the logs/manual should be updated after each
grass_addons commit. 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] Is automatic compilation of addons currently working ?

[Moritz Lennert]

At https://grass.osgeo.org/addons/grass7/logs/ I see "logs generated 
Mon, 29 Jan 2018".


This seems to lead to the fact that recently added addons are not in the 
list of addon manual pages...


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

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.3

[Martin Landa]

Hi,

2018-03-11 20:53 GMT+01:00 Markus Neteler :
> # Fedora --> result: ok
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25638976
>
> # EPEL7 --> result: ok
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25639160

WinGRASS standalone installer for testing:

https://grass.osgeo.org/grass72/binary/mswindows/native/x86/WinGRASS-7.2.3RC1-1-Setup-x86.exe

https://grass.osgeo.org/grass72/binary/mswindows/native/x86_64/WinGRASS-7.2.3RC1-1-Setup-x86_64.exe

> Looks good for the final release :-)

Me too :-) 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

Re: [GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Moritz Lennert]

Hi to all,

I like the proposal and the discussion.

Would it be a good idea to schedule a virtual meeting during the code sprint 
next week ?

Moritz

Am 13. März 2018 02:16:09 MEZ schrieb Vaclav Petras :
>Hi Markus,
>
>On Mon, Mar 12, 2018 at 3:03 PM, Markus Metz
>
>wrote:
>>
>> On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras 
>wrote:
>>
>> The example in the wiki is based on a GeoTIFF file with a single
>raster
>band. IMHO, the input should be more general in the form
>"GDAL_raster_datasource raster_band" and "GDAL_vector_datasource
>layer_name".
>
>Yes, I agree, the input files in the examples are trivial. Ideally,
>this
>should also work with things like PostGIS or NetCDF for time series. I
>don't have proposal for the syntax at this point, space from your
>suggestion, colon, and a separate ...-layer pseudo-option come to my
>mind.
>
>For vectors we already have a similar case with @OGR mapset where we
>use
>vector map name for GDAL_vector_datasource and layer for layer_name.
>
>There we hit some terminology differences but that could be mitigated
>by
>adding something like OGC compliant descriptions which might be anyway
>needed for the better integration with QGIS.
>
>https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3
>
>> Specifying a raster band/layer name should probably be mandatory.
>
>I'm not sure if it should be mandatory or not. I think @OGR requires
>the
>layer, but if user provides a single band GeoTIFF or a Shapefile, it
>seems
>as expected behavior that the only band/layer is picked automatically.
>
>> The new parser would then use GDAL to test if the given datasource is
>valid and if the given raster band/vector layer exists in this
>datasource.
>
>These and other tests will be big part of the backend: "The system
>behind
>the interface will be inherently fragile, so it is necessary to write
>large
>amount of tests which would check different combinations of data types
>and
>projections."
>
>> I guess the main part of this project would be to write a parser for
>the
>`grass run` arguments that translates them to an actual GRASS command.
>
>Yes, there are two types of arguments, those related to `grass run`
>like
>`--mask` and then those which are part of module interface like `input`
>which translate to some import commands and also the module option.
>
>In case somebody wonders, yes, `--mask` could be a general option for
>all
>the module, in fact `--region` was already discussed (r.relief
>input=...
>--v --r="n=5520 s=4000..."). Further, `input` could be written like
>`--input` to follow POSIX and finally, even to modules themselves could
>accept the general files (like with @OGR), rather than going through
>`run`.
>But any of these are outside of scope for this GSoC and it is probably
>a
>good idea to leave them for the next iteration. Same goes for the full
>subcommand interface idea and Grassfile (directory rc file) idea
>mentioned
>in the comment 15 of #2579.
>
>https://trac.osgeo.org/grass/ticket/2579#comment:15
>
>> > Mentors: I'm seeking an additional mentor for this idea. I put
>myself
>as first, but you can be first or second mentor as you wish.
>>
>> I would be interested in the general design and concept for the
>implementation of this project.
>
>Great, this will be very helpful.
>
>> A very interesting idea that would facilitate the use of GRASS as a
>toolbox similar to GDAL or (ambitious reference) OTB.
>
>Thanks and thanks for the feedback too!
>
>Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3388: Legacy appstream metadata

[GRASS GIS]

#3388: Legacy appstream metadata
-+-
  Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Default |Version:  7.2.1
Resolution:  fixed   |   Keywords:  appstream
   CPU:  Unspecified |   Platform:  Linux
-+-
Changes (by neteler):

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


Comment:

 Backported to 7.4.svn, 7.2.svn, 7.0.svn, and 6.4.svn. Closing.

-- 
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] #3388: Legacy appstream metadata

[GRASS GIS]

#3388: Legacy appstream metadata
-+-
  Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Default |Version:  7.2.1
Resolution:  |   Keywords:  appstream
   CPU:  Unspecified |   Platform:  Linux
-+-

Comment (by Bas Couwenberg):

 That's what the Debian package does as well, that should be fine.

-- 
Ticket URL: 
GRASS GIS 

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