[GRASS-dev] Fwd: [gdal-dev] ogr2ogr clip operation very slow compared to QGIS

2018-11-13 Thread Markus Neteler
FYI - not sure if relevant for us

-- Forwarded message -
From: Nyall Dawson 
Date: Wed, Nov 14, 2018 at 12:17 AM
Subject: Re: [gdal-dev] ogr2ogr clip operation very slow compared to QGIS
To: Even Rouault 
Cc: gdal dev 

On Wed, 14 Nov 2018 at 01:03, Even Rouault  wrote:

> Looking at QGIS code, it uses GEOS prepared geometry mechanism with the clip
> geometry, so as to speed up intersection operations on it. Whereas ogr2ogr -
> clipsrc uses the 'naive' intersection function. I guess this is the reason for
> the speed difference.

This is the big difference -- using the prepared methods results in
orders of magnitude speed boosts.

> QGIS also checks for the result of contains() and
> intersects() predicates before calculating the intersection geometry. Not sure
> how much that speed-up things.

Significantly (sorry no actual figures available). What's happening
here is the GEOS intersection method doesn't utilise prepared
geometries, yet the tests like contains and intersects do. The raw
intersection method is slow, even if there's no actual intersection or
if the geometry will be returned unchanged (i.e. it's within the clip
mask). So by taking advantage of the fast within/intersects tests on
the prepared geometry we potentially skip a bunch of unnecessary slow
intersection calculations.

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

Re: [GRASS-dev] [GRASS GIS] #3689: v.rast.stats: add where option

2018-11-13 Thread GRASS GIS
#3689: v.rast.stats: add where option
--+--
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  v.rast.stats
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by veroandreo):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.8.0 => 7.6.0


Comment:

 Milestone changed to 76 and change backported. Closing.

 Thanks again, markusM :)

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--

Comment (by mmetz):

 Replying to [comment:3 BastienFR]:
 > Thanks for your answer.  I did try with the good option `layer=1`
 directly in GRASS and it worked as expected.  I'll update my question on
 StackExchange to give the answer (or if you want to do it, I'll accept
 your answer).

 You can update your question to give the answer, maybe with a link to the
 manual and the (by now updated) tutorial ;-)
 >
 > However, note that your tutorial do not state that properly
 (https://grasswiki.osgeo.org/wiki/V.generalize_tutorial#Gereneral_Parameters).
 There is no `layer` option in the call given.
 >
 > {{{
 > v.generalize -c input=roads output=roads_douglas_reduction2
 method=douglas_reduction threshold=0 reduction=50 type=line where="cat<3"
 > }}}

 Thanks for pointing this out, now fixed.

 The tutorial has been written for the initial version of v.generalize
 where the default answer for the layer option was 1. The default has been
 changed from 1 to -1 (all layers) in r39888 (9 years ago).
 >
 > The fact the the QGIS v.generalize tool do not allow to set the `layer`
 option even if allowing setting the `WHERE` statement, how or where should
 we document the problem so it's fix there?

 The QGIS interface description for v.generalize needs to have layer=1
 hard-coded (not a user-option).

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--

Comment (by BastienFR):

 Thanks for your answer.  I did try with the good option `layer=1` directly
 in GRASS and it worked as expected.  I'll update my question on
 StackExchange to give the answer (or if you want to do it, I'll accept
 your answer).

 However, note that your tutorial do not state that properly
 (https://grasswiki.osgeo.org/wiki/V.generalize_tutorial#Gereneral_Parameters).
 There is no `layer` option in the call given.

 `v.generalize -c input=roads output=roads_douglas_reduction2
 method=douglas_reduction threshold=0 reduction=50 type=line where="cat<3"`

 The fact the the QGIS v.generalize tool do not allow to set the `layer`
 option even if allowing setting the `WHERE` statement, how or where should
 we document the problem so it's fix there?

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--

Comment (by mmetz):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:3694 BastienFR]:
 > > The `WHERE` statement from `v.generalize` do not seem to work anymore.
 >
 > Looking at the manual G7:v.generalize:
 >
 > layer=string
 > Layer number or name ('-1' for all layers)
 >
 > A single vector map can be connected to multiple database tables.
 This number determines which table to use. When used with direct OGR
 access this is the layer name.
 >
 > Default: -1
 >
 > By default all layers are processed, in which case the cats and where
 options are ignored because they require a single layer to be selected.

 FWIW, I have added a warning in trunk r73673 if the cats and where options
 are ignored.

 The QGIS interface description for v.generalize needs to be fixed to use
 `layer=1`.

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--

Comment (by mmetz):

 Replying to [ticket:3694 BastienFR]:
 > The `WHERE` statement from `v.generalize` do not seem to work anymore.

 Looking at the manual G7:v.generalize:

 layer=string
 Layer number or name ('-1' for all layers)

 A single vector map can be connected to multiple database tables. This
 number determines which table to use. When used with direct OGR access
 this is the layer name.

 Default: -1

 By default all layers are processed, in which case the cats and where
 options are ignored because they require a single layer to be selected.

 Results are as expected when using `v.generalize layer=1 where="CNTY<1"
 ...`.

 Note that a boundary is generalized as soon as any of the areas it belongs
 to fulfils the where condition. In a topological vector model as in GRASS,
 the modification of a single boundary results in the modification of two
 areas.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] r.pi addons on windows

2018-11-13 Thread Luca Delucchi
Hi devs,

it seems that there are problem in the compilation of r.pi addons on windows [0]
Could someone check to the problems?

