Re: [GRASS-dev] Untangling geoPAT installation when updating GRASS version

[Vaclav Petras]

Dear all,

this may not address this specific problem with multiple installations, but
it may help overall with debugging such problems because it is more direct.
I'm attaching a geoPAT patch which deals with the names of the libraries
and removes the need to modify GRASS source code before the compilation
happens.

The following command executed in the directory with the source code should
be sufficient to compile modules with a self-compiled GRASS which is not in
system:

make MODULE_TOPDIR=~/.../trunk/ GRASS_VERSION_NUMBER=7.5.svn

Path to the GRASS GIS installation/code/dev files and the version needs to
be provided. This was tested with the current trunk in a home directory and
not with GRASS installed (`make install`-ed) in the system. Nevertheless
this removes the need to modify the source code and thus increasing
compatibility with different GRASS versions (which change the copied and
modified file).

Besides the limited testing, there are three other issues:

1) g.extension is not able to install the code from a directory (or ZIP,
...) because no system for C addon modules with libraries is in place (same
issue as with r.pi.* suite). When GRASS_VERSION_NUMBER is added to
g.extension code and HTML for the main directory is resolved/or ignored in
g.extension, modules at least compile, but nothing is installed (added) to
the local addons directory.

2) I don't understand why GRASS_VERSION_NUMBER isn't already defined.

3) I don't know how to contribute to the geoPAT repository.

Best,
Vaclav



On Fri, Feb 23, 2018 at 6:22 PM, Dylan Beaudette 
wrote:

> How about your GRASS "development" files: installed via package
> manager? Same version as the binaries?
>
> D
>
> On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier
>  wrote:
> > Thanks Dylan,
> >
> > I did install using `sudo sh install.sh grass72` -- then `sudo sh
> install.sh
> > grass74` after my Grass version got updated to 7.4
> >
> > Cheers,
> >
> > P
> >
> > On 23 February 2018 at 18:41, Dylan Beaudette  >
> > wrote:
> >>
> >> Howdy Pierre!
> >>
> >> In my experience, the GeoPat modules need to know where several things
> >> are located, including (I think) parts of the GRASS source code. Have
> >> a look through the install.sh code:
> >>
> >> http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh
> >>
> >> I was able to get these modules up and running by invoking install.sh
> like
> >> this:
> >>
> >> sh install.sh grass75
> >>
> >> ... where "grass75" is the binary compiled from grass_trunk. The
> >> install.sh code seemed to find the source code it needed and worked
> >> without issue.
> >>
> >> How did you install / upgrade the Geopat modules? Could it be that
> >> install.sh is "finding" the old source code / headers? Is there a
> >> package for both GRASS binaries and development files?
> >>
> >> Dylan
> >>
> >>
> >> On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier
> >>  wrote:
> >> > Hi,
> >> >
> >> > I've been compiling the geoPAT extensions for GRASS from
> >> > http://sil.uc.edu/gitlist/geoPAT/
> >> >
> >> > At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS
> >> > repository, but since this repo updated to GRASS 7.4, I have the
> >> > following
> >> > issue:
> >> >
> >> > GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help
> >> > ERROR: Module built against version $Revision: 70617 $ but trying to
> use
> >> >version $Revision: 70829 $. You need to rebuild GRASS GIS or
> >> >untangle multiple installations.
> >> > [Raster MASK present]
> >> >
> >> > Any pointers about how to resolve the version tangling? I've tried
> >> > recompiling geoPAT, but that didn't work.
> >> >
> >> > Cheers,
> >> >
> >> > Pierre
> >> >
> >> > ___
> >> > 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
>
diff -urN geoPAT-3a75addf/p.sig.grid/Makefile geoPAT/p.sig.grid/Makefile
--- geoPAT-3a75addf/p.sig.grid/Makefile 2016-03-05 01:15:31.0 -0500
+++ geoPAT/p.sig.grid/Makefile  2018-02-24 20:16:32.576234715 -0500
@@ -2,6 +2,8 @@
 
 PGM=p.sig.grid
 
