Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Luca Delucchi]

On 29 January 2015 at 16:13, Martin Landa  wrote:
> Hi,
>

Hi,

>
> or we can vote for the current proposals:
>
> 1) upper-case
>
> http://grasswiki.osgeo.org/w/images/GRASSGIS_splash4.jpg
> +
> http://grasswiki.osgeo.org/w/images/GRASSGIS_welcome_banner1.jpg
>
> 2) lower-case
>
> http://grasswiki.osgeo.org/w/images/GRASSGIS_splash5.jpg
> +
> http://grasswiki.osgeo.org/w/images/GRASSGIS_welcome_banner4.jpg
>
> From design POV I like 2), but what I don't like are lower-case
> letters. Would be nice to have third proposal based on 2) but with
> upper-case letters. Then I would be happy to start voting.
>

+1, I also like 2), but what I don't like GRASS name in lower-case letters

> Martin
>

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[GRASS GIS]

#2568: Upper-lower case issues with sqlite driver and affect on 
v.db.reconnect.all
--+-
 Reporter:  ewcgrass  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  major |   Milestone:  7.0.0
Component:  Database  | Version:  svn-releasebranch70  
 Keywords:|Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by mmetz):

 Replying to [ticket:2568 ewcgrass]:
 > 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.

 Have you updated the vector db connections (in GRASS 6.4) after editing
 the tables? If you change the key column name from lower case to upper
 case, you need to run `v.db.connect map= key=` first before doing anything
 else.

 >
 > 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: 
GRASS GIS 

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

Re: [GRASS-dev] Getting version number *before* starting

[Rainer M Krug]

Vaclav Petras  writes:

> On Thu, Jan 29, 2015 at 9:51 AM, Rainer M Krug  wrote:
>
>> 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 about the --version parameter of grass command.

This is for "human consumption" and, as you point out below, has changed
quite a bit - actually I think that the version info is just plainly
missing from GRASS GIS 7.0.0RC1 as I think it should be before the
license?



>
> {{{
> $ 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...
> }}}
>
> Unfortunately for GRASS GIS 7 it is giving more the license and about then
> the version:
>
> {{{
> $ grass71 --version
>
> 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 7.1.svn release is coordinated and produced by
> }}}
>
> Although, I'm running 71 from source code, so it might be different.
>
> To get general idea, here are examples what other projects have in
> --version:
>
> {{{
> gcc --version
> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> ...
> }}}
>
> {{{
> pandoc --version
> pandoc 1.12.2.1
> Compiled with texmath 0.6.5.2, highlighting-kate 0.5.5.1.
> Syntax highlighting is supported for the following languages:
> ...
> }}}

Yup - they all have the version in the first line, bur RC1 has it not -
I think this is a bug?

Thanks,

Rainer

>
> 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: Rainerkrugsde
>> PGP: 0x0F52F982
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Getting version number *before* starting

[Rainer M Krug]

Vaclav Petras  writes:

> On Thu, Jan 29, 2015 at 5:20 PM, Blumentrath, Stefan <
> stefan.blumentr...@nina.no> wrote:
>
>>  What about grass70 --config?
>>
>> Cheers
>>
>> Stefan
>>
>
> --config does not work for 64.

unfortunately not - but one could always make an exception for 64.

>
> For 70 it does not give version, only revision (of library I think). We
> should probably change the format to be more parseable. The line order is
> really not stable, I'm not sure what other do.
>
> $ grass71 --config
> x86_64-unknown-linux-gnu
> ./configure  --enable-largefile=yes --with-nls --with-cxx --with-readline
> --with-pthread --with-proj-share=/usr/share/proj
> --with-geos=/usr/bin/geos-config --with-wxwidgets --with-cairo
> --with-opengl-libs=/usr/include/GL --with-freetype=yes
> --with-freetype-includes=/usr/include/freetype2/ --with-postgresql=yes
> --with-postgres-includes=/usr/include/postgresql --with-sqlite=yes
> --with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-odbc=no
> --with-liblas=yes --with-liblas-config=/usr/bin/liblas-config
> gcc
> /home/vasek/dev/grass/gcc_trunk/dist.x86_64-unknown-linux-gnu
> 63639
> }}}
>
> 70 --help has actually version number on the first line as 64 --version has
> but 64 --help does not have the version, except for usage (at least the one
> from Ubuntu package).
>
> I'm afraid we have to implement something better. What would it be?

A parsable format would be really nice here, as most of the information
needed is here.

Some standard fields as
- MAJOR version (e.g. 7)
- MINOR version (e.g. 1)
- PATCH version (e.g. 0)
- version EXTENSION (e.g. alpha)
- REVISION
- PLATFORM (e.g. x86_64-unknown-linux-gnu)
- grass BASE directory (e.g.
/home/vasek/dev/grass/gcc_trunk/dist.x86_64-unknown-linux-gnu) (I
assume the bin/ is in the base directory?)
- the CONFIGURE options - possibly split into separate and multiple
entries

A format like the Debian Control Files Syntax [1], which is defined and
easily parsable from different languages, would be the easiest.

I don't know if something like this can be still incorporated into
7.0.0?

This would be really nice and useful.

Thanks,

Rainer


