Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Veronica Andreo]

Hi Moritz

Thanks for the heads-up! Yes, for overlapping buffers v.rast.bufferstats
seems just perfect! IIUC, it does exactly what MM was explaining. Great!

Thanks again! And thanks Stefan for the add-on!

Vero


El mié., 22 may. 2019 19:30, Moritz Lennert 
escribió:

> Le Wed, 22 May 2019 19:25:19 +0200,
> Veronica Andreo  a écrit :
>
> > Hi Markus,
> >
> > Thanks for the explanation. It is possible to import topologically
> > incorrect vectors, but not create them within GRASS. So, as a
> > solution to my problem, I rather create (potentially overlapping)
> > buffers outside GRASS and import them with -c in v.in.ogr to use
> > v.rast.stats with no loss of areas, or follow the procedure that you
> > described earlier in the thread.
>
> You can also have a look at the v.rast.bufferstats addon.
>
> Moritz
>
> >
> > Cheers,
> > Vero
> >
> > El mié., 22 may. 2019 a las 18:48, Markus Metz (<
> > markus.metz.gisw...@gmail.com>) escribió:
> >
> > >
> > >
> > > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo
> > >  wrote:
> > > >
> > > > Dear all,
> > > >
> > > > thanks again for your answers. I found an easier way, use -c flag
> > > > in
> > > v.in.ogr seems to not build topology of overlapping areas and then
> > > v.rast.stats does not complain.
> > > >
> > > > However, if one builds buffer areas for points within GRASS,
> > > > i.e., using
> > > v.buffer, the problem appears again when buffer areas overlap,
> > > which it's pretty common when creating buffers around neighbouring
> > > points. Then, to get zonal stats for those areas the approach
> > > suggested by Markus Metz should be followed. I believe it is a bit
> > > of an overkill for such a common task in GIS. Couldn't v.buffer
> > > have a -c flag as v.in.ogr so when overlapping of buffer areas is
> > > fine the topology is not built and one would get just one area per
> > > input point? Would that be possible?
> > >
> > > In short, no.
> > >
> > > The reason is that with a topological vector model, areas are
> > > constructed from boundaries and centroids. If you use the -c flag
> > > of v.in.ogr and there are polygons that overlap to a large degree
> > > or completely, it is not possible to find a centroid for each
> > > topological area, i.e. the overlapping input polygons can not be
> > > properly represented with a topological model when using the -c
> > > flag. As soon as you get incorrect boundaries and/or duplicate
> > > centroids when building topology, results are wrong.
> > >
> > > Markus M
> > >
> > > >
> > > > cheers,
> > > > Vero
> > > >
> > > >
> > > >
> > > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
> > > mlenn...@club.worldonline.be>) escribió:
> > > >>
> > > >> On 16/05/19 03:11, Veronica Andreo wrote:
> > > >> > Dear all,
> > > >> >
> > > >> > thanks for the answers...
> > > >> >
> > > >> > @Madi, I know, but that's how I got the data from a colleague
> > > >> > using SaTScan to get cluster sizes.
> > > >> >
> > > >> > So, these "clusters" are 3, they are represented by circular
> > > >> > areas
> > > and 2
> > > >> > of them overlap, and it is just fine that they overlap. I just
> > > >> > want
> > > one
> > > >> > centroid per area to be able to get one value per original
> > > >> > area.
> > > >> >
> > > >> > I tested your solution, @Micha (thanks much for your time!),
> > > >> > but it gives me 4 values, and I need 3. Moreover, I can no
> > > >> > longer recognize which polygon is which since v.db.select for
> > > >> > layer 3 reports cats
> > > from 1
> > > >> > to 4, but d.vect shows something different (I'd assume 2/3 has
> > > >> > become 4?). See screenshot below.
> > > >>
> > > >> To see the cat values of layer 3 you have to indicate that layer
> > > >> in the label_layer parameter (Labels tab).
> > > >>
> > > >> You can also see the correspondance between the two layers with
> > > >>
> > > >> v.category polys_3layers op=print layer=1,3
> > > >>
> > > >> >
> > > >> > So, is it possible somehow to keep my 3 original polygons? And
> > > >> > how
> > > can I
> > > >> > get raster values for my original 3 polygons in GRASS? Or is
> > > >> > it that this is not allowed by topology?
> > > >>
> > > >> This depends on how you want to get raster values. If
> > > >> v.what.rast at the location of the centroid is all you need than
> > > >> Micha's solution should
> > > work.
> > > >>
> > > >> If you need v.rast.stats then you either have to use Markus'
> > > >> suggestion, or you use Micha's approach running v.rast.stats on
> > > >> layer three and then use some magic to transform the output of
> > > >> the above v.category call to a correspondance table between
> > > >> layer. Something like this
> > > >>
> > > >> import grass.script as g
> > > >> for feature in g.read_command('v.category',
> > > >>   input_='polys_3layers',
> > > >>   op='print',
> > > >>layer=[3,1]).splitlines():
> > > >>   cat1 = feature.split('|')[0]
> > > 

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Moritz Lennert]

