Michael Barton | 30 Jan 19:52 2015
Picon

Re: New splash screen for GRASS GIS 7?

Thanks for doing the voting page Martin.

There seem to be 4 main components to the splash screen decisions:

1) Which image to use (we seem to be narrowing that down a lot)
2) Which font (unless we are set now with Fira Sans for the sans serif font)
3) Whether to use upper or lower case
4) Where to put the text on the image

For myself, I like the grassy world in color, 
the Fira Sans/Garramond fonts
the lower case for grass gis
and probably the text across the bottom of the image so the map aspect of the grassy world image can be better seen

Since this combination doesn’t exist, I’m not yet sure how best to express this on the page.

But all that said, and as much as I am in favor of our democratic procedures over all, I’m not sure voting will give the best graphic design. So maybe voting should be advisory, with Vincent having final say so?

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)



On Jan 30, 2015, at 9:41 AM, grass-dev-request <at> lists.osgeo.org wrote:

From: Martin Landa <landa.martin <at> gmail.com>
Cc: GRASS developers list <grass-dev <at> lists.osgeo.org>
To: Vincent Bain <bain <at> toraval.fr>
Date: January 30, 2015 at 8:53:32 AM MST
Subject: Re: [GRASS-dev] New splash screen for GRASS GIS 7?


Hi,

2015-01-30 15:13 GMT+01:00 Vincent Bain <bain <at> toraval.fr>:
I fear it is an endless discussion anyway. Objectivity is hard to reach
in that domain of graphic design.

this is what we need to avoid. RC2 is waiting for a new splash and
welcome banner. I can see three candidates [1]. Please free add new
candidates, it would be nice to launch voting during weekend and than
to move on to RC2 on the beginning of the next week, what do you
think?

Martin

[1] http://grasswiki.osgeo.org/wiki/Talk:Identity

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa



_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Moritz Lennert | 30 Jan 17:02 2015
Picon

New wiki page summarising GRASS APIs

Hi,

In preparation of a talk at the geospatial devroom at the FOSSDEM this 
weekend, I've elaborated a wiki page on the current GRASS GIS APIs:

http://grasswiki.osgeo.org/wiki/GRASS_GIS_APIs

I still need to complete the part on the C-API, but any feedback is 
welcome, especially if I put any nonsense in there. It really is only 
supposed to be a brief synthetic overview of each API to give people an 
idea.

Moritz
Moritz Lennert | 30 Jan 15:52 2015
Picon

pygrass: append new point to map of points

Hello,

Is it possible in pygrass to append a new point to a map of points (same 
for other features) ? Or do I have to get all the features of a map, and 
the new feature, and then write all features to a new map ?

Moritz
Rainer M Krug | 30 Jan 10:49 2015
Picon

[BUG 7.0.90RC1] Version not stated explicitly in RC1

The version info of GRASS GIS 7.0.0RC1 is missing the explicit statement
of the version number - see output below.

It is mentioned in the contributions section, but not explicitly as the
first line as in GRASS GIS 6.4.4 

Thanks,

Rainer
,----
| $ grass70 --version
| 
| Geographic Resources Analysis Support System (GRASS) is Copyright,
| 1999-2015 by the GRASS Development Team, and licensed under terms of the
| GNU General Public License (GPL) version >=2.
| 
| This GRASS 7.0.0RC1 release is coordinated and produced by
| the GRASS Development Team with contributions from all over the world.
| 
| This program is distributed in the hope that it will be useful, but
| WITHOUT ANY WARRANTY; without even the implied warranty of
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
| General Public License for more details.
| 
| $ grass64 --version
| GRASS GIS 6.4.4
| 
| Geographic Resources Analysis Support System (GRASS) is Copyright,
| 1999-2014 by the GRASS Development Team, and licensed under terms of the
| GNU General Public License (GPL) version >=2.
| 
| This GRASS 6.4.4 release is coordinated and produced by the
| GRASS Development Team with contributions from all over the world.
| 
| This program is distributed in the hope that it will be useful, but
| WITHOUT ANY WARRANTY; without even the implied warranty of
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
| General Public License for more details.
| 10:46:06 ~/Documents/Projects/R-Packages/spgrass/pkg$
`----

--

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 29 Jan 18:31 2015

[GRASS GIS] #2568: Upper-lower case issues with sqlite driver and affect on v.db.reconnect.all

#2568: Upper-lower case issues with sqlite driver and affect on v.db.reconnect.all
----------------------+-----------------------------------------------------
 Reporter:  ewcgrass  |       Owner:  grass-dev <at> …              
     Type:  defect    |      Status:  new                      
 Priority:  major     |   Milestone:  7.0.0                    
Component:  Database  |     Version:  svn-releasebranch70      
 Keywords:            |    Platform:  Linux                    
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------
 I am rebuilding an number of existing mapsets from GRASS 6.4.4 (svn 02 Nov
 2013) to GRASS 7.0.0 (svn 17 Jan 2015), per the directions given in the
 wiki. The 6.4.4 mapset database files are in .dbf format, with conversions
 being done to sqlite format. v.build.all works fine, as does db.connect
 -d, but v.db.reconnect.all terminates early when it encounters a .dbf
 table that has the name "CAT" (upper case) in the key column, as opposed
 to "cat" (lower case).

 What happens is the sqlite table is created with all the attributes being
 properly copied over, but the sqlite table refuses to connect to the
 vector file. Once the .dbf table has been converted to sqlite format, then
 I can change the case of the key column using sqliteman, after which the
 table and vector file will then connect properly using either v.db.connect
 or v.db.reconnect.all. However, v.db.reconnect.all will terminate early
 again upon encountering the next .dbf table in which the key column is
 "CAT" in upper case.

 I can show the .dbf table attibutes by right-clicking on the vector map
 being converted (after having used v.build.all, of course) on the layer
 manager gui, and can access the "manage table" tab in the gui that
 appears. However, it shows "cat" in lower case when it is in fact in upper
 case "CAT", and will not allow the name to be changed from "CAT" to "cat"
 because the name cat already exists, nor will it allow CAT to be changed
 temporarily to something like "cat1" as a temporary place holder so it can
 be changed again to "cat", since "cat" or "CAT" is required in the key
 column.

 The .dbf tables that cause this problem are tables that have been modified
 and saved using OpenOffice or LibreOffice calc, which defaults to saving
 all column names to upper case.

 I could get around this issue by repeatedly using v.db.reconnect.all and
 sqliteman until all tables have been properly copied over and connected,
 but that defeats the whole purpose of having v.db.reconnect.all in the
 first place, and also highlight the problem that exists with the sqlite
 driver regarding column name capitalization, which is something that is
 likely to affect many other GRASS users.

 My suggest(s) for correcting this would be to either have a means of
 ignoring errors in v.db.reconnect.all (but this could cause other yet
 undefined problems), or to have the sqlite driver (or whatever other GRASS
 module is used by v.db.reconnect.all that is causing early termination) to
 accept "CAT" as well as "cat".

 This issue does not appear to be a random one, since I have been able to
 encounter it and correct it (by recursively using sqliteman with
 v.db.reconnect.all and/or v.db.connect with the newly changed table with
 the sqlite file) repeatedly with all vector files for which the category
 column in the dbf table is spelled "CAT".

 Good work on GRASS 7 folks... its impressive!

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2568>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Paulo van Breugel | 29 Jan 18:30 2015
Picon

Compute mahalanobis distance using Scipy

I would like to compute a raster layer with for each raster cell the mahalanobis distance to the centre of the environmental space formed by all reference data points (raster cells). In R this can be done as explained here [1].

. I would like to do this using python only (no dependency on R). I came up with the following, which works, but is very slow. I guess this is because it loops over every raster cell to compute the mahalanobis distance? Any idea how this can be done faster (I am very new to python, so bear with me if I am making stupid mistakes)



ref = ['bio1 <at> clim','bio2 <at> clim','bio3 <at> clim']

import numpy as np

from scipy.spatial import distance

import scipy.linalg as linalg

import grass.script as grass

import grass.script.array as garray


# Create covariance table (could do this in python instead)

text_file = open("tmpfile", "w")

text_file.write(grass.read_command("r.covar", quiet=True, map=ref))

text_file.close()

covar = np.loadtxt(tmpcov, skiprows=1)

os.remove(tmpcov)

 

# Import data

dat_ref = None

stat_mean = None

layer = garray.array()


for i, map in enumerate(ref):

    layer.read(map, null=np.nan)

    s = len(ref)

    r, c = layer.shape

    if dat_ref is None:

        dat_ref = np.empty((s, r, c), dtype=np.double)

    if stat_mean is None:

        stat_mean = np.empty((s), dtype=np.double)

    dat_ref[i,:,:] = layer

    stat_mean[i] = np.nanmean(layer)

del layer


# Compute mahalanobis distance

r, c = dat_ref[1,:,:].shape

stat_mah = garray.array()

for i in xrange(r):

     for j in xrange(c):

         cell_ref = dat_ref[...,i,j]

         stat_mah[i,j] = distance.mahalanobis(cell_ref, stat_mean

, linalg.inv(covar))

stat_mah.write("mahalanobisMap")



[1] https://pvanb.wordpress.com/2014/05/13/a-new-method-and-tool-exdet-to-evaluate-novelty-environmental-conditions/

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Rainer M Krug | 29 Jan 15:51 2015
Picon

Getting version number *before* starting

Hi

I would, for implementation in spgrass7 in R, to be able to get the version
number of GRASS GIS before starting GRASS. I know that in the file

,----
| GRASS_BASE_DIRECTORY/etc/VERSIONNUMBER
`----