>
>
>>
>> *From:* grass-dev-boun...@lists.osgeo.org [mailto:
>> grass-dev-boun...@lists.osgeo.org] *On Behalf Of *Vaclav Petras
>> *Sent:* 29. januar 2015 23:10
>> *To:* Rainer M Krug
>> *Cc:* grass-dev@lists.osgeo.org
>> *Subject:* Re: [GRASS-dev] Getting version number *before* starting
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 29, 2015 at 9:51 AM, Rainer M Krug  wrote:
>>
>> 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 about the --version parameter of grass command.
>>
>>
>> {{{
>> $ 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...
>> }}}
>>
>> Unfortunately for GRASS GIS 7 it is giving more the license and about then
>> the version:
>>
>> {{{
>> $ grass71 --version
>>
>> 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 7.1.svn release is coordinated and produced by
>> }}}
>>
>>
>> Although, I'm running 71 from source code, so it might be different.
>>
>> To get general idea, here are examples what other projects have in
>> --version:
>>
>>
>> {{{
>> gcc --version
>> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> ...
>> }}}
>>
>> {{{
>> pandoc --version
>> pandoc 1.12.2.1
>> Compiled with texmath 0.6.5.2, highlighting-kate 0.5.5.1.
>> Syntax highlighting is supported for the following languages:
>>
>> ...
>> }}}
>>
>> 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: Rainerkrugsde
>> PGP: 0x0F52F982
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinf

[GRASS-dev] [BUG 7.0.90RC1] Version not stated explicitly in RC1

[Rainer M Krug]

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: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Moritz Lennert]

On 29/01/15 17:43, Vaclav Petras wrote:

On the MS Windows installer takes care of that by copying demo Location
to newly created grassdata dir in Documents and creating the rc file. Is
this enough? If not why? And do we want to do something similar for
cases when installation is not done by GRASS GIS? If startup detects no
grassdata it could just create the dir and copy the demo Location there,
so the only thing needed is to press Start button.


Don't forget that in many GNU/Linux distributions data is separated from 
applications in the packaging. So, either we have to tell users to 
install a specific data package (e.g. grass-demodata) or the startup 
screen needs a button: "Download and unpack demo data".


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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Moritz Lennert]

On 29/01/15 18:30, Paulo van Breugel wrote:

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)


There's probably ways to accelerate this in Python (maybe you can try 
rewriting your for-loops as map() calls), but on the Wikipedia page on 
mahalanobis distance that you reference [1], it says that:


"Along each principal component axis, it measures the number of standard 
deviations from P to the mean of D. If each of these axes is rescaled to 
have unit variance, then Mahalanobis distance corresponds to standard 
Euclidean distance in the transformed space."


Couldn't you use i.pca to calculate principal components and then 
calculate distances of points in that space ?


Just brainstorming...


Moritz


[1] http://en.wikipedia.org/wiki/Mahalanobis_distance

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

+1 for a button, but I am not sure sure a data download is that
necessary...
The button might just be a script creating a (several?) empty Location(s?)
in a directory that the user can choose.



On 30 January 2015 at 15:20, Moritz Lennert 
wrote:

> On 29/01/15 17:43, Vaclav Petras wrote:
>
>> On the MS Windows installer takes care of that by copying demo Location
>> to newly created grassdata dir in Documents and creating the rc file. Is
>> this enough? If not why? And do we want to do something similar for
>> cases when installation is not done by GRASS GIS? If startup detects no
>> grassdata it could just create the dir and copy the demo Location there,
>> so the only thing needed is to press Start button.
>>
>
> Don't forget that in many GNU/Linux distributions data is separated from
> applications in the packaging. So, either we have to tell users to install
> a specific data package (e.g. grass-demodata) or the startup screen needs a
> button: "Download and unpack demo data".
>
> Moritz
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Moritz Lennert]

On 30/01/15 11:01, Yann Chemin wrote:

+1 for a button, but I am not sure sure a data download is that
necessary...
The button might just be a script creating a (several?) empty
Location(s?) in a directory that the user can choose.


I think the idea was to have a location with some data already in it to 
allow people to just explore GRASS without having to think about data 
import issues, etc.



Moritz

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Rainer M Krug]

Yann Chemin  writes:

> +1 for a button, but I am not sure sure a data download is that
> necessary...

I think a download button would be useful as the demo location should be
in the home directory so that the user can play with it.

The disadvantage would be that the user has to be online for this. A
compromise could be to have

a) an archived location in package form, so that the archive is
   installed but not the location. This would be an optional package.

b) A button which, depending on whether the grass-demodata package has been
   installed, extracts the archived location into the home directory or,
   if it has not been installed, suggests to download it.

Cheers,

Rainer

> The button might just be a script creating a (several?) empty Location(s?)
> in a directory that the user can choose.



>
>
>
> On 30 January 2015 at 15:20, Moritz Lennert 
> wrote:
>
>> On 29/01/15 17:43, Vaclav Petras wrote:
>>
>>> On the MS Windows installer takes care of that by copying demo Location
>>> to newly created grassdata dir in Documents and creating the rc file. Is
>>> this enough? If not why? And do we want to do something similar for
>>> cases when installation is not done by GRASS GIS? If startup detects no
>>> grassdata it could just create the dir and copy the demo Location there,
>>> so the only thing needed is to press Start button.
>>>
>>
>> Don't forget that in many GNU/Linux distributions data is separated from
>> applications in the packaging. So, either we have to tell users to install
>> a specific data package (e.g. grass-demodata) or the startup screen needs a
>> button: "Download and unpack demo data".
>>
>> Moritz
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Nikos Alexandris]