[0] http://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.2/logs/r.pi.log

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--
Changes (by BastienFR):

 * Attachment "NC_test.shp" added.

 shp

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--
Changes (by BastienFR):

 * Attachment "NC_test.shx" added.

 shx

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--
Changes (by BastienFR):

 * Attachment "NC_test.prj" added.

 prj

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--
Changes (by BastienFR):

 * Attachment "NC_test.dbf" added.

 NC_test.dbf

-- 
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] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
+--
  Reporter:  BastienFR  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Default|Version:  7.4.1
Resolution: |   Keywords:  v.generalize
   CPU:  x86-64 |   Platform:  MSWindows
+--
Changes (by BastienFR):

 * Attachment "Capture.PNG" added.

 result_image

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3694: WHERE statement in v.generalize do not work

2018-11-13 Thread GRASS GIS
#3694: WHERE statement in v.generalize do not work
--+-
 Reporter:  BastienFR |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:
Component:  Default   |Version:  7.4.1
 Keywords:  v.generalize  |CPU:  x86-64
 Platform:  MSWindows |
--+-
 The `WHERE` statement from `v.generalize` do not seem to work anymore.

 A good description of the problem was done at:

 https://gis.stackexchange.com/questions/301858/cannot-manage-to-get-the-
 where-statement-to-work-in-v-generalize

 Another example:

 The attached shape was produced in R with:


 {{{
 library(sf)
 library(dplyr)

 # preparing the shapefile
 nc <- st_read(system.file("gpkg/nc.gpkg", package="sf"), quiet = TRUE) %>%
   mutate(CNTY = as.numeric(CNTY_%
   select(CNTY) %>%
   st_transform(st_crs(2264)) %>%
   st_write("d:/temp/NC_test.shp")
 }}}


 Using QGIS to call `v.generalize` (the same problem happens in grass
 directly, however I prefer working directly in QGIS):

 `C:\OSGEO4~1\bin>v.generalize input=vector_5beaccc5750337
 type="line,boundary,area" where="CNTY<1" method="douglas" threshold=15000
 look_ahead=7 reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0
 closeness_thresh=0 betweeness_thresh=0 alpha=1 beta=1 iterations=1 -l
 output=outputdc6669bcd1974052b171ef4c11d51846
 error=errordc6669bcd1974052b171ef4c11d51846 --overwrite`

 I get generalization over all the territory and not just limited to the
 polygons where `CNTY<1`

 (see image 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] #3693: Issue with G76 in docker: creating a location fails

2018-11-13 Thread GRASS GIS
#3693: Issue with G76 in docker: creating a location fails
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.3
 Component:  Startup  |Version:  svn-releasebranch76
Resolution:   |   Keywords:  docker g.proj
   CPU:  x86-64   |   Platform:  Linux
--+-

Comment (by neteler):

 Problem solved: update of docker-compose from v1.8.0 to v1.23.1 (what a
 waste of time to figure out this one...).

 Explanations:

 {{{
 Program received signal SIGILL, Illegal instruction.
 }}}

 This means that a CPU instruction is called which is not present in the
 CPU running the docker. In our case, we run it on a KVM virtualization.
 Apparently docker-compose v1.23 (at least, later than v1.8 addresses the
 problem of the missing instruction). w00t!

 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] #3693: Issue with G76 in docker: creating a location fails

2018-11-13 Thread GRASS GIS
#3693: Issue with G76 in docker: creating a location fails
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.4.3
 Component:  Startup |Version:  svn-releasebranch76
Resolution:  worksforme  |   Keywords:  docker g.proj
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by neteler):

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


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] PyGRASS: changing description and comments

2018-11-13 Thread Markus Neteler
On Tue, Nov 13, 2018 at 9:03 AM Luca Delucchi  wrote:
> Il giorno sab 10 nov 2018, 17:46 Luí­s Moreira de Sousa 
>  ha scritto:
>>
>> Hi all,
>
>
> Hi Luis,
>>
>>
>> is there a way of modifying the contents of the description and comments 
>> fields associated with rasters? I could also use r.support, but it would be 
>> more elegant to use the API.
>
>
> It seems that description and comments are not possible to be modified by the 
> API, other values instead are [0]
>
> [0] 
> https://grass.osgeo.org/grass70/manuals/libpython/pygrass.raster.html#module-pygrass.raster.history

... grass70 is a bit dated, better:
https://grass.osgeo.org/grass74/manuals/libpython/pygrass.raster.html#module-pygrass.raster.history

even better
https://grass.osgeo.org/grass76/manuals/libpython/pygrass.raster.html#module-pygrass.raster.history

It will not change much but old API descriptions may lead to confusion.

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

Re: [GRASS-dev] PyGRASS: changing description and comments

2018-11-13 Thread Luca Delucchi
Il giorno sab 10 nov 2018, 17:46 Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> ha scritto:

> Hi all,
>

Hi Luis,

>
> is there a way of modifying the contents of the description and comments
> fields associated with rasters? I could also use r.support, but it would be
> more elegant to use the API.
>

It seems that description and comments are not possible to be modified by
the API, other values instead are [0]

[0]
https://grass.osgeo.org/grass70/manuals/libpython/pygrass.raster.html#module-pygrass.raster.history


> Thank you.
> --
>

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

Re: [GRASS-dev] [GRASS GIS] #3689: v.rast.stats: add where option

2018-11-13 Thread GRASS GIS
#3689: v.rast.stats: add where option
--+--
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.rast.stats
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mmetz):

 Replying to [comment:7 veroandreo]:
 > Thanks so much, MarkusM! Committed in r73666. Milestone was set to 7.8,
 but is it worth a backport to next 7.6 release?

 I think it's ok if you backport to 7.6

-- 
Ticket URL: 
GRASS GIS 

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