Re: [GRASS-dev] [GRASS GIS] #2424: PyGRASS does not work when GRASS is invoked from outside

[GRASS GIS]

#2424: PyGRASS  does not work when GRASS is invoked from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Python  |Version:  svn-trunk
  ctypes |   Keywords:  installation, pygrass, temporal,
Resolution:  |  scripts
   CPU:  |   Platform:  MSWindows 8
  Unspecified|
-+-

Comment (by wenzeslaus):

 These both help, but just to clarify, here we are concerned with only the
 part of the Python API which uses `ctypes` in the background, i.e. not
 `grass.script` which works just fine, but with `grass.temporal` and a
 significant part of `grass.pygrass`.

 Replying to [comment:12 neteler]:
 >  * Python: GRASS GIS 7 with an external library: grass-session:

 This makes using `grass.script` much easier, but it is not possible to use
 anything which calls ''ctypes'' (`grass.lib`), i.e. `grass.temporal` and
 `grass.pygrass`, unless the dynamic libraries are loaded in some special
 way (just changing `LD_LIBRARY_PATH` was not enough so far). (From
 `grass.pygrass` I mean the part using `ctypes`, otherwise see the
 comment:3 to comment:6 here.)

 >  * New easy-to-use CLI and API for GRASS GIS

 In past your would have to do this (see comment:6 for details):

 {{{
 export LD_LIBRARY_PATH=$(grass70 --config path)/lib
 python script_with_ctypes.py
 }}}

 Since 7.2 (after #2579, i.e. r65252), you can (see again comment:6 for
 details):

 {{{
 grass ~/grassdata/nc_spm/test/ --exec script_with_ctypes.py
 }}}

 In regard to this ticket, the proposed CLI would work similarly to current
 `--exec`. Same goes to the proposed Python API and the current APIs.

 Nevertheless, `--exec` and the proposed CLI interface reduce the need to
 load the libraries, for example, because the recommended way of using them
 is to write a GRASS module and then call it using `--exec` - this way the
 GRASS-specific part of the program is isolated and at the same time usable
 as a separate GRASS module.

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

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] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Vaclav Petras]

Hi Pietro,

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

>
> On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras 
> wrote:
>
>> I just compiled a another idea for this year GSoC:
>>
>> https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-useCL
>> IandAPIforGRASSGIS
>>
>
> I like the idea! It is still not clear to me if you think to have a
> persistent storage for the "temporary" location/mapset or if they are
> generated every time.
>


I'm not sure what you mean by "persistent storage". The current system of
connecting to an existing "D/L/M" stays in place. I mean temporary as a
temporary directory, e.g. in /tmp:

"""
GRASS Database would be created with an appropriate Location (projection
based on input files or additional CLI input).
The GRASS GIS Database, Location and Mapset should be created on the fly
and deleted afterwards (the .grassrc wouldn't be used).
...
Add --tmp-location which runs --exec in a database/location/mapset which
are created at the beginning and deleted at the end.
"""

So, basically combination of current -c, --exec, and rm -r.

If you have ideas about how it make it more efficient that would be great
since the overhead for the run option/subcommand will be high. Currently,
the idea is that user can use an existing "D/L/M" if higher efficiency is
needed (i.e. same as now).


> 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'm available to co-mentoring this GSoC.
>

Awesome!
___
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
+-
Changes (by wenzeslaus):

 * owner:  grass-dev@… => wenzeslaus


Comment:

 Assigning to myself for clarity, but should be fixed in r72253 from #3496
 by felixg for 7.4. Do we need/want to backport?

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

 * owner:  ptschrum => wenzeslaus
 * status:  assigned => new


Comment:

 Assigning to myself for clarity, but should be fixed in r72253 from #3496
 by felixg for 7.4. Do we need/want to backport?

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

 Please check if r72356 makes sense (trunk). Then I'll backport 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] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

[GRASS GIS]

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by mmetz):

 Replying to [comment:21 neteler]:
 > Anything left here?

 According to [https://www.python.org/dev/peps/pep-0394/ Python PEP 394],
 we need to decide if we replace the shebang `#!/usr/bin/env python` with
 `#!/usr/bin/env python2` or `#!/usr/bin/env python3`. This applies not
 only to FreeBSD, but also to Linux distros.

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

 Instead of installing the file as `/usr/share/appdata/grass.appdata.xml`
 it should be installed as
 `/usr/share/metainfo/org.osgeo.grass.appdata.xml`.

 The Debian package does that because lintian complains about the legacy
 location.

-- 
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] #3231: ctypesgen.py fails during grass compilation

[GRASS GIS]

#3231: ctypesgen.py fails during grass compilation
--+-
  Reporter:  vince|  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Compiling|Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:  MacOS X
   CPU:  Unspecified  |   Platform:  MacOSX
--+-
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.2.3 => 7.2.2


Comment:

 This got fixed in r71219 in relbranch72 (see also #3331) and published
 with 7.2.2.

 Closing. Please reopen if needed.

-- 
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] #2424: PyGRASS does not work when GRASS is invoked from outside

[GRASS GIS]

#2424: PyGRASS  does not work when GRASS is invoked from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Python  |Version:  svn-trunk
  ctypes |   Keywords:  installation, pygrass, temporal,
Resolution:  |  scripts
   CPU:  |   Platform:  MSWindows 8
  Unspecified|
-+-

Comment (by neteler):

 Please see
  * Python: GRASS GIS 7 with an external library: grass-session:
   *
 
https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#Python:_GRASS_GIS_7_with_an_external_library
 :_grass-session
  * New easy-to-use CLI and API for GRASS GIS
   * https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-
 useCLIandAPIforGRASSGIS

-- 
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] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

[GRASS GIS]

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by neteler):

 Anything left here?

-- 
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:  grass-dev@…
  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 neteler):

 See r72253: v.in.pdal: change API calls to PDAL 1.6.0 (available in G7.4).

 See also #3243

-- 
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] #3234: d.barscale: HTMLParser.HTMLParseError: EOF in middle of construct

[GRASS GIS]

#3234: d.barscale: HTMLParser.HTMLParseError: EOF in middle of construct
+-
  Reporter:  spareeth   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.2.3
 Component:  Compiling  |Version:  svn-trunk
Resolution: |   Keywords:
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by neteler):

 Sajid: still an issue?

-- 
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] #3385: Typo in the i.vi man page

[GRASS GIS]

#3385: Typo in the i.vi man page
--+--
  Reporter:  micha|  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Docs |Version:  7.2.0
Resolution:   |   Keywords:  Vegetation Index
   CPU:  Unspecified  |   Platform:  All
--+--

Comment (by neteler):

 ping

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

 Bas, anything missing here?

-- 
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] #3027: i.atcorr's create_iwave.py broken

[GRASS GIS]

#3027: i.atcorr's create_iwave.py broken
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Imagery  |Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:  i.atcorr
   CPU:  x86-64   |   Platform:  All
--+-
Changes (by neteler):

 * status:  reopened => closed
 * resolution:   => fixed
 * milestone:  7.2.3 => 7.4.0


Comment:

 Due to too many changes no backport to 7.2 planned: please use GRASS GIS
 7.4 where it was fixed.

-- 
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:  ptschrum
  Type:  defect| Status:  assigned
  Priority:  normal|  Milestone:  7.2.3
 Component:  Vector|Version:  7.2.0
Resolution:|   Keywords:
   CPU:  All   |   Platform:  All
---+--

Comment (by neteler):

 See r72253: v.in.pdal: change API calls to PDAL 1.6.0 (available in G7.4)

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

[Markus Metz]