Maybe a crazy idea, but...  if access to internet isn't an option, 
maybe the "button" can create a Location and Mapset(s), and let a script 
create some artificial vector and raster maps?  So a user can still play 
along with unreal data.


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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Markus Neteler]

On Thu, Jan 29, 2015 at 2:58 PM, Vincent Bain  wrote:
> Le mercredi 28 janvier 2015 à 17:42 +0200, Nikos Alexandris a écrit :
>> The ones @
>> 
>> are for the Wiki... !?  If anyone is interested.
>
> Sorry Nikos, I missed your suggestion.
> Perhaps it's an opportunity to bet on a similar output, again for
> consistency (see attached file).

While this is nicely evolving, please let's keep "GIS/gis" in the name.

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

Re: [GRASS-dev] [BUG 7.0.90RC1] Version not stated explicitly in RC1

[Markus Neteler]

On Fri, Jan 30, 2015 at 10:49 AM, Rainer M Krug  wrote:
> 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,

Fixed in r64361. + r64362.

grass71 --version
GRASS GIS 7.1.svn

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 GIS 7.1.svn 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.

(likewise done for 7.0.x)

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

Trying to satisfy everyone's claims, I propose another splash screen :
- capitalized GRASS GIS (boohhh ;-)) ;
- centered layout with title underneath logo.

It is available on the wiki page, it comes with a welcome banner too.

/Beware that we might progressively turn the result into something quite
flavourless.../

Vincent
(going back to snow blowing)


Le vendredi 30 janvier 2015 à 12:35 +0100, Markus Neteler a écrit :
> On Thu, Jan 29, 2015 at 2:58 PM, Vincent Bain  wrote:
> > Le mercredi 28 janvier 2015 à 17:42 +0200, Nikos Alexandris a écrit :
> >> The ones @
> >> 
> >> are for the Wiki... !?  If anyone is interested.
> >
> > Sorry Nikos, I missed your suggestion.
> > Perhaps it's an opportunity to bet on a similar output, again for
> > consistency (see attached file).
> 
> While this is nicely evolving, please let's keep "GIS/gis" in the name.
> 
> thanks
> Markus


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

Re: [GRASS-dev] [BUG 7.0.90RC1] Version not stated explicitly in RC1

[Rainer M Krug]

Markus Neteler  writes:

> On Fri, Jan 30, 2015 at 10:49 AM, Rainer M Krug  wrote:
>> 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,
>
> Fixed in r64361. + r64362.
>

Thanks

Rainer


> grass71 --version
> GRASS GIS 7.1.svn
>
> 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 GIS 7.1.svn 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.
>
> (likewise done for 7.0.x)
>
> Markus

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Yann Chemin]

still +1 for http://grasswiki.osgeo.org/wiki/File:GRASSGIS_splash5.jpg

On 30 January 2015 at 17:45, Vincent Bain  wrote:

> Trying to satisfy everyone's claims, I propose another splash screen :
> - capitalized GRASS GIS (boohhh ;-)) ;
> - centered layout with title underneath logo.
>
> It is available on the wiki page, it comes with a welcome banner too.
>
> /Beware that we might progressively turn the result into something quite
> flavourless.../
>
> Vincent
> (going back to snow blowing)
>
>
> Le vendredi 30 janvier 2015 à 12:35 +0100, Markus Neteler a écrit :
> > On Thu, Jan 29, 2015 at 2:58 PM, Vincent Bain  wrote:
> > > Le mercredi 28 janvier 2015 à 17:42 +0200, Nikos Alexandris a écrit :
> > >> The ones @
> > >> <
> http://grasswiki.osgeo.org/wiki/User:NikosA#Ideas_for_an_alternative_GRASS-Wiki_logogram
> >
> > >> are for the Wiki... !?  If anyone is interested.
> > >
> > > Sorry Nikos, I missed your suggestion.
> > > Perhaps it's an opportunity to bet on a similar output, again for
> > > consistency (see attached file).
> >
> > While this is nicely evolving, please let's keep "GIS/gis" in the name.
> >
> > thanks
> > Markus
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

Continuing the crazy thoughts,
You could have FFT/wavelet parameters per column of a raster image
hard-coded to create an image on request (that I could do I think). About a
vector, well a set of polygon arcs pairs can easily be stored in code and
(i suppose) imported on the fly as a vector.

On 30 January 2015 at 16:06, Nikos Alexandris 
wrote:

> Maybe a crazy idea, but...  if access to internet isn't an option, maybe
> the "button" can create a Location and Mapset(s), and let a script create
> some artificial vector and raster maps?  So a user can still play along
> with unreal data.
>
> Nikos
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Moritz Lennert]

On 30/01/15 13:15, Vincent Bain wrote:

Trying to satisfy everyone's claims, I propose another splash screen :
- capitalized GRASS GIS (boohhh ;-)) ;
- centered layout with title underneath logo.

It is available on the wiki page, it comes with a welcome banner too.

/Beware that we might progressively turn the result into something quite
flavourless.../


Even though GRASS is an acronym and so should normally be capitalized, I 
don't have an opinion about that.


However, I do prefer splash4 (with modified fonts) over splash7. Did 
anyone plead for centralization ?


The idea was just to put logo and title closer together.

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
+---
 Reporter:  santipardo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:  7.0.0