+include ../similarlib/Similar.make
+
 LIBES = $(SIMILARLIB) $(GPROJLIB) $(RASTERLIB) $(GISLIB) $(MATHLIB) 
 DEPENDENCIES = $(SIMILARDEP) $(GPROJDEP) $(RASTERDEP) $(GISDEP) 
 EXTRA_INC = $(PROJINC)
diff -urN geoPAT-3a75addf/p.sig.points/Makefile geoPAT/p.sig.points/Makefile
--- geoPAT-3a75addf/p.sig.points/Makefile   2016-03-05 01:15:31.0 
-0500
+++ geoPAT/p.sig.points/Makefile2018-02-24 20:16:27.336234588 -0500
@@ -2,6 +2,8 @@
 
 PGM = p.sig.points
 
+include ../similarlib/Similar.make
+
 LIBES = $(SIMILARLIB) $(RASTERLIB) $(GISLIB) $(MATHLIB) $(VECTORLIB) $(DBMILIB)
 DEPENDENCIES 

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[GRASS GIS]

#2757: r.import: ERROR: Input raster map is outside current region
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.4.0
 Component:  Python  |Version:  svn-releasebranch74
Resolution:  fixed   |   Keywords:  r.import, r.in.gdal, r.external,
   CPU:  |  r.region
  Unspecified|   Platform:  All
-+-
Changes (by neteler):

 * status:  reopened => closed
 * version:  svn-trunk => svn-releasebranch74
 * resolution:   => fixed
 * milestone:  7.0.6 => 7.4.0


Comment:

 Checking this ticket with GRASS GIS 7.4:

 {{{
 # Fedora box
 GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > g.version -ger
 version=7.4.1svn
 date=2018
 revision=r72180
 build_date=2018-01-28
 build_platform=x86_64-pc-linux-gnu
 build_off_t_size=8
 libgis_revision=70829
 libgis_date="2017-04-04 09:43:02 +0200 (Tue, 04 Apr 2017) "
 proj4=4.9.3
 gdal=2.1.3
 geos=3.6.1
 sqlite=3.20.1
 }}}


 Test in Long-Lat:

 {{{
 GRASS 7.4.1svn (latlong_wgs84):/scratch > r.import input=bio1.bil
 output=bioclim1
 90 degree north is exceeded by 6.82121e-13 cells
 Importing raster map ...
  100%
 GRASS 7.4.1svn (latlong_wgs84):/scratch > g.region raster=bioclim1 -p
 projection: 3 (Latitude-Longitude)
 zone:   0
 datum:  wgs84
 ellipsoid:  wgs84
 north:  90N
 south:  60S
 west:   180W
 east:   180E
 nsres:  0:02:30
 ewres:  0:02:30
 rows:   3600
 cols:   8640
 cells:  31104000

 GRASS 7.4.1svn (latlong_wgs84):/scratch > g.region raster=bioclim1 -g
 projection=3
 zone=0
 n=90
 s=-60
 w=-180
 e=180
 nsres=0.0417
 ewres=0.0417
 rows=3600
 cols=8640
 cells=31104000
 }}}

 Test in NC sample dataset location:

 {{{
 GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > r.import input=bio1.bil
 output=bioclim1 resample=bilinear extent=region resolution=region
 WARNING: Projection of dataset does not appear to match current location.

  Location PROJ_INFO is:
  name: Lambert Conformal Conic
  proj: lcc
  datum: nad83
  a: 6378137.0
  es: 0.006694380022900787
  lat_1: 36.16
  lat_2: 34.34
  lat_0: 33.75
  lon_0: -79
  x_0: 609601.22
  y_0: 0
  no_defs: defined

  Dataset PROJ_INFO is:
  name: WGS 84
  datum: wgs84
  ellps: wgs84
  proj: ll
  no_defs: defined

  ERROR: proj

  In case of no significant differences in the projection
  definitions, use the -o flag to ignore them and use current
  location definition.
  Consider generating a new location from the input dataset using
  the 'location' parameter.
 90 degree north is exceeded by 6.82121e-13 cells
 Importing raster map ...
  100%
 Estimated target resolution for input band : 4021.78765331
 Using current region resolution for input band : nsres=500.0,
 ewres=500.0
 Reprojecting ...

 GRASS 7.4.1svn (nc_basic_spm_grass7):/scratch > g.region -p
 raster=bioclim1
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  32
 south:  1
 west:   12
 east:   935000
 nsres:  500
 ewres:  500
 rows:   620
 cols:   1630
 cells:  1010600
 }}}

 (the "ERROR: proj" is a bit disturbing as a message, since using r.import)

 It looks ok to me - thanks for the hard work esp. by Markus Metz on
 improving the global data import and treatment of global data with
 coordinate precision issues!

 Closing, this improvement is part of the recently published GRASS GIS
 7.4.0.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Future of external Processing providers in QGIS