the version number is stored, but I have two questions:

1) is this the same between systems (I saw it in Mac Linux and Windows)?
2) I assume the location of this file is very un-likely to change?
3) can the internal structure of the GDRASS_BASE_DIRECTORY be configured
during the build process (particularly the bin/ and the location of
VERSIONNUMBER), and if yes, how can I obtain the location of these folders?

So: would there be any downside in just reading this file to determine
the version of GRASS GIS, as the grass startup script seems to be
reading from that file as well?

Thanks,

Rainer

--

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Michael Barton | 29 Jan 13:27 2015
Picon

Re: New splash screen for GRASS GIS 7?

Thanks again for all this Vicent. I too like the grassy continents in green. The white lettering on this is a nice contrast to the dark lettering on the startup too. Fira Sans is a good font. It really updates the looks of this.

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)




On Jan 29, 2015, at 1:30 AM, grass-dev-request <at> lists.osgeo.org wrote:


From: 
Vincent Bain <bain <at> toraval.fr>
To: Martin Landa <landa.martin <at> gmail.com>
Date: January 28, 2015 at 2:26:42 PM MST
Subject: Re: [GRASS-dev] New splash screen for GRASS GIS 7?


Hi Martin, thank you...

I just updated the wiki page to suggest a font substitution : Fira Sans
is a very clean sans serif typeface, under the SIL Open Font License. I
find an intersting contrast with garamond serif.

Bye,
V.



Le mercredi 28 janvier 2015 à 22:16 +0100, Martin Landa a écrit :
Hi Vincent,

2015-01-28 15:36 GMT+01:00 Vincent Bain <bain <at> toraval.fr>:
I packed most of the graphical tests I did last week on a wiki page. I
tried to initiate a place (very rough yet) where we can further set up
things concerning graphical identity. Hope this helps.

http://grasswiki.osgeo.org/wiki/Identity

thanks a lot! The splash screens with grass continents are absolutely
great!!! I like most [1]. For the startup screen I would choose [2].