Component:  wxGUI   | Version:  svn-releasebranch70  
 Keywords:  locale  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:2 annakrat]:
 > I encoded the string in r64335 to the encoding set during the startup. I
 am not sure if that solves the problem, needs testing.
 That change is bogus. The string should be a str (byte string), not
 unicode, so calling .encode() on it is meaningless. Reverted in r64364.

 The error appears to arise from r41856 passing unicode=True to
 gettext.install(), meaning that translated strings are returned as unicode
 values which then end up being converted to strings using the default
 encoding. Fixed in r64366.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
+---
 Reporter:  santipardo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:  7.0.0
Component:  wxGUI   | Version:  svn-releasebranch70  
 Keywords:  locale  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:6 glynn]:

 > The error appears to arise from r41856 passing unicode=True to
 gettext.install()

 A similar mistake exists in r59652, fixed in r64367

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Nikos Alexandris]

On 30.01.2015 14:35, Yann Chemin wrote:


Continuing the crazy thoughts,
You could have FFT/wavelet parameters per column of a raster image
hard-coded to create an image on request (that I could do I think). 
About a
vector, well a set of polygon arcs pairs can easily be stored in code 
and

(i suppose) imported on the fly as a vector.


I was thinking more of random stuff (random points, polygons for 
vectors, and some arbitrary raster maps based on some random/fuzzy 
rules).  But your idea is far more advanced and suitable for the case.


So, we are talking about a "minimal data set" created on-demand, 
without the need to deliver any real data.  I will help in this 
direction, as far as I can.  What do others think about this?


Nikos

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Nikos Alexandris]

On 30.01.2015 14:24, Yann Chemin wrote:

still +1 for 
http://grasswiki.osgeo.org/wiki/File:GRASSGIS_splash5.jpg


me too, +1 (for lower case letters as well).  This splash is "so very" 
well crafted.


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

Re: [GRASS-dev] [GRASS GIS] #2564: r.what: remove 400 maps limit and add some new output options

[Sören Gebbert]

Dear Stefan,
thank you very much for your feedback, the patch and suggestions.

I have integrated some of your suggestions in t.rast.what. There is
now stdout and coordinates support in the latest trunk version
(r64368). The column layout bug is now fixed and the documentation was
updated according to the new features. Everything is now covered with
tests. Hence, if the modules does not run as you expect, please make a
test run (in a grass session make python test_what.py in the testsuite
folder of t.rast.what) and send me the result of the test, so i can
investigate the problem.

I did not modified the options in t.rast.what as your patch suggested,
since the options should run by default in your suggested
configuration.

The temporal database layout and its handling (distributed, mapset
specific temporal databases) should be identical in the grass7.0
release version and grass7 trunk.

Best regards
Soeren

2015-01-30 8:49 GMT+01:00 Blumentrath, Stefan :
> Forgot to mention:
>
> t.rast.what does not seem to write to stdout (as the description suggests), 
> only to file. Output to stdout could be an improvement for people who want to 
> read the output directly into R for example (for that purpose the " 
> one_point_per_row_output"-layout is splendid).
>
> Carrying also the coordinates-option from r.what to t.rast.what would be nice 
> for cases where one only has a few coordinates to process and where copying 
> them from a text file or web and pasting them into the module is more 
> convenient than creating a vector map for a single use case in advance (and 
> probably deleting the vector map afterwards)...
>
> Finally, as written in the r.what ticket, being able to make use of the 
> site_name column also in "vector-map-mode" would be useful, because it is 
> more demanding (both for user and computer) to join additional information to 
> the output (or the other way around) using two columns in double precision 
> compared to e.g. one cat column(or whatever a user might like to have in 
> order to carachterize the sites), esp. because coordinates may be given with 
> different level of precision in r.what and v.to.db for example. But this 
> applies to r.what first of course...
> An intermediate solution could be to pipe something like:
> v.to.db map=INPUT_VECTOR_MAP option=coor qcolumn=cat separator=comma -p | awk 
> -v FS=',' -v OFS=',' '{print $2,$3,$1}' | tail -n +2
> to the coordinates option in r.what... That way the cat column would show up 
> in the r.what output...
>
> Thanks again for the excellent tool!
>
> Cheers,
> Stefan
>
>
>
> -Original Message-
> From: grass-dev-boun...@lists.osgeo.org 
> [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Blumentrath, Stefan
> Sent: 29. januar 2015 07:30
> To: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] [GRASS GIS] #2564: r.what: remove 400 maps limit and 
> add some new output options
>
> Great news! Thanks.
> I shall test immediately.
>
> -Original Message-
> From: grass-dev-boun...@lists.osgeo.org 
> [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of GRASS GIS
> Sent: 29. januar 2015 00:16
> Subject: Re: [GRASS-dev] [GRASS GIS] #2564: r.what: remove 400 maps limit and 
> add some new output options
>
> #2564: r.what: remove 400 maps limit and add some new output options
> -+--
> -+
>  Reporter:  sbl  |   Owner:  grass-dev@…
>  Type:  enhancement  |  Status:  new
>  Priority:  normal   |   Milestone:  7.1.0
> Component:  Raster   | Version:  svn-trunk
>  Keywords:  r.what   |Platform:  Unspecified
>   Cpu:  Unspecified  |
> -+--
> -+
>
> Comment(by huhabla):
>
>  I have just committed a new temporal module called t.rast.what in trunk
>  (r64349 - r64351) that utilized r.what to sample space time raster  datasets 
> using vector points. It provides three output layouts that  transforms the 
> r.what output into row or column layouts. It can run  several r.what 
> processes in parallel using a maximum of 400 raster map  layer in a single 
> r.what process.
>
>  Please have a look at it.
>
>  Any feedback about its performance, usefulness and handling is highly  
> welcome.
>
>  Improving r.what to allow more than 400 maps is simple, just edit the  fixed 
> value in the source. But, editing this value may cause open file  handler 
> limit problems with your OS. However, these limits can be adjusted  at kernel 
> level configuration for Linux.
>
>  Implementing a more intelligent file handling solution requires more  effort.
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

Le vendredi 30 janvier 2015 à 13:41 +0100, Moritz Lennert a écrit :
> On 30/01/15 13:15, Vincent Bain wrote:
> > Trying to satisfy everyone's claims, I propose another splash screen :
> > - capitalized GRASS GIS (boohhh ;-)) ;
> > - centered layout with title underneath logo.
> >
> > It is available on the wiki page, it comes with a welcome banner too.
> >
> > /Beware that we might progressively turn the result into something quite
> > flavourless.../
> 
> Even though GRASS is an acronym and so should normally be capitalized, I 
> don't have an opinion about that.

The point is it differs much from one country to another. I am not
certain but I believe anglo-saxons progressively come to the _french
usage_, i.e. capitalizing only the initial of an acronym when it is
pronounced as a word (the case for GRASS GIS). Extract from
https://en.wikipedia.org/wiki/Capitalization

While acronyms have historically been written in all-caps,
British usage is moving towards capitalizing only the first
letter in cases when these are pronounced as words (e.g., Unesco
and Nato), reserving all-caps for initialisms (e.g., UK and
USA).

I fear it is an endless discussion anyway. Objectivity is hard to reach
in that domain of graphic design.

> 
> However, I do prefer splash4 (with modified fonts) over splash7. Did 
> anyone plead for centralization ?
> The idea was just to put logo and title closer together.

No Moritz, I was only trying to put text and graphics close to each
other. But you are right, we can copy version 4 layout.


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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Glynn Clements]

Paulo van Breugel wrote:

> 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)

The main speed-up will come from "inlining" distance.mahalanobis(),
which is essentially:

delta = u - v
m = np.dot(np.dot(delta, VI), delta)
return np.sqrt(m)

np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
equivalent to np.sum(u * v), so the second line above is equivalent to

m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1), axis=-1)

Thus, delta can be extended from a 1-D array to 3-D, changing the
result from a scalar to a 2-D array. The calculation of stat_mah then
becomes:

VI = np.linalg.inv(covar)
delta = dat_ref - stat_mean[:,None,None]
m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] * 
VI[None,None,:,:],axis=-1),axis=-1)
stat_mah = np.sqrt(m)

This moves the loops from Python into C, which usually results in a
significant speed increase.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] pygrass: append new point to map of points

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Martin Landa]

Hi,

2015-01-30 15:13 GMT+01:00 Vincent Bain :
> 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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] New wiki page summarising GRASS APIs

[Moritz Lennert]

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


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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  fixed   |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by santipardo):

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


Comment:

 Now the GUI opens and it's perfectly working in locale Spanish. Thanks!!!

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by martinl):

  * status:  closed => reopened
  * resolution:  fixed =>


Comment:

 Reopening the ticket because it needs to be backported to `relbr70` before
 closing.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by martinl):

 Replying to [comment:9 martinl]:
 > Reopening the ticket because it needs to be backported to `relbr70`
 before closing.

 I tried to backport r64367 to `relbr70` in r64369. Unfortunately
 `grass.py` in trunk differs from relbr70 too much regarding language
 settings. Does anybody know more about that? I hesitate to backport the
 diff completely in hard freeze.

 Anyway, please, could you try also recent GRASS 70 release branch? It
 should have been fixed there too.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Yann Chemin]

is there a way to make a public poll online with the different versions and
send the link on GRASS-dev and GRASS-user MLs, then give a sunday midnight
close of poll?

On 30 January 2015 at 21:23, Martin Landa  wrote:

> Hi,
>
> 2015-01-30 15:13 GMT+01:00 Vincent Bain :
> > 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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Martin Landa]

2015-01-30 17:36 GMT+01:00 Yann Chemin :
> is there a way to make a public poll online with the different versions and
> send the link on GRASS-dev and GRASS-user MLs, then give a sunday midnight
> close of poll?

wiki page for voting would be enough, I would say. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Thanks! I am traveling right now so will look at this as soon as I am back,
but this looks promising. Much appreciated.

On Fri, 30 Jan 2015 15:40 Glynn Clements  wrote:

>
> Paulo van Breugel wrote:
>
> > 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)
>
> The main speed-up will come from "inlining" distance.mahalanobis(),
> which is essentially:
>
> delta = u - v
> m = np.dot(np.dot(delta, VI), delta)
> return np.sqrt(m)
>
> np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
> equivalent to np.sum(u * v), so the second line above is equivalent to
>
> m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1),
> axis=-1)
>
> Thus, delta can be extended from a 1-D array to 3-D, changing the
> result from a scalar to a 2-D array. The calculation of stat_mah then
> becomes:
>
> VI = np.linalg.inv(covar)
> delta = dat_ref - stat_mean[:,None,None]
> m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] *
> VI[None,None,:,:],axis=-1),axis=-1)
> stat_mah = np.sqrt(m)
>
> This moves the loops from Python into C, which usually results in a
> significant speed increase.
>
> --
> Glynn Clements 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

OK Martin, your sum up is appreciable.