Le Wed, 22 May 2019 19:25:19 +0200,
Veronica Andreo  a écrit :

> Hi Markus,
> 
> Thanks for the explanation. It is possible to import topologically
> incorrect vectors, but not create them within GRASS. So, as a
> solution to my problem, I rather create (potentially overlapping)
> buffers outside GRASS and import them with -c in v.in.ogr to use
> v.rast.stats with no loss of areas, or follow the procedure that you
> described earlier in the thread.

You can also have a look at the v.rast.bufferstats addon.

Moritz

> 
> Cheers,
> Vero
> 
> El mié., 22 may. 2019 a las 18:48, Markus Metz (<
> markus.metz.gisw...@gmail.com>) escribió:  
> 
> >
> >
> > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo
> >  wrote:  
> > >
> > > Dear all,
> > >
> > > thanks again for your answers. I found an easier way, use -c flag
> > > in  
> > v.in.ogr seems to not build topology of overlapping areas and then
> > v.rast.stats does not complain.  
> > >
> > > However, if one builds buffer areas for points within GRASS,
> > > i.e., using  
> > v.buffer, the problem appears again when buffer areas overlap,
> > which it's pretty common when creating buffers around neighbouring
> > points. Then, to get zonal stats for those areas the approach
> > suggested by Markus Metz should be followed. I believe it is a bit
> > of an overkill for such a common task in GIS. Couldn't v.buffer
> > have a -c flag as v.in.ogr so when overlapping of buffer areas is
> > fine the topology is not built and one would get just one area per
> > input point? Would that be possible?
> >
> > In short, no.
> >
> > The reason is that with a topological vector model, areas are
> > constructed from boundaries and centroids. If you use the -c flag
> > of v.in.ogr and there are polygons that overlap to a large degree
> > or completely, it is not possible to find a centroid for each
> > topological area, i.e. the overlapping input polygons can not be
> > properly represented with a topological model when using the -c
> > flag. As soon as you get incorrect boundaries and/or duplicate
> > centroids when building topology, results are wrong.
> >
> > Markus M
> >  
> > >
> > > cheers,
> > > Vero
> > >
> > >
> > >
> > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
> > mlenn...@club.worldonline.be>) escribió:  
> > >>
> > >> On 16/05/19 03:11, Veronica Andreo wrote:  
> > >> > Dear all,
> > >> >
> > >> > thanks for the answers...
> > >> >
> > >> > @Madi, I know, but that's how I got the data from a colleague
> > >> > using SaTScan to get cluster sizes.
> > >> >
> > >> > So, these "clusters" are 3, they are represented by circular
> > >> > areas  
> > and 2  
> > >> > of them overlap, and it is just fine that they overlap. I just
> > >> > want  
> > one  
> > >> > centroid per area to be able to get one value per original
> > >> > area.
> > >> >
> > >> > I tested your solution, @Micha (thanks much for your time!),
> > >> > but it gives me 4 values, and I need 3. Moreover, I can no
> > >> > longer recognize which polygon is which since v.db.select for
> > >> > layer 3 reports cats  
> > from 1  
> > >> > to 4, but d.vect shows something different (I'd assume 2/3 has
> > >> > become 4?). See screenshot below.  
> > >>
> > >> To see the cat values of layer 3 you have to indicate that layer
> > >> in the label_layer parameter (Labels tab).
> > >>
> > >> You can also see the correspondance between the two layers with
> > >>
> > >> v.category polys_3layers op=print layer=1,3
> > >>  
> > >> >
> > >> > So, is it possible somehow to keep my 3 original polygons? And
> > >> > how  
> > can I  
> > >> > get raster values for my original 3 polygons in GRASS? Or is
> > >> > it that this is not allowed by topology?  
> > >>
> > >> This depends on how you want to get raster values. If
> > >> v.what.rast at the location of the centroid is all you need than
> > >> Micha's solution should  
> > work.  
> > >>
> > >> If you need v.rast.stats then you either have to use Markus'
> > >> suggestion, or you use Micha's approach running v.rast.stats on
> > >> layer three and then use some magic to transform the output of
> > >> the above v.category call to a correspondance table between
> > >> layer. Something like this
> > >>
> > >> import grass.script as g
> > >> for feature in g.read_command('v.category',
> > >>   input_='polys_3layers',
> > >>   op='print',
> > >>layer=[3,1]).splitlines():
> > >>   cat1 = feature.split('|')[0]
> > >>   cats2 = feature.split('|')[1].split('/')
> > >>   for cat2 in cats2:
> > >>   print cat1, cat2
> > >>
> > >> This correspondance table could then be used to aggregate the
> > >> raster stats per (original) polygon in SQL. This could be the
> > >> easily put into an addon module.
> > >>
> > >> Moritz
> > >>  
> > > ___
> > > grass-user mailing list
> > > grass-user@lists.osgeo.org
> > > 

[GRASS-user] Average height over catchment in grass gis

[Rengifo Ortega]

Dear users  I am writting you here with the hope of getting some ideas about 
how to caculate what Kirsten Hennrich et al., refers to as average catchment 
height (Ha) I found this infomation in the proceedings of an international 
conference called regionalisation of hydrology. 
In page 184, he says that it is possible to calculate  Ha  using r.statistics 
in GRASS GIS (IAHS publication no. 254). 
I have been using sofar SAGA GIS to do the job.   But recently  I am  
experiencing some memory issues with SAGA GIS. In the old versions of  SAGA GIS 
 this calculation was named catchment height.  The new versions of SAGA GIS 
require that the user calculate  the mean over catchment  (MoC) first. 
Thereafter is MoC substrated from the original DTM. The product of this is the 
average catchment height or simply catchment height. 
Have someone in this group used GRASS GIS to calculate Catchment height in 
GRASS GIS. Any  hint will be appreciated.
Best regardsRengifo Ortega___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.what.vect never ends, SQLite warning

[Mehrdad Varedi]

Hi Everyone,
When I try v.what.vect on a point layer and the output of a v.voronoi,
after around an hour I begin getting the warnings that apparently are
because of an SQLite database lock.

This is not what happens with v.what.vect only.
When exporting the layer to shapefile or any other format it happens too.
The point layer is not very big. it has 275,000 records and each has 350
features (they are mostly double precision). The same happens with v.color
on this layer.

I have read feedback like, the SQLite doesn't like concurrent access on the
same table, although I have restarted the computer, run only grass or tried
to run it from R within GRASS and no other connection to that database
existed, although the process takes forever and I begin getting the warning
"Waiting for XXX seconds"

Do you know how can I accelerate the processing or make it work?

FYI, the CPU is not very busy more than 15-20% of its total capacity and
the memory of 16GB is usually half free. The writing on disk is very
minimal when it is working before the SQLite lock warning.

Kind regards,

Mehrdad

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

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Thanks for the help, Markus N. and Markus M. – Grass compiles and builds 
successfully with proj 5.2.0.

Cheers,

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 13:16
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn

Hi Eric,

On Wed, May 22, 2019 at 6:01 PM Patton, Eric (NRCan/RNCan) 
mailto:eric.pat...@canada.ca>> wrote:
>
> Thanks for that info. So would a suitable strategy be to try re-synching  
> Grass from git,

yes, with "git pull"

then compiling and building with proj 6.1, and if that fails, try the proj 
5.9.3 release?

As I wrote earlier, GRASS should now build with proj 6, but coordinate 
operations can produce wrong results.

proj-5.2.0 is the latest proj 5 release, GRASS is working with proj-5.2.0

Markus M

> ~ Eric.
>
>
>
> From: Markus Metz 
> mailto:markus.metz.gisw...@gmail.com>>
> Sent: May 22, 2019 12:57
> To: Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>>
> Cc: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>> wrote:
> >
> > Markus -
> >
> > Yes, I am using proj 6.0.0 – built with no errors.
>
>
>
> be aware that GRASS might compile with PROJ 6, but it is not working, too 
> much has changed from PROJ 5 and all those changes are not yet considered in 
> GRASS. Most importantly, coordinate transformations might produce wrong 
> results.
>
>
>
> Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+, 
> because of bug fixes and important new functionality.
>
> >
> > I believe I checked out master with ‘git clone 
> > https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be 
> > present in my source tree?
>
>
>
> It depends when you updated master the last time. If in doubt, git pull again.
>
>
>
> Markus M
>
>
>
> >
>
> >
> >
> > ~ Eric.
> >
> >
> >
> > From: Markus Metz 
> > mailto:markus.metz.gisw...@gmail.com>>
> > Sent: May 22, 2019 12:25
> > To: Markus Neteler mailto:nete...@osgeo.org>>
> > Cc: Patton, Eric (NRCan/RNCan) 
> > mailto:eric.pat...@canada.ca>>; 
> > grass-user@lists.osgeo.org
> > Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
> >
> >
> >
> >
> >
> > On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
> > mailto:nete...@osgeo.org>> wrote:
> > >
> > > Hi Eric,
> > >
> > > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> > > mailto:eric.pat...@canada.ca>> wrote:
> > > >
> > > > Hi Markus,
> > > >
> > > > I noted your new installation instructions for the git repo and have 
> > > > used those.
> > > >
> > > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > > >
> > > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > > -DRELDIR=\"lib/proj\" -o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > > do_proj.c: In function ‘GPJ_init_transform’:
> > > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > > >   else {
> > > >   ^~~~
> > > > do_proj.c: At top level:
> > > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL)
> > > >  ^~
> > > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL) {
> > > >  ^~
> > > > do_proj.c:167:15: error: 

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Veronica Andreo]

Hi Markus,