Martin

[1] http://grasswiki.osgeo.org/w/images/GRASSGIS_splash4.jpg
[2] http://grasswiki.osgeo.org/wiki/File:GRASSGIS_welcome_banner1.jpg



_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 29 Jan 13:09 2015

[GRASS GIS] #2567: v.net.iso: allow extraction of subnet limited by maximum cost

#2567: v.net.iso: allow extraction of subnet limited by maximum cost
------------------------------------+---------------------------------------
 Reporter:  mlennert                |       Owner:  grass-dev <at> …              
     Type:  enhancement             |      Status:  new                      
 Priority:  normal                  |   Milestone:  7.1.0                    
Component:  Vector                  |     Version:  unspecified              
 Keywords:  v.net.iso maximum cost  |    Platform:  Unspecified              
      Cpu:  Unspecified             |  
------------------------------------+---------------------------------------
 Another idea for maybe accelerating v.net.iso: if only a small subpart of
 the network needs to be analysed, add a flag that creates an output map
 containing only those segments that are within the maximum isochrone
 given, and not all the rest of the network.

 In other words, currently, when a user asks for costs=5,10,15,20 only
 output the network that is reachable within 20, and not the 20-* part.

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2567>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 29 Jan 12:34 2015

[GRASS GIS] #2566: v.net.*: allow separate output for each starting point

#2566: v.net.*: allow separate output for each starting point
-------------------------------------------------+--------------------------
 Reporter:  mlennert                             |       Owner:  grass-dev <at> …              
     Type:  enhancement                          |      Status:  new                      
 Priority:  normal                               |   Milestone:  7.1.0                    
Component:  Vector                               |     Version:  svn-trunk                
 Keywords:  v.net.iso v.net.alloc network graph  |    Platform:  Unspecified              
      Cpu:  Unspecified                          |  
-------------------------------------------------+--------------------------
 When using v.net.iso (also v.net.alloc and maybe others) with several
 different starting points, I have to relaunch the module on each point if
 I want separate output for each point and not an isochrone or allocation
 only for the closest point. So I loop over the different starting points.
 However, at each run, v.net.iso has to reconstruct the graph which takes
 time making the loop quite slow.

 Two ideas come to mind that might accelerate this:

  1. Integrate the loop into the modules, e.g. with a flag indicating that
 you want separate output per starting node. In this situation, the content
 of output option would become a basename for all output maps.

  2. Create a system which keeps the contructed graph in memory or in a
 file allowing to use it over different runs.

 Any of this sound feasible ?

 Moritz

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2566>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Blumentrath, Stefan | 29 Jan 09:30 2015
Picon

Build errors for GRASS 7.1 on Ubuntu?

Dear all,

 

I was just about to test Sörens new t.rast.what module but it seems that I have to update my installation of GRASS 7 (trunk) first.

 

Unfortunately, I get a lot of build errors with r64351 on Ubuntu 14.04…

 

This is how I configure:

CFLAGS="-O2 -msse -msse2 -mfpmath=sse -minline-all-stringops -g -Wall" LDFLAGS="-s" ./configure --with-cxx --with-sqlite --with-postgres --with-postgres-includes=/usr/include/postgresql --with-odbc --with-cairo --with-proj-share=/usr/local/share/proj --with-tcltk-includes=/usr/include/tcl8.4/ --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-fftw --with-nls --with-python --with-tiff --with-geos --enable-largefile --with-readline --with-blas --with-glw --with-motif --with-openmp --with-wxwidgets --with-pthread --with-liblas --with-netcdf --with-lapack

 

./configure runs without issues, but on make I get errors in more than 40/50 modules (gui, raster, vector, temporal, db).

One of the error messages is a syntax error in a header file:

/usr/include/GL/gl.h:90: Syntax error at '\n'

 

Any ideas?

 

Thanks for helping.

Stefan

 

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Gmane