The first one cannot be used, in cause the license attached to the font,
I am guilty not to have cleaned the wiki page in time. I'll propose a
similar typeface to replace it.

I try to make a last suggestion tonight.

Vincent.

Le vendredi 30 janvier 2015 à 16:53 +0100, Martin Landa a écrit :
> Hi,
> 
> 2015-01-30 15:13 GMT+01:00 Vincent Bain :
> > 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
> 


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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Martin Landa]

Hi Vincent,

2015-01-30 17:41 GMT+01:00 Vincent Bain :

[...]

> I try to make a last suggestion tonight.

thanks for your hard work!!! Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

 On Fri, 30 Jan 2015 10:59 Moritz Lennert 
wrote:

On 29/01/15 18:30, Paulo van Breugel wrote:
> 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)

There's probably ways to accelerate this in Python (maybe you can try
rewriting your for-loops as map() calls), but on the Wikipedia page on
mahalanobis distance that you reference [1], it says that:

"Along each principal component axis, it measures the number of standard
deviations from P to the mean of D. If each of these axes is rescaled to
have unit variance, then Mahalanobis distance corresponds to standard
Euclidean distance in the transformed space."

Couldn't you use i.pca to calculate principal components and then
calculate distances of points in that space ?

Just brainstorming...

 Interesting thought. I will see if I can work that one out. Thanks!


Moritz

[1] http:// 
en.wikipedia.org /wiki/
Mahalanobis
_distance

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Nikos Alexandris]

Vincent, is this beautiful 3D-scene available for others to experiment 
with?


Nikos

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Martin Landa]

2015-01-30 17:38 GMT+01:00 Martin Landa :
> 2015-01-30 17:36 GMT+01:00 Yann Chemin :
>> is there a way to make a public poll online with the different versions and
>> send the link on GRASS-dev and GRASS-user MLs, then give a sunday midnight
>> close of poll?
>
> wiki page for voting would be enough, I would say. Martin

http://grasswiki.osgeo.org/wiki/Talk:Identity#Voting

(not open yet)

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by santipardo):

 Not working yet after compiling release branch r64369:


 {{{
 Welcome to GRASS GIS 7.0.0svn (r64369)

 Launching  GUI in the background, please wait...
 Traceback (most recent call last):
   File "./grass70", line 1462, in 
 bash_startup()
   File "./grass70", line 1122, in bash_startup
 _("3D raster MASK present")))
 UnicodeEncodeError: 'ascii' codec can't encode character u'\xc1' in
 position 176: ordinal not in range(128)
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

Naturally, it is a blender scene rendered with Cycles engine.

It is a bit tricky to use if you don't know Blender; for those familiar
with Blender it involves a particle system where density is controled by
vertex groups. Everything else is very basic if you are at ease with
node editor (for materials).

Here is the file :
http://lesfavrets.fr/telec/grass_world.blend


Le vendredi 30 janvier 2015 à 18:48 +0200, Nikos Alexandris a écrit :
> Vincent, is this beautiful 3D-scene available for others to experiment 
> with?
> 
> Nikos
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by martinl):

 Replying to [comment:11 santipardo]:
 > Not working yet after compiling release branch r64369:

 OK, I took liberty to sync `set_language()` functions with try. Please try
 out r64370.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by santipardo):

 Recompiled from r64370 and working now. The /etc/VERSIONNUMBER doesn't
 update, it remains "7.0.0svn r64369" (I don't know if there's a little bug
 here, or it's only a problem in my system).

 But it works!

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)

[GRASS GIS]

#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale 
(UnicodeEncodeError)
-+--
  Reporter:  santipardo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  blocker |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  fixed   |Keywords:  locale   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by martinl):

  * status:  reopened => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:13 santipardo]:
 > Recompiled from r64370 and working now. The /etc/VERSIONNUMBER doesn't
 update, it remains "7.0.0svn r64369" (I don't know if there's a little bug
 here, or it's only a problem in my system).

 you need to run `configure` script to update revision number.

 > But it works!

 Thanks for testing, closing ticket.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Michael Barton]

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)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Jan 30, 2015, at 9:41 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

From: Martin Landa mailto:landa.mar...@gmail.com>>
Cc: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
To: Vincent Bain mailto:b...@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 
mailto:b...@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Michael Barton]

This is sort of beginning to sound like what we already have. That is, we have 
a button on the web site that downloads a demo data set that is already 
organized in a location and mapset.

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 Jan 30, 2015, at 3:19 AM, Rainer M Krug  wrote:
> 
> Yann Chemin  writes:
> 
>> +1 for a button, but I am not sure sure a data download is that
>> necessary...
> 
> I think a download button would be useful as the demo location should be
> in the home directory so that the user can play with it.
> 
> The disadvantage would be that the user has to be online for this. A
> compromise could be to have
> 
> a) an archived location in package form, so that the archive is
>   installed but not the location. This would be an optional package.
> 
> b) A button which, depending on whether the grass-demodata package has been
>   installed, extracts the archived location into the home directory or,
>   if it has not been installed, suggests to download it.
> 
> Cheers,
> 
> Rainer
> 
>> The button might just be a script creating a (several?) empty Location(s?)
>> in a directory that the user can choose.
> 
> 
> 
>> 
>> 
>> 
>> On 30 January 2015 at 15:20, Moritz Lennert 
>> wrote:
>> 
>>> On 29/01/15 17:43, Vaclav Petras wrote:
>>> 
 On the MS Windows installer takes care of that by copying demo Location
 to newly created grassdata dir in Documents and creating the rc file. Is
 this enough? If not why? And do we want to do something similar for
 cases when installation is not done by GRASS GIS? If startup detects no
 grassdata it could just create the dir and copy the demo Location there,
 so the only thing needed is to press Start button.
 
>>> 
>>> Don't forget that in many GNU/Linux distributions data is separated from
>>> applications in the packaging. So, either we have to tell users to install
>>> a specific data package (e.g. grass-demodata) or the startup screen needs a
>>> button: "Download and unpack demo data".
>>> 
>>> Moritz
>>> 
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>> 
> 
> -- 
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982

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

Re: [GRASS-dev] [GRASS GIS] #2208: r.in.gdal/v.in.ogr: reprojection at import

[GRASS GIS]

#2208: r.in.gdal/v.in.ogr: reprojection at import
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  enhancement |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  unspecified 
 
 Keywords:  projection import gdal ogr  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---

Comment(by martinl):

 Replying to [comment:7 annakrat]:

 > Thanks, that's great! Eventually, this should be a core module and
 should be incorporated in the import dialog. Although the gui should be
 simple, we can still force users to actively decide the method and
 resolution.

 I absolutely agree, are you planning to do that? Thanks, Martin

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Blumentrath, Stefan]

Dear all,

I would like to support Michael`s and Nikos`s suggestions for changes in the 
descriptions on the welcome screen in trunk, as I think careful and 
well-thought-out wording will be an important means of "Making start of GRASS 
GIS easier for newcomers".

On courses here at the University of Oslo, I saw people creating a new gisdbase 
folder - in anticipatory obedience - at the beginning of the second day of the 
course, because it was the first thing we did on the first day. Shortly after 
they wondered how they can access the data from the first day... Saying 
something like "There can be more than one or more directories like that on one 
machine" is technically true but does probably not reflect the concept of the 
GRASS GIS database... 
Furthermore, if that folder is predefined, people may be less tempted to create 
several gisdatabase folder on their computer.
One might even go one step further saying:

"The GRASS GIS database directory is the central place where all your GRASS GIS 
data will be stored/organized. Change the folder only for a good reason."
Also greying out the path (and not having it as an input field), as proposed by 
others earlier, could be a good idea.

As for the Location description, what about:
"A Location in GRASS is defined by a Coordinate Reference System. It is a 
subdirectory of the gisdatabase containing one or more collections of spatial 
data ("Mapsets"), which all share the Location`s CRS."
I also like this statement from the wiki: "You can think of a location as a 
data library for a region of interest."

For mapsets I do like Nikos proposal. And alike Michael I tend to compare 
mapsets with projects (and not Locations). In fact creating a location for 
every project would be counterproductive cause it would lead to fragmentation 
and data duplication... 

Markus, from your experience from your courses, are there explanations which 
usually work particularly well for newbies and people coming from other GIS?

Kind regards,
Stefan


-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Nikos Alexandris
Sent: 29. januar 2015 18:13
To: Moritz Lennert
Cc: Michael Barton; GRASS developers grass-developers
Subject: Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

On 29.01.2015 18:49, Moritz Lennert wrote:

>> ### Mapset
>>
>> "A Mapset contains GIS data. Every Location automatically has one 
>> Mapset named PERMANENT that also contains projection information for 
>> the Location."
>
> Maybe add a little about use of mapsets:
>
> "A Mapset is a subdirectory of a location and contains GIS data.
> Mapsets are used to organise the data into coherent subsets (by 
> project, user, or other systems). Every Location automatically has one 
> Mapset named PERMANENT that also contains projection information for 
> the Location."

Proposing slightly different wording:

"A Mapset is a subdirectory inside a Location and contains geospatial data. 
Mapsets are useful in organising the data into coherent subsets (by project, 
user, or other thematic units)."


> If we don't have enough space, I'd just drop the last sentence about 
> the PERMANENT mapset.
>
> [Looking at this I actually makes me think about the real need for 
> 'PERMANENT'. Couldn't the location-relevant files just be stored in 
> (possible hidden files directly in the location directory ? Or do we 
> want to keep the notion of permanent data vs modifiable data for 
> educational purpose ? Then again, I don't really want to open 
> Pandora's box at this stage of the release process... ;-) ]

Using the PERMANENT Mapset as a safety-pool, for all of the "raw" data, isn't a 
bad idea as well. Copy then elsewhere and play along.  I do it most of the 
times.  It saves time to re-import stuff, for example, if a map is irreversibly 
modified.  Which is a matter of time to happen (and not a question of "will it 
happen?").  At the end of a project's life-cycle, stuff can be cleaned.

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

Le vendredi 30 janvier 2015 à 18:52 +, Michael Barton a écrit :
> 
> Since this combination doesn’t exist, I’m not yet sure how best to
> express this on the page.

Yes, I was at that point of reflexion, then I decided to sum up things
in a 3x5 array, it will come soon -- between two power cuts and internet 
blackouts due to huge snowfall here in the Alps!

In the scope of a vote I found it was interesting to decline each layout
on every bg image I submitted.


> 
> 
> 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?

It's kind of you Michael, but I am only bringing a modest contribution
to a vaste project that does not belong to me at all...

I send a synthesis in a moment.



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

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

[GRASS GIS]

#2568: Upper-lower case issues with sqlite driver and affect on 
v.db.reconnect.all
---+
  Reporter:  ewcgrass  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  7.0.0
 Component:  Database  | Version:  svn-releasebranch70  
Resolution:  fixed |Keywords:   
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by ewcgrass):

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


Comment:

 Thanks for solving this so quickly. I missed that entirely because having
 different key column names never negatively affected doing work with the
 vector file attribute data in GRASS 6.4. Running v.db.connect map= key=cat
 in GRASS 6.4 before migrating fixes the problem, as it does running
 v.db.connect map= key=CAT in GRASS 7.0 after migrating from .dbf to
 sqlite!

 v.db.reconnect.all still hangs at every other database error it encounters
 during migration (eg. syntax issues re. column names vs sqlite keywords,
 quotes or squiggles in table data, dropping columns due to name length >10
 in the .dbf table which for odd reasons were never caught earlier, etc.).
 But I guess this is not all bad, as it is an opportunity to clean up
 database files? About 300 dbf tables migrations completed, about 1200 more
 to go.

 Perhaps this Ticket should be changed from a "bug" to a "wish", where
 v.db.reconnect.all could perhaps be modified to catch these migration
 errors more graciously?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2208: r.in.gdal/v.in.ogr: reprojection at import

[GRASS GIS]

#2208: r.in.gdal/v.in.ogr: reprojection at import
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  enhancement |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  unspecified 
 
 Keywords:  projection import gdal ogr  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---

Comment(by mmetz):

 Replying to [comment:16 martinl]:
 > Replying to [comment:7 annakrat]:
 >
 > > Thanks, that's great! Eventually, this should be a core module and
 should be incorporated in the import dialog. Although the gui should be
 simple, we can still force users to actively decide the method and
 resolution.
 >
 > I absolutely agree, are you planning to do that? Thanks, Martin

 There is a GUI-related issue. The two modules currently have each two
 input options, input_file and input_directory. It would be nice if these
 two options could be combined in one, key input, type string, and the GUI
 would provide an interface similar to r.in.gdal/v.in.ogr where you can
 select if you want to import a file or a directory or something from a
 database. The difference to the current r.in.gdal/v.in.ogr interface would
 be that input is only one GDAL/OGR datasource. Each GDAL/OGR datasource
 may contain several band/layers, but that is handled by
 r.in.gdal/v.in.ogr. GDAL supports currently 135 different formats, OGR 80
 different formats. Not all of them are file based, thus the need for
 flexible specification of the input datasource.

 The aim is to provide a simple yet powerful interface for users to import
 data which are (semi-)automatically reprojected if need be.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2569: Allow v.db.reconnect.all to handle database errors more graciously

[GRASS GIS]

#2569: Allow v.db.reconnect.all to handle database errors more graciously
-+--
 Reporter:  ewcgrass |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Database | Version:  unspecified  
 Keywords:   |Platform:  Linux
  Cpu:  x86-64   |  
-+--
 v.db.reconnect.all appears to stop at every database error it encounters
 during migration of database tables from .dbf to sqlite (and likely others
 too). While this provides a great opportunity to clean up incorrect
 database tables, it destroys work flow.

 It would be nice if flags could be added to allow v.db.reconnect.all to
 skip errors and list them, while continuing to process the rest of the
 database tables in the mapset. Then those tables which caused the errors
 could be more easily audited and repaired.

 This would be extremely useful for the numerous vector file migrations
 that are necessary from GRASS 6.x to 7.0, but it may be too late to
 incorporate it into version 7.0 at this time, which is why I suggest it as
 something for version 7.1 or later.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Vincent Bain]

Le vendredi 30 janvier 2015 à 21:24 +0100, Vincent Bain a écrit :
> 
> I send a synthesis in a moment.
> 
> 

There it is :

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

Bye,
Vincent

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

Re: [GRASS-dev] New wiki page summarising GRASS APIs

[Markus Neteler]

Hi Moritz,

On Fri, Jan 30, 2015 at 5:02 PM, Moritz Lennert
 wrote:
> 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,

Quick comment just on the C part:
I think that using system calls in C is not good to show, shouldn't is
be rather these functions?

http://grass.osgeo.org/programming7/get__window_8c.html

Best from Brussels,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Markus Neteler]

On Fri, Jan 30, 2015 at 1:35 PM, Yann Chemin  wrote:
> Continuing the crazy thoughts,
> You could have FFT/wavelet parameters per column of a raster image
> hard-coded to create an image on request (that I could do I think).

... r.surf.fractal does this... but:

> About a
> vector, well a set of polygon arcs pairs can easily be stored in code and (i
> suppose) imported on the fly as a vector.

... but in times of open data it sounds strange to me to randomly generate data.
You can then not even reproduce the same results. I would definitely
stick to real data as already included in the demolocation.

just my 0.02 cents,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Nikos Alexandris]

Yann Chemin:


Continuing the crazy thoughts,
You could have FFT/wavelet parameters per column of a raster image
hard-coded to create an image on request (that I could do I think).


Markus Neteler wrote:


... r.surf.fractal does this... but:



About a
vector, well a set of polygon arcs pairs can easily be stored in 
code and (i

suppose) imported on the fly as a vector.


... but in times of open data it sounds strange to me to randomly 
generate data.

You can then not even reproduce the same results. I would definitely
stick to real data as already included in the demolocation.


Indeed, reproducibility is a key point.  I think there is a way to 
force reproducible "random" data. As like it is done with seed values 
(in Python, and R, for example).  In any case, it was just an idea to 
get people without access to the net, and with near-zero background, 
past the first steps.


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