Thanks for the explanation. It is possible to import topologically
incorrect vectors, but not create them within GRASS. So, as a solution to
my problem, I rather create (potentially overlapping) buffers outside GRASS
and import them with -c in v.in.ogr to use v.rast.stats with no loss of
areas, or follow the procedure that you described earlier in the thread.

Cheers,
Vero

El mié., 22 may. 2019 a las 18:48, Markus Metz (<
markus.metz.gisw...@gmail.com>) escribió:

>
>
> On Wed, May 22, 2019 at 3:11 PM Veronica Andreo 
> wrote:
> >
> > Dear all,
> >
> > thanks again for your answers. I found an easier way, use -c flag in
> v.in.ogr seems to not build topology of overlapping areas and then
> v.rast.stats does not complain.
> >
> > However, if one builds buffer areas for points within GRASS, i.e., using
> v.buffer, the problem appears again when buffer areas overlap, which it's
> pretty common when creating buffers around neighbouring points. Then, to
> get zonal stats for those areas the approach suggested by Markus Metz
> should be followed. I believe it is a bit of an overkill for such a common
> task in GIS. Couldn't v.buffer have a -c flag as v.in.ogr so when
> overlapping of buffer areas is fine the topology is not built and one would
> get just one area per input point? Would that be possible?
>
> In short, no.
>
> The reason is that with a topological vector model, areas are constructed
> from boundaries and centroids. If you use the -c flag of v.in.ogr and there
> are polygons that overlap to a large degree or completely, it is not
> possible to find a centroid for each topological area, i.e. the overlapping
> input polygons can not be properly represented with a topological model
> when using the -c flag. As soon as you get incorrect boundaries and/or
> duplicate centroids when building topology, results are wrong.
>
> Markus M
>
> >
> > cheers,
> > Vero
> >
> >
> >
> > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
> mlenn...@club.worldonline.be>) escribió:
> >>
> >> On 16/05/19 03:11, Veronica Andreo wrote:
> >> > Dear all,
> >> >
> >> > thanks for the answers...
> >> >
> >> > @Madi, I know, but that's how I got the data from a colleague using
> >> > SaTScan to get cluster sizes.
> >> >
> >> > So, these "clusters" are 3, they are represented by circular areas
> and 2
> >> > of them overlap, and it is just fine that they overlap. I just want
> one
> >> > centroid per area to be able to get one value per original area.
> >> >
> >> > I tested your solution, @Micha (thanks much for your time!), but it
> >> > gives me 4 values, and I need 3. Moreover, I can no longer recognize
> >> > which polygon is which since v.db.select for layer 3 reports cats
> from 1
> >> > to 4, but d.vect shows something different (I'd assume 2/3 has become
> >> > 4?). See screenshot below.
> >>
> >> To see the cat values of layer 3 you have to indicate that layer in the
> >> label_layer parameter (Labels tab).
> >>
> >> You can also see the correspondance between the two layers with
> >>
> >> v.category polys_3layers op=print layer=1,3
> >>
> >> >
> >> > So, is it possible somehow to keep my 3 original polygons? And how
> can I
> >> > get raster values for my original 3 polygons in GRASS? Or is it that
> >> > this is not allowed by topology?
> >>
> >> This depends on how you want to get raster values. If v.what.rast at the
> >> location of the centroid is all you need than Micha's solution should
> work.
> >>
> >> If you need v.rast.stats then you either have to use Markus' suggestion,
> >> or you use Micha's approach running v.rast.stats on layer three and then
> >> use some magic to transform the output of the above v.category call to a
> >> correspondance table between layer. Something like this
> >>
> >> import grass.script as g
> >> for feature in g.read_command('v.category',
> >>   input_='polys_3layers',
> >>   op='print',
> >>layer=[3,1]).splitlines():
> >>   cat1 = feature.split('|')[0]
> >>   cats2 = feature.split('|')[1].split('/')
> >>   for cat2 in cats2:
> >>   print cat1, cat2
> >>
> >> This correspondance table could then be used to aggregate the raster
> >> stats per (original) polygon in SQL. This could be the easily put into
> >> an addon module.
> >>
> >> Moritz
> >>
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Markus Metz]

On Wed, May 22, 2019 at 3:11 PM Veronica Andreo 
wrote:
>
> Dear all,
>
> thanks again for your answers. I found an easier way, use -c flag in
v.in.ogr seems to not build topology of overlapping areas and then
v.rast.stats does not complain.
>
> However, if one builds buffer areas for points within GRASS, i.e., using
v.buffer, the problem appears again when buffer areas overlap, which it's
pretty common when creating buffers around neighbouring points. Then, to
get zonal stats for those areas the approach suggested by Markus Metz
should be followed. I believe it is a bit of an overkill for such a common
task in GIS. Couldn't v.buffer have a -c flag as v.in.ogr so when
overlapping of buffer areas is fine the topology is not built and one would
get just one area per input point? Would that be possible?

In short, no.

The reason is that with a topological vector model, areas are constructed
from boundaries and centroids. If you use the -c flag of v.in.ogr and there
are polygons that overlap to a large degree or completely, it is not
possible to find a centroid for each topological area, i.e. the overlapping
input polygons can not be properly represented with a topological model
when using the -c flag. As soon as you get incorrect boundaries and/or
duplicate centroids when building topology, results are wrong.

Markus M

>
> cheers,
> Vero
>
>
>
> El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
mlenn...@club.worldonline.be>) escribió:
>>
>> On 16/05/19 03:11, Veronica Andreo wrote:
>> > Dear all,
>> >
>> > thanks for the answers...
>> >
>> > @Madi, I know, but that's how I got the data from a colleague using
>> > SaTScan to get cluster sizes.
>> >
>> > So, these "clusters" are 3, they are represented by circular areas and
2
>> > of them overlap, and it is just fine that they overlap. I just want one
>> > centroid per area to be able to get one value per original area.
>> >
>> > I tested your solution, @Micha (thanks much for your time!), but it
>> > gives me 4 values, and I need 3. Moreover, I can no longer recognize
>> > which polygon is which since v.db.select for layer 3 reports cats from
1
>> > to 4, but d.vect shows something different (I'd assume 2/3 has become
>> > 4?). See screenshot below.
>>
>> To see the cat values of layer 3 you have to indicate that layer in the
>> label_layer parameter (Labels tab).
>>
>> You can also see the correspondance between the two layers with
>>
>> v.category polys_3layers op=print layer=1,3
>>
>> >
>> > So, is it possible somehow to keep my 3 original polygons? And how can
I
>> > get raster values for my original 3 polygons in GRASS? Or is it that
>> > this is not allowed by topology?
>>
>> This depends on how you want to get raster values. If v.what.rast at the
>> location of the centroid is all you need than Micha's solution should
work.
>>
>> If you need v.rast.stats then you either have to use Markus' suggestion,
>> or you use Micha's approach running v.rast.stats on layer three and then
>> use some magic to transform the output of the above v.category call to a
>> correspondance table between layer. Something like this
>>
>> import grass.script as g
>> for feature in g.read_command('v.category',
>>   input_='polys_3layers',
>>   op='print',
>>layer=[3,1]).splitlines():
>>   cat1 = feature.split('|')[0]
>>   cats2 = feature.split('|')[1].split('/')
>>   for cat2 in cats2:
>>   print cat1, cat2
>>
>> This correspondance table could then be used to aggregate the raster
>> stats per (original) polygon in SQL. This could be the easily put into
>> an addon module.
>>
>> Moritz
>>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

Hi Eric,

On Wed, May 22, 2019 at 6:01 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
>
> Thanks for that info. So would a suitable strategy be to try re-synching
 Grass from git,

yes, with "git pull"

then compiling and building with proj 6.1, and if that fails, try the proj
5.9.3 release?

As I wrote earlier, GRASS should now build with proj 6, but coordinate
operations can produce wrong results.

proj-5.2.0 is the latest proj 5 release, GRASS is working with proj-5.2.0

Markus M

> ~ Eric.
>
>
>
> From: Markus Metz 
> Sent: May 22, 2019 12:57
> To: Patton, Eric (NRCan/RNCan) 
> Cc: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
> >
> > Markus -
> >
> > Yes, I am using proj 6.0.0 – built with no errors.
>
>
>
> be aware that GRASS might compile with PROJ 6, but it is not working, too
much has changed from PROJ 5 and all those changes are not yet considered
in GRASS. Most importantly, coordinate transformations might produce wrong
results.
>
>
>
> Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+,
because of bug fixes and important new functionality.
>
> >
> > I believe I checked out master with ‘git clone
https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be
present in my source tree?
>
>
>
> It depends when you updated master the last time. If in doubt, git pull
again.
>
>
>
> Markus M
>
>
>
> >
>
> >
> >
> > ~ Eric.
> >
> >
> >
> > From: Markus Metz 
> > Sent: May 22, 2019 12:25
> > To: Markus Neteler 
> > Cc: Patton, Eric (NRCan/RNCan) ;
grass-user@lists.osgeo.org
> > Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
> >
> >
> >
> >
> >
> > On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
wrote:
> > >
> > > Hi Eric,
> > >
> > > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> > >  wrote:
> > > >
> > > > Hi Markus,
> > > >
> > > > I noted your new installation instructions for the git repo and
have used those.
> > > >
> > > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > > >
> > > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > > do_proj.c: In function ‘GPJ_init_transform’:
> > > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > > >   else {
> > > >   ^~~~
> > > > do_proj.c: At top level:
> > > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL)
> > > >  ^~
> > > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL) {
> > > >  ^~
> > > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > > >  info_trans->meters = 1.;
> > > >^~
> > > > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > > >  info_trans->zone = 0;
> > > >^~
> > > > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> > > >  sprintf(info_trans->proj, "pipeline");
> > > >^~
> > > > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> > > >  return 1;
> > > >  ^~
> > > > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> > > >  }
> > > >  ^
> > > > ../../include/Make/Compile.make:32: recipe for target
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > > > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > > > make: *** Waiting 

Re: [GRASS-user] r.contour contour wrap

[Mark Seibel]

just FYI.

I am (was?) using 7.6 and had errors with r.contour outputs (linux mint).
Output lines would be broken in areas there was good DEM data. The lines
had large gaps between some isolines where other software could make clean
contour from the DEM.

I downloaded and compiled 7.7 and works great.

On Thu, May 3, 2018 at 4:29 PM Markus Neteler  wrote:

> On Thu, May 3, 2018 at 10:17 PM, Markus Metz
>  wrote:
> > On Tue, May 1, 2018 at 9:57 PM, Markus Metz <
> markus.metz.gisw...@gmail.com>
> > wrote:
> ...
> > Thanks for providing test data! There was indeed a bug in r.contour,
> fixed
> > in trunk r72668. Is it OK to backport the bugix to GRASS 7.4 and 7.2?
>
> ... in terms of backport policy definitely yes.
>
> markusN
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Thanks for that info. So would a suitable strategy be to try re-synching  Grass 
from git, then compiling and building with proj 6.1, and if that fails, try the 
proj 5.9.3 release?

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 12:57
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn



On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) 
mailto:eric.pat...@canada.ca>> wrote:
>
> Markus -
>
> Yes, I am using proj 6.0.0 – built with no errors.

be aware that GRASS might compile with PROJ 6, but it is not working, too much 
has changed from PROJ 5 and all those changes are not yet considered in GRASS. 
Most importantly, coordinate transformations might produce wrong results.

Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+, 
because of bug fixes and important new functionality.
>
> I believe I checked out master with ‘git clone 
> https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be 
> present in my source tree?

It depends when you updated master the last time. If in doubt, git pull again.

Markus M

>
>
>
> ~ Eric.
>
>
>
> From: Markus Metz 
> mailto:markus.metz.gisw...@gmail.com>>
> Sent: May 22, 2019 12:25
> To: Markus Neteler mailto:nete...@osgeo.org>>
> Cc: Patton, Eric (NRCan/RNCan) 
> mailto:eric.pat...@canada.ca>>; 
> grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
> mailto:nete...@osgeo.org>> wrote:
> >
> > Hi Eric,
> >
> > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> > mailto:eric.pat...@canada.ca>> wrote:
> > >
> > > Hi Markus,
> > >
> > > I noted your new installation instructions for the git repo and have used 
> > > those.
> > >
> > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > >
> > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
> > > -I/usr/local/include -DPACKAGE=\""grasslibs"\"   
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > > -o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > do_proj.c: In function ‘GPJ_init_transform’:
> > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > >   else {
> > >   ^~~~
> > > do_proj.c: At top level:
> > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL)
> > >  ^~
> > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL) {
> > >  ^~
> > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > > before ‘->’ token
> > >  info_trans->meters = 1.;
> > >^~
> > > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > > before ‘->’ token
> > >  info_trans->zone = 0;
> > >^~
> > > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> > >  sprintf(info_trans->proj, "pipeline");
> > >^~
> > > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> > >  return 1;
> > >  ^~
> > > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> > >  }
> > >  ^
> > > ../../include/Make/Compile.make:32: recipe for target 
> > > 'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > > make: *** Waiting for unfinished jobs
> >
> > ok, there seems to be a problem with the PROJ installation.
>
>
>
> No, it's a problem with the #ifdef's 

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
>
> Markus -
>
> Yes, I am using proj 6.0.0 – built with no errors.

be aware that GRASS might compile with PROJ 6, but it is not working, too
much has changed from PROJ 5 and all those changes are not yet considered
in GRASS. Most importantly, coordinate transformations might produce wrong
results.

Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+,
because of bug fixes and important new functionality.
>
> I believe I checked out master with ‘git clone
https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be
present in my source tree?

It depends when you updated master the last time. If in doubt, git pull
again.

Markus M

>
>
>
> ~ Eric.
>
>
>
> From: Markus Metz 
> Sent: May 22, 2019 12:25
> To: Markus Neteler 
> Cc: Patton, Eric (NRCan/RNCan) ;
grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 4:39 PM Markus Neteler  wrote:
> >
> > Hi Eric,
> >
> > On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> >  wrote:
> > >
> > > Hi Markus,
> > >
> > > I noted your new installation instructions for the git repo and have
used those.
> > >
> > > The first error in error.log occurs in /usr/local/grass/lib/proj:
> > >
> > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > do_proj.c: In function ‘GPJ_init_transform’:
> > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > >   else {
> > >   ^~~~
> > > do_proj.c: At top level:
> > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL)
> > >  ^~
> > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL) {
> > >  ^~
> > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > >  info_trans->meters = 1.;
> > >^~
> > > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > >  info_trans->zone = 0;
> > >^~
> > > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> > >  sprintf(info_trans->proj, "pipeline");
> > >^~
> > > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> > >  return 1;
> > >  ^~
> > > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> > >  }
> > >  ^
> > > ../../include/Make/Compile.make:32: recipe for target
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > > make: *** Waiting for unfinished jobs
> >
> > ok, there seems to be a problem with the PROJ installation.
>
>
>
> No, it's a problem with the #ifdef's in do_proj.c accounting for
different versions of PROJ
>
> >
>
> > Which proj version do you use? Please post the names of the related
> > packages here which you have installed (so that we see the precise
> > version names).
>
>
>
> This must be PROJ 6.
>
>
>
> do_proj.c should be fixed in master 7c3e8de:
>
>
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f
>
>
>
> Markus M
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Markus -