On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras  wrote:
>
> Dear list,
>
> I just compiled a another idea for this year GSoC:
>
>
https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-useCLIandAPIforGRASSGIS
>
> All: You may remember this idea from 2015. Since then I implemented
--exec which, I think, is successful since I can see it used in different
posts online. However, I also think that --exec is far from an ideal
interface. I seek comments for the ideas and newly proposed CLI and
potential Python API design which is presented at the wiki.

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". Specifying a raster band/layer name should probably be
mandatory. 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.

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

A very interesting idea that would facilitate the use of GRASS as a toolbox
similar to GDAL or (ambitious reference) OTB.

Markus M
>
> Students: This email applies to all potential GSoC students, but I'm
including those of you who posted on the mailing list so far to CC just to
let you know that you can apply for more than one idea which is more than
appropriate when there is more than one student interested in the same
idea. Please find details about this idea at the wiki.
>
> Thank you and please let me if you have any questions or comments,
> Vaclav
>
> ___
> 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] #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:  reopened
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Python   |Version:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:47 lucadelu]:
 > Should the patch also backported to GRASS 6.4?
 >
 > I got the same bug and I fixed applying the patch...

 Yes, please apply to releasebranch_6_4

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] i.ortho.transform output

[Luca Delucchi]

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

-- 
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] [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:  reopened
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Python   |Version:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by lucadelu):

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


Comment:

 Should the patch also backported to GRASS 6.4?

 I got the same bug and I fixed applying the 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] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Pietro]

Dear Vaclav,

On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras  wrote:

> I just compiled a another idea for this year GSoC:
>
> https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-
> useCLIandAPIforGRASSGIS
>

I like the idea! It is still not clear to me if you think to have a
persistent storage for the "temporary" location/mapset or if they are
generated every time.

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'm available to co-mentoring this GSoC.

Best regards

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

Re: [GRASS-dev] [GRASS GIS] #3511: [patch] v.buffer: allow squared buffers around points

[GRASS GIS]

#3511: [patch] v.buffer: allow squared buffers around points
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  v.buffer squared buffer
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

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


Comment:

 Closing this ticket as fixed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] How difficult would it be to modify v.buffer to allow creation of square buffers around points

[Moritz Lennert]

On 05/03/18 18:15, Moritz Lennert wrote:

On 05/03/18 14:10, Markus Metz wrote:



On Mon, Mar 5, 2018 at 12:07 PM, Moritz Lennert 
> 
wrote:

 >
 > Hi,
 >
 > For some applications it is sometimes interesting to be able to 
create square buffers around points. So my question to those who know 
the GEOS code best: How difficult would it be to change v.buffer to be 
able to do this ?


Buffers around points are trivial, and square buffers around points 
would be even more trivial. This could be triggered by the already 
existing -s flag (square caps at end of lines, outside corners straight).


Please create a ticket for square buffers around points such that this 
request does not get forgotten.


Done [1] already with an attempt at a (very simple) patch. Would be 
great if you could have a look.


Moritz
> [1] https://trac.osgeo.org/grass/ticket/3511


Better version now committed in r72353.

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

Re: [GRASS-dev] [GRASS GIS] #3511: [patch] v.buffer: allow squared buffers around points

[GRASS GIS]

#3511: [patch] v.buffer: allow squared buffers around points
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.buffer squared buffer
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:4 mmetz]:
 > Replying to [comment:3 mlennert]:
 > > Replying to [comment:2 mmetz]:
 > > > Replying to [comment:1 mlennert]:
 > > > > Replying to [ticket:3511 mlennert]:
 > > > > > The attached patch implements squared buffers around points.
 > > > >
 > > > > Forgot to explain: with the patch, v.buffer should create square
 buffers around points if the -s flag is set.
 > > >
 > > > Currently v.buffer always uses Vect_point_buffer2() for points, but
 the Vect_*_buffer*() functions might disappear at some stage because they
 are not working properly (apart from point buffering). Therefore it might
 be safer to add this functionality to v.buffer directly.
 > >
 > > Please check the attached new patch.
 >
 > The patch looks and works fine, please commit.

 Done in r72353.

-- 
Ticket URL: 
GRASS GIS 

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