[Vaclav Petras]

Thank you, Paolo, for the summary. It was great to be part of the meeting!

On Fri, Feb 23, 2018 at 9:26 AM, Paolo Cavallini 
wrote:

> Hi all,
> meeting has just ended. I must say it was a very interesting and
> productive discussion. We are really grateful for the developers from
> GRASS, SAGA and OTB for their contributions to our discussion.
> I recap briefly here what I believe are the most important outcomes:
> * we'll keep SAGA and GRASS Processing providers
> * we'll try to update SAGA provider to the next LTR when this will be
> available
> * we invite OTB team to add their work to QGIS core, granting them write
> access if they wish
> * for OTB provider, considering that OTB binaries are not part of the
> installer on Windows, we suggest this approach: OTB provider checks
> whether OTB is installed, if not it suggests the user to install it, if
> the user does not the provider hides itself
> * While we have granted an exception to the ‘processing providers should
> not be in core’ for the short term, our longer term plan is to put in
> place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).
> When this capability is implemented, we will mandate that all providers
> will be provided as plugins and then fetch these plugins on demand if an
> algorithm references them
> * we will not accept new providers, unless some very strict and
> exceptional conditions apply (TBD; e.g. new backend of high quality and
> general usage)
> * for future versions we will consider moving providers to the XML
> approach where appropriate, as it appears more maintainable, even at the
> expense of flexibility in interface tuning; GRASS is the next candidate,
> noting that this might require some modifications in GRASS core
> * as a first step in we ask anybody to test thoroughly the new SAGA
> provider by Alex Bruy
> https://github.com/alexbruy/processing-saga
> also a check from SAGA, GRASS, and OTB devs would be important, to check
> whether this approach is the preferred one from all sides.
> Please add if I missed something.
> Overall, I think we have now a brighter future for Processing, and as a
> consequence for QGIS, SAGA, GRASS and OTB altogether.
> * If you want to watch the complete discussion, please be patient; video
> is being uploaded.
> All the best, and thanks again.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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] #789: g.region option to expand the computational region of about "some" pixels?

[GRASS GIS]

#789: g.region option to expand the computational region of about "some" pixels?
-+-
  Reporter:  nikos   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.4.1
 Component:  Default |Version:  unspecified
Resolution:  |   Keywords:  g.region, expand computational
   CPU:  |  region
  Unspecified|   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 I am out of the loop here. `g.region pixels=1` goes from

 {{{
 rows:   1193
 cols:   981
 }}}
 to
 {{{
 rows:   1195
 cols:   983
 }}}

 This means expansion, by the given number of `pixels=1` in all directions.
 It works for me, thank you.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Future of external Processing providers in QGIS

[Paolo Cavallini]

Hi all,

video link here:
https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira2018#future-of-processing-providers

All the best.
===
* If you want to watch the complete discussion, please be patient; video
is being uploaded.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev