Re: [GRASS-dev] [GRASS GIS] #3091: The RUN_GISBASE variable is not set correctly on FreeBSD

[GRASS GIS]

#3091: The RUN_GISBASE variable is not set correctly on FreeBSD
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Default  |Version:  7.0.4
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by lbartoletti):

 Hi,

 You can close this tickets, we have
 [https://trac.osgeo.org/grass/ticket/2940 patched files] for FreeBSD.

 Regards.

--
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.2
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by lbartoletti):

 Hello,

 Good news, it's works! :)
 
[[Image(https://raw.githubusercontent.com/lbartoletti/grass7/master/grass_freebsd.png)]]

 There was an error in the configuration for the package and also some
 grass' files need to be patched.

 After the review, the FreeBSD package will be available soon!

 You can close this ticket.

 Thanks.

--
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 Mac compiling - cairo problems

[Michael Barton]

I solved it. I typo in the configure string. Thanks.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Jul 26, 2017, at 6:26 PM, Vaclav Petras 
> wrote:



On Wed, Jul 26, 2017 at 7:10 PM, Michael Barton 
> wrote:

But fontconfig.h is IN the directory I've pointed to in the 
--with-cairo-includes= statement.

Here is my configure script:

./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.8.sdk --with-freetype 
--with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include/ 
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config 
--with-gdal-libs=/Library/Frameworks/GDAL.framework/Libraries --with-proj 
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config 
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-cairo --with-cairo-includes=/Library/Frameworks/cairo.framework/Headers/ 
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
--with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-sqlite

...

Finished compilation: Wed Jul 26 17:02:45 MDT 2017
make: *** [default] Error 1
CMB-MacBook-Pro:releasebranch_7_2 cmbarton$ cd 
/Users/cmbarton/grass_source/releasebranch_7_2/lib/cairodriver
CMB-MacBook-Pro:cairodriver cmbarton$ make
gcc  -g -O2   -arch i386 -isysroot /Developer/SDKs/MacOSX10.8.sdk -fno-common  
-I/Users/cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
 
-I/Users/cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
   -I../driver -I/Library/Frameworks/cairo.framework/Headers/ 
-I/Library/Frameworks/FreeType.framework/unix/include/ 
-DPACKAGE=\""grasslibs"\"   
-I/Users/cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
 
-I/Users/cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
 -DRELDIR=\"lib/cairodriver\" -o OBJ.x86_64-apple-darwin16.7.0/text.o -c text.c
text.c:20:10: fatal error: 'fontconfig/fontconfig.h' file not found
#include 
 ^
1 error generated.
make: *** [OBJ.x86_64-apple-darwin16.7.0/text.o] Error 1


Hi Michael,

As far as I understand, compiler simply looks at all directories specified by 
-I (which are configured by ./configure) and pastes the -I path and the path in 
#include together and tests if the file exists. So I would first double check:

ls /Library/Frameworks/cairo.framework/Headers/
ls /Library/Frameworks/cairo.framework/Headers/fontconfig/fontconfig.h

Vaclav

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

Re: [GRASS-dev] Adding hexagonal rasters to GRASS

[Vaclav Petras]

On Mon, Jul 24, 2017 at 11:16 AM, Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:

> - In theory, all raster modules can function in exactly the same way with
> both square and hexagons if all geometric and neighbourhood
> methods/properties/functions are abstracted correctly.
>
> - The risk here is breaking the existing r. modules by implementing the
> raster abstraction. Perhaps some sort of transition may be devised to avoid
> it
>

> - On my side, the next step is to dive into the code and study how
> practical these ideas may be. But please put forward your ideas in any case.
>

For start, I suggest implementing some prototypes from stretch rather than
rewriting/adopting existing code. Probably a conversion or visualization
module makes sense so that we can see the results. I'm sure you have much
better about this than I since you already went through that before.

I suggest that the modules store the hexagon map (maybe a correct name in
GRASS?) in raster map with some metadata on the side. I would ignore the
problem that a raster map which (perhaps) does not make any sense (for
raster modules) is created. The metadata may be stored in just in the
current directory (in future, they would go to the GRASS database).

You would need to use functions to modify computational region inside the
module to be able to store it properly (e.g. r.in.lidar modifies the
computational region for itself when -e flag is used). Standard way of
doing this is in C, but Python works as well and may be much simpler
(either through PyGRASS or ctypes directly). Importantly, this can be done
without changing the library or existing modules, so you can do any
experiments you want (e.g. in GRASS Addons, GRASS Sandbox or on GitHub).

Talking just about how this prototype could be implemented, here is an
example of user interaction and the results (the names are not final,
r.hex.to.rast would probably become h.to.rast in the future):

GRASS > g.list rast m=.
a_raster

GRASS > r.info raster_1 -g
...
res=2
...

GRASS > g.region raster=raster_1

GRASS > r.to.hex input=raster_1 output=hexagons

GRASS > g.list rast m=.
raster_1
hexagons

GRASS > r.info hexagon
something very unexpected here for the user
number of cells and perhaps even extent does not fit

GRASS > r.hex.info
raster hexagon processed as hexagons
output about hexagonal grid
(information from the raster and metadata on the side combined)

GRASS > r.hex.waterflow input=hexagons output=hexagonal_flow

GRASS > g.list rast m=.
raster_1
hexagons
hexagonal_flow

GRASS > g.list.hex m=.
hexagons
hexagonal_flow

GRASS > g.region res=0.1  # note much lower resolution

GRASS > r.hex.to.rast input=hexagonal_flow output=raster_2

GRASS > d.rast raster_2
no we see the hexagons because we oversampled them
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Mac compiling - cairo problems

[Vaclav Petras]

On Wed, Jul 26, 2017 at 7:10 PM, Michael Barton 
wrote:

>
> But fontconfig.h is IN the directory I've pointed to in the
> --with-cairo-includes= statement.
>
> Here is my configure script:
>
> ./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.8.sdk
> --with-freetype 
> --with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include/
> --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
> --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
> --with-gdal-libs=/Library/Frameworks/GDAL.framework/Libraries --with-proj
> --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include
> --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
> --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
> --with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config
> --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include
> --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
> --with-cairo 
> --with-cairo-includes=/Library/Frameworks/cairo.framework/Headers/
> --with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib
> --with-cairo-ldflags="-lcairo" --without-postgres --without-mysql
> --with-sqlite
>

...


> Finished compilation: Wed Jul 26 17:02:45 MDT 2017
> make: *** [default] Error 1
> CMB-MacBook-Pro:releasebranch_7_2 cmbarton$ cd /Users/cmbarton/grass_
> source/releasebranch_7_2/lib/cairodriver
> CMB-MacBook-Pro:cairodriver cmbarton$ make
> gcc  -g -O2   -arch i386 -isysroot /Developer/SDKs/MacOSX10.8.sdk
> -fno-common  
> -I/Users/cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
> -I/Users/cmbarton/grass_source/releasebranch_7_2/dist.
> x86_64-apple-darwin16.7.0/include   -I../driver -I/
> Library/Frameworks/cairo.framework/Headers/ -I/Library/Frameworks/
> FreeType.framework/unix/include/ -DPACKAGE=\""grasslibs"\"   -I/Users/
> cmbarton/grass_source/releasebranch_7_2/dist.x86_64-apple-darwin16.7.0/include
> -I/Users/cmbarton/grass_source/releasebranch_7_2/dist.
> x86_64-apple-darwin16.7.0/include -DRELDIR=\"lib/cairodriver\" -o
> OBJ.x86_64-apple-darwin16.7.0/text.o -c text.c
> text.c:20:10: fatal error: 'fontconfig/fontconfig.h' file not found
> #include 
>  ^
> 1 error generated.
> make: *** [OBJ.x86_64-apple-darwin16.7.0/text.o] Error 1
>
>
Hi Michael,

As far as I understand, compiler simply looks at all directories specified
by -I (which are configured by ./configure) and pastes the -I path and the
path in #include together and tests if the file exists. So I would first
double check:

ls /Library/Frameworks/cairo.framework/Headers/
ls /Library/Frameworks/cairo.framework/Headers/fontconfig/fontconfig.h

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

[GRASS-dev] GRASS Mac compiling - cairo problems

[Michael Barton]

I'm trying to do a basic compilation of GRASS 7.2 on my Mac to get started in a 
new binary packaging attempt. I'm hitting new issues with cairo and wonder if 
anyone can shed some light on this.

This is the first time I've tried compiling on my current machine. It is up to 
date with the newest version of OS X (Sierra, OS X 10.12.6) and current 
developer tools.

I have William Kyngesburye's cairo framework 12.2-1.

First problem is that configure could not find cairo with the path in the 
configure string I used last October. I tried a couple of other paths and found 
one that worked.

When I tried to make GRASS, I ran into the following errors, all related to 
cairo. cairodriver can't find fonconfig.h, which I think are leading to the 
rest of the errors.

But fontconfig.h is IN the directory I've pointed to in the 
--with-cairo-includes= statement.

Here is my configure script:

./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.8.sdk --with-freetype 
--with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include/ 
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib 
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config 
--with-gdal-libs=/Library/Frameworks/GDAL.framework/Libraries --with-proj 
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include 
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib 
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj 
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config 
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include 
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib 
--with-cairo --with-cairo-includes=/Library/Frameworks/cairo.framework/Headers/ 
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib 
--with-cairo-ldflags="-lcairo" --without-postgres --without-mysql --with-sqlite 
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib 
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include 
--with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include 
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x 
--with-cxx --with-opengl=aqua --without-readline --prefix=/Applications 
--enable-macosx-app --with-python 
--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.12.1/bin/wx-config 
--with-macosx-archs="i386 x86\_64" --with-opencl

Here are the errors (I can give a full log dump if it would be helpful):

Errors in:
/Users/cmbarton/grass_source/releasebranch_7_2/lib/cairodriver
/Users/cmbarton/grass_source/releasebranch_7_2/lib/display
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.barscale
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.colortable
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.erase
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.font
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.fontlist
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.geodesic
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.graph
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.grid
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.his
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.histogram
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.info
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.labels
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.legend
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.legend.vect
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.linegraph
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.mon
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.northarrow
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.path
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.profile
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.rast
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.rast.arrow
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.rast.num
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.rgb
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.rhumbline
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.text
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.vect
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.vect.chart
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.vect.thematic
/Users/cmbarton/grass_source/releasebranch_7_2/display/d.where
/Users/cmbarton/grass_source/releasebranch_7_2/vector/v.label
/Users/cmbarton/grass_source/releasebranch_7_2/misc/m.nviz.script
--
In case of errors please change into the 

Re: [GRASS-dev] [GRASS GIS] #3380: v.what.vect query_column dropdown button doesn't show attribute columns of query_map

[GRASS GIS]

#3380: v.what.vect query_column dropdown button doesn't show attribute columns 
of
query_map
--+-
  Reporter:  rorschach|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.2.1
Resolution:   |   Keywords:  v.what.vect
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mlennert):

 Replying to [ticket:3380 rorschach]:
 > A pleasant day to everyone.
 >
 > Does anyone else encounter this problem? When I'm using v.what.vect, the
 query_column dropdown button doesn't show the attribute columns of the
 vector layer specified by query_map.
 >
 > It's not too much of an issue since the user can always type the column
 names manually but the dropdown button is supposed to be there to allow
 the user to select the attribute columns of their query_map.
 >
 > If anyone knows a fix or wants to fix this, I would highly appreciate
 it.
 >
 > By the way, I'm using GRASS 7.2.1 on Xubuntu 16.04.

 This was fixed in trunk in r70518, but apparently never backported. I
 don't know if there are objections to backporting... Martin ?

--
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] #3380: v.what.vect query_column dropdown button doesn't show attribute columns of query_map

[GRASS GIS]

#3380: v.what.vect query_column dropdown button doesn't show attribute columns 
of
query_map
--+-
  Reporter:  rorschach|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.2.1
Resolution:   |   Keywords:  v.what.vect
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by rorschach):

 * Attachment "no-columns.png" added.


--
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] #3380: v.what.vect query_column dropdown button doesn't show attribute columns of query_map

[GRASS GIS]

#3380: v.what.vect query_column dropdown button doesn't show attribute columns 
of
query_map
-+-
 Reporter:  rorschach|  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Vector   |Version:  7.2.1
 Keywords:  v.what.vect  |CPU:  Unspecified
 Platform:  Linux|
-+-
 A pleasant day to everyone.

 Does anyone else encounter this problem? When I'm using v.what.vect, the
 query_column dropdown button doesn't show the attribute columns of the
 vector layer specified by query_map.

 It's not too much of an issue since the user can always type the column
 names manually but the dropdown button is supposed to be there to allow
 the user to select the attribute columns of their query_map.

 If anyone knows a fix or wants to fix this, I would highly appreciate it.

 By the way, I'm using GRASS 7.2.1 on Xubuntu 16.04.

 Thank you.

 ''Attached is an image for your perusal.''

--
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 flyer for the new osgeo branding

[Moritz Lennert]

On 25/07/17 00:55, Luca Delucchi wrote:

Hi devs,

I worked for the GRASS flyer [0] with the new osgeo branding, the
content is really similar to the GRASS flyer, just different layout.

Comments?


Some quick remarks:

- First of all: who are why addressing with this ? Users or developers ? 
The following remarks assume users.


- The first title reads "A mature mapping suite". I'm not sure I would 
advertise GRASS first and foremost for mapping. I'd rather present it as

"A mature spatial analysis suite" or something similar.

- Maybe an extract of the "GRASS GIS capabilities" on 
https://grass.osgeo.org/documentation/general-overview/ would be more 
important than the interoperability and development information. I think 
people should first get a vision of what GRASS GIS actually does before 
thinking about how interoperable it is...


- Paragraphs could possibly be rearranged to create a drilling down from 
the most important general info to more specific info. I would say that 
for first contact with users the most important elements are: what is 
it/what does it do ? who uses it ? On what OS's does it run ? Is there 
documentation ? Is there a community ? Is it "certified" (I agree that 
the fact that it is an OSGeo project needs to be prominently present) ?  ...


- I don't think we should adapt our logos to the OSGeo color scheme. 
Those are two different branding efforts. Not sure one has to fit into 
the other.


That's all for now, especially since I will not have time to work on 
this in the near future... ;-)


Moritz


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