Yes, I am using proj 6.0.0 – built with no errors.

I believe I checked out master with ‘git clone 
https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be present 
in my source tree?

~ Eric.

From: Markus Metz 
Sent: May 22, 2019 12:25
To: Markus Neteler 
Cc: Patton, Eric (NRCan/RNCan) ; 
grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn



On Wed, May 22, 2019 at 4:39 PM Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> mailto:eric.pat...@canada.ca>> wrote:
> >
> > Hi Markus,
> >
> > I noted your new installation instructions for the git repo and have used 
> > those.
> >
> > The first error in error.log occurs in /usr/local/grass/lib/proj:
> >
> > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> > -DPACKAGE=\""grasslibs"\"   
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> > -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" 
> > -o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > do_proj.c: In function ‘GPJ_init_transform’:
> > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> >   else {
> >   ^~~~
> > do_proj.c: At top level:
> > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL)
> >  ^~
> > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL) {
> >  ^~
> > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > before ‘->’ token
> >  info_trans->meters = 1.;
> >^~
> > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> > before ‘->’ token
> >  info_trans->zone = 0;
> >^~
> > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> >  sprintf(info_trans->proj, "pipeline");
> >^~
> > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> >  return 1;
> >  ^~
> > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> >  }
> >  ^
> > ../../include/Make/Compile.make:32: recipe for target 
> > 'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > make: *** Waiting for unfinished jobs
>
> ok, there seems to be a problem with the PROJ installation.

No, it's a problem with the #ifdef's in do_proj.c accounting for different 
versions of PROJ
>
> Which proj version do you use? Please post the names of the related
> packages here which you have installed (so that we see the precise
> version names).

This must be PROJ 6.

do_proj.c should be fixed in master 7c3e8de:
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f

Markus M

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

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

On Wed, May 22, 2019 at 4:39 PM Markus Neteler  wrote:
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
>  wrote:
> >
> > Hi Markus,
> >
> > I noted your new installation instructions for the git repo and have
used those.
> >
> > The first error in error.log occurs in /usr/local/grass/lib/proj:
> >
> > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > do_proj.c: In function ‘GPJ_init_transform’:
> > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> >   else {
> >   ^~~~
> > do_proj.c: At top level:
> > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL)
> >  ^~
> > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL) {
> >  ^~
> > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> >  info_trans->meters = 1.;
> >^~
> > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> >  info_trans->zone = 0;
> >^~
> > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> >  sprintf(info_trans->proj, "pipeline");
> >^~
> > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> >  return 1;
> >  ^~
> > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> >  }
> >  ^
> > ../../include/Make/Compile.make:32: recipe for target
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > make: *** Waiting for unfinished jobs
>
> ok, there seems to be a problem with the PROJ installation.

No, it's a problem with the #ifdef's in do_proj.c accounting for different
versions of PROJ
>
> Which proj version do you use? Please post the names of the related
> packages here which you have installed (so that we see the precise
> version names).

This must be PROJ 6.

do_proj.c should be fixed in master 7c3e8de:
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f

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

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Neteler]

Hi Eric,

On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
 wrote:
>
> Hi Markus,
>
> I noted your new installation instructions for the git repo and have used 
> those.
>
> The first error in error.log occurs in /usr/local/grass/lib/proj:
>
> test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> -DPACKAGE=\""grasslibs"\"   
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
> OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> -DPACKAGE=\""grasslibs"\"   
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
> OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> -DPACKAGE=\""grasslibs"\"   
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
> OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
> -DPACKAGE=\""grasslibs"\"   
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
> -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
> OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> do_proj.c: In function ‘GPJ_init_transform’:
> do_proj.c:136:6: error: expected ‘}’ before ‘else’
>   else {
>   ^~~~
> do_proj.c: At top level:
> do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
>  if (info_trans->pj == NULL)
>  ^~
> do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
>  if (info_trans->pj == NULL) {
>  ^~
> do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> before ‘->’ token
>  info_trans->meters = 1.;
>^~
> do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
> before ‘->’ token
>  info_trans->zone = 0;
>^~
> do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
>  sprintf(info_trans->proj, "pipeline");
>^~
> do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
>  return 1;
>  ^~
> do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
>  }
>  ^
> ../../include/Make/Compile.make:32: recipe for target 
> 'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> make: *** Waiting for unfinished jobs

ok, there seems to be a problem with the PROJ installation.

Which proj version do you use? Please post the names of the related
packages here which you have installed (so that we see the precise
version names).

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

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Patton, Eric (NRCan/RNCan)]

Hi Markus,

I noted your new installation instructions for the git repo and have used 
those. 

The first error in error.log occurs in /usr/local/grass/lib/proj:
 
test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include 
-DPACKAGE=\""grasslibs"\"   -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include 
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\" -o 
OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
do_proj.c: In function ‘GPJ_init_transform’:
do_proj.c:136:6: error: expected ‘}’ before ‘else’
  else {
  ^~~~
do_proj.c: At top level:
do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
 if (info_trans->pj == NULL)
 ^~
do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
 if (info_trans->pj == NULL) {
 ^~
do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘->’ token
 info_trans->meters = 1.;
   ^~
do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘->’ token
 info_trans->zone = 0;
   ^~
do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
 sprintf(info_trans->proj, "pipeline");
   ^~
do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
 return 1;
 ^~
do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
 }
 ^
../../include/Make/Compile.make:32: recipe for target 
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
make: *** Waiting for unfinished jobs

Thanks,

~ Eric.




-Original Message-
From: Markus Neteler  
Sent: May 21, 2019 16:49
To: Patton, Eric (NRCan/RNCan) 
Cc: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn

Hi Eric,

On Tue, May 21, 2019 at 6:00 PM Patton, Eric (NRCan/RNCan) 
 wrote:
...
> I was running Grass 7.7svn (trunk) fine last week, and updated to v74509 
> today on Linux Mint 19.1.

We just moved to GitHub:

git clone https://github.com/OSGeo/grass.git

However, a question:

> No errors during configure, but make showed many errors of the type:
>
> Error: /usr/lib/gcc/x86_64-linux-gnu/7/include/xmmintrin.h:120: Syntax error 
> at '{'

I guess that these error messages appear in the ctypes part which is
(unfortunately) "normal" and apparently not an issue.
...

> There’s far too many errors to list here, but the result of it is that 221 
> grass modules fail to build.

Which is the first one listed in
error.log
?

Can you then cd into that directory, run "make" therein and report the error?

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

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Veronica Andreo]

Dear all,

thanks again for your answers. I found an easier way, use -c flag in
v.in.ogr seems to not build topology of overlapping areas and then
v.rast.stats does not complain.

However, if one builds buffer areas for points within GRASS, i.e., using
v.buffer, the problem appears again when buffer areas overlap, which it's
pretty common when creating buffers around neighbouring points. Then, to
get zonal stats for those areas the approach suggested by Markus Metz
should be followed. I believe it is a bit of an overkill for such a common
task in GIS. Couldn't v.buffer have a -c flag as v.in.ogr so when
overlapping of buffer areas is fine the topology is not built and one would
get just one area per input point? Would that be possible?

cheers,
Vero



El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
mlenn...@club.worldonline.be>) escribió:

> On 16/05/19 03:11, Veronica Andreo wrote:
> > Dear all,
> >
> > thanks for the answers...
> >
> > @Madi, I know, but that's how I got the data from a colleague using
> > SaTScan to get cluster sizes.
> >
> > So, these "clusters" are 3, they are represented by circular areas and 2
> > of them overlap, and it is just fine that they overlap. I just want one
> > centroid per area to be able to get one value per original area.
> >
> > I tested your solution, @Micha (thanks much for your time!), but it
> > gives me 4 values, and I need 3. Moreover, I can no longer recognize
> > which polygon is which since v.db.select for layer 3 reports cats from 1
> > to 4, but d.vect shows something different (I'd assume 2/3 has become
> > 4?). See screenshot below.
>
> To see the cat values of layer 3 you have to indicate that layer in the
> label_layer parameter (Labels tab).
>
> You can also see the correspondance between the two layers with
>
> v.category polys_3layers op=print layer=1,3
>
> >
> > So, is it possible somehow to keep my 3 original polygons? And how can I
> > get raster values for my original 3 polygons in GRASS? Or is it that
> > this is not allowed by topology?
>
> This depends on how you want to get raster values. If v.what.rast at the
> location of the centroid is all you need than Micha's solution should work.
>
> If you need v.rast.stats then you either have to use Markus' suggestion,
> or you use Micha's approach running v.rast.stats on layer three and then
> use some magic to transform the output of the above v.category call to a
> correspondance table between layer. Something like this
>
> import grass.script as g
> for feature in g.read_command('v.category',
>   input_='polys_3layers',
>   op='print',
>layer=[3,1]).splitlines():
>   cat1 = feature.split('|')[0]
>   cats2 = feature.split('|')[1].split('/')
>   for cat2 in cats2:
>   print cat1, cat2
>
> This correspondance table could then be used to aggregate the raster
> stats per (original) polygon in SQL. This could be the easily put into
> an addon module.
>
> Moritz
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user