[GRASS-dev] dateutil dependency killing GRASS 7

[Michael Barton]

A couple of things here.

1. We need to be able to bundle dateutil or to have it bundled with Mac 
frameworks. Otherwise, temporal GIS doesn't work apparently.
2. The lack of dateutil for TGIS should not shut down the entire GUI. This is a 
serious problem. It could make part or all of TGIS not functional, but it is 
NOT needed for anything else. So it should not kill the entire interface. It 
needs to be walled off somehow.
3. I thought that adding new dependencies was something that should be brought 
up in the dev group, at the very least to make everyone aware of it.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

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











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

Re: [GRASS-dev] [GRASS GIS] #1692: calling a script within a script failing on Windows XP

[GRASS GIS]

#1692: calling a script within a script failing on Windows XP
-+--
 Reporter:  hamish   |   Owner:  martinl
 
 Type:  defect   |  Status:  assigned   
 
 Priority:  blocker  |   Milestone:  6.4.3  
 
Component:  Shell Scripts| Version:  6.4.2  
 
 Keywords:  v.random.cover, wingrass, shell scripts  |Platform:  MSWindows 
XP
  Cpu:  x86-32   |  
-+--
Changes (by martinl):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => martinl
  * status:  new => assigned


-- 
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] #1692: calling a script within a script failing on Windows XP

[GRASS GIS]

#1692: calling a script within a script failing on Windows XP
-+--
 Reporter:  hamish   |   Owner:  
grass-dev@…  
 Type:  defect   |  Status:  new
  
 Priority:  blocker  |   Milestone:  6.4.3  
  
Component:  Shell Scripts| Version:  6.4.2  
  
 Keywords:  v.random.cover, wingrass, shell scripts  |Platform:  MSWindows 
XP 
  Cpu:  x86-32   |  
-+--

Comment(by martinl):

 Replying to [comment:6 hamish]:
 > > we need to fix this ASAP as it takes out a bunch of the scripts,
 > > including many of the v.db.* ones.

 It seems to me that shell scripts don't work only if there are installed
 as !AddOns. I think it's caused by the fact that shell script and bat
 script are placed in the same directory. It's result of your wish [1]
 which required extra hacking on g.extension side (it was the bad idea from
 POV) and moreover produced this blocker. It would be nice to simplify
 things and to complicated them when it's really not necessary. I hope that
 it was fixed in r53428 in G65. Please could you try the next snapshot, at
 least `v.random.cover` seems to work for me.

 Martin

 http://lists.osgeo.org/pipermail/grass-dev/2011-December/056938.html

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

On Tue, Oct 16, 2012 at 4:23 PM, Margherita Di Leo
 wrote:
> Hi Sören,
>
> On Tue, Oct 16, 2012 at 4:15 PM, Sören Gebbert
>  wrote:
>>
>> Hi,
>> i hope i do not start a flame war. :)
>>
>> 2012/10/16 Martin Landa :
>> > Hi,
>> >
>> > 2012/10/16 Vaclav Petras :
>> >> gif is a nice simple option how to present 'moving images'. It is
>> >> widely supported and we don't need any external dependency in case of
>> >> using images2gif.py. I would like to see this option even if we were
>> >> able to export a real video.
>> >
>> > agreed, Martin
>>
>> IMHO animated GIF's have so many limitations i wouldn't support it for
>> GIS related map animations at all. The results will be to horrible.
>>
>> Some arguments against it:
>> * Very small color range support: 8 bit per pixel == 256 colors for a
>> picture
>> * True color is only supported when creating 256 bit tiles in a single
>> picture,
>>   each tile can use different parts of a 24 bit RGB color space
>> * Only suitable for small animations and low-resolution film clips
>> * No control over animation frame rate/animation flow/pausing while
>> playing GIF's
>>
>>
> GIF's have also pro's, for example I use them in presentations, they usually
> are more handy to show than videos, you can just add them as images. Of
> course the option to export regular video as well, if technically possible,
> would be a plus.

The gif output would be something you get quickly and easily and it's
ideal for presentations (as Madi said). I would also export the
sequence of images to let the 'advanced' users make anything what they
want.

Anna


>
> Ciao madi
>
>
> --
> Margherita DI LEO
> Postdoctoral Researcher
> European Commission - DG JRC
> Forest Resources and Climate
> I-21020 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
>
>
>
> ___
> 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] images2gif.py in grass

[Margherita Di Leo]

Hi Sören,

On Tue, Oct 16, 2012 at 4:15 PM, Sören Gebbert  wrote:

> Hi,
> i hope i do not start a flame war. :)
>
> 2012/10/16 Martin Landa :
> > Hi,
> >
> > 2012/10/16 Vaclav Petras :
> >> gif is a nice simple option how to present 'moving images'. It is
> >> widely supported and we don't need any external dependency in case of
> >> using images2gif.py. I would like to see this option even if we were
> >> able to export a real video.
> >
> > agreed, Martin
>
> IMHO animated GIF's have so many limitations i wouldn't support it for
> GIS related map animations at all. The results will be to horrible.
>
> Some arguments against it:
> * Very small color range support: 8 bit per pixel == 256 colors for a
> picture
> * True color is only supported when creating 256 bit tiles in a single
> picture,
>   each tile can use different parts of a 24 bit RGB color space
> * Only suitable for small animations and low-resolution film clips
> * No control over animation frame rate/animation flow/pausing while
> playing GIF's
>
>
> GIF's have also pro's, for example I use them in presentations, they
usually are more handy to show than videos, you can just add them as
images. Of course the option to export regular video as well, if
technically possible, would be a plus.

Ciao madi


-- 
Margherita DI LEO
Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Martin Landa]

Hi,

2012/10/16 Sören Gebbert :
> Some arguments against it:
> * Very small color range support: 8 bit per pixel == 256 colors for a picture
> * True color is only supported when creating 256 bit tiles in a single 
> picture,
>   each tile can use different parts of a 24 bit RGB color space
> * Only suitable for small animations and low-resolution film clips
> * No control over animation frame rate/animation flow/pausing while
> playing GIF's

these limitations should be noted in the manual (please Anna), but
it's not the reason why the tool developed by Anna shouldn't support
animated GIF output. Of course support for video output is very
important, and should be implemented in some way (probably with extra
dependency, eg. mencoder or so).

Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Sören Gebbert]

Hi,
i hope i do not start a flame war. :)

2012/10/16 Martin Landa :
> Hi,
>
> 2012/10/16 Vaclav Petras :
>> gif is a nice simple option how to present 'moving images'. It is
>> widely supported and we don't need any external dependency in case of
>> using images2gif.py. I would like to see this option even if we were
>> able to export a real video.
>
> agreed, Martin

IMHO animated GIF's have so many limitations i wouldn't support it for
GIS related map animations at all. The results will be to horrible.

Some arguments against it:
* Very small color range support: 8 bit per pixel == 256 colors for a picture
* True color is only supported when creating 256 bit tiles in a single picture,
  each tile can use different parts of a 24 bit RGB color space
* Only suitable for small animations and low-resolution film clips
* No control over animation frame rate/animation flow/pausing while
playing GIF's

Best regards
Soeren

> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

Where should this script be placed? It could be a grass module,
however I need to call the writeGif function directly to avoid saving
images to disk (writeGif accepts PIL images).

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

Re: [GRASS-dev] images2gif.py in grass

[Luca Delucchi]

2012/10/16 Martin Landa :
> Hi,
>

Hi

> 2012/10/16 Vaclav Petras :
>> gif is a nice simple option how to present 'moving images'. It is
>> widely supported and we don't need any external dependency in case of
>> using images2gif.py. I would like to see this option even if we were
>> able to export a real video.
>
> agreed, Martin
>

me too...

-- 
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] images2gif.py in grass

[Martin Landa]

Hi,

2012/10/16 Vaclav Petras :
> gif is a nice simple option how to present 'moving images'. It is
> widely supported and we don't need any external dependency in case of
> using images2gif.py. I would like to see this option even if we were
> able to export a real video.

agreed, Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Martin Landa]

Hi,

2012/10/16 Sören Gebbert :
> i would prefer to convert the images in a "real" video format to avoid
> the limitations of GIF.
> Maybe you could try to use PyMedia[1],[2] (well, its pretty old) or
> utilize mencoder[3] to create the videos?

creating video output, eg. using `mencoder` could be added later
(another dependency, will not work on Windows). I would suggest to
start with something which will work on all supported platforms
without any extra dependency (which seems to be `images2gif`).

Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Vaclav Petras]

Hi Soeren,

gif is a nice simple option how to present 'moving images'. It is
widely supported and we don't need any external dependency in case of
using images2gif.py. I would like to see this option even if we were
able to export a real video.

Vaclav

On 16 October 2012 15:42, Sören Gebbert  wrote:
> Hi Anna,
> i would prefer to convert the images in a "real" video format to avoid
> the limitations of GIF.
> Maybe you could try to use PyMedia[1],[2] (well, its pretty old) or
> utilize mencoder[3] to create the videos?
>
> [1] http://pymedia.org
> [2] http://pymedia.org/tut/src/make_video.py.html
> [3] mencoder 'mf://*.png' -mf type=png:fps=10 -ovc lavc -lavcopts
> vcodec=wmv2 -oac copy -o animation.avi
>
> Best regards
> Soeren
>
> 2012/10/16 Anna Kratochvílová :
>> Hi,
>>
>> I'm currently developing new tool for animation (wxpython-based
>> replacement of wxwidgets-based xganim, coming soon to addons) and I
>> would like to include the possibility to export the animation not only
>> as a sequence of images. It seems to me that the easiest possibility
>> is to use script images2gif.py [1] for creating animated gif, which is
>> under BSD license. Would it be possible to have it in grass?
>>
>> Thanks,
>> Anna
>>
>> [1] http://visvis.googlecode.com/hg/vvmovie/images2gif.py
>> ___
>> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Margherita Di Leo]

Hi Luca

On Tue, Oct 16, 2012 at 3:41 PM, Luca Delucchi  wrote:

> 2012/10/16 Margherita Di Leo :
> > Ahoj Anna,
> >
>
> Hi
>
> >
> > As far as I can undestand, the BSD license is not fully compatible with
> GPL
> > unless it is either the New BSD License/Modified BSD License or the
> > Simplified BSD License/FreeBSD License, which have been verified as GPL
> > compatible by FSF [1]. Maybe you could consider to use ImageMagik
> instead,
> > which is released under Apache 2 license, which seems compatible with
> GPL3
> > [3].
> > Anyhow I'm not an expert and maybe someone may correct me if I'm wrong.
> >
>
> Yes you are wrong...


Yes you are right and I'm happy to be wrong, I completely missed the (new)
.. :D


> Your first link answer the question, "New"  BSD
> is compatible with GPL, Anna you can use images2gif.py
>
> > Thanks,
> >
> > madi
> >
> >
> > [1] http://en.wikipedia.org/wiki/BSD_licenses
> > [2] http://www.imagemagick.org/script/license.php
> > [3] http://www.apache.org/licenses/GPL-compatibility.html
> >>
> >>
> >
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
>



-- 
Margherita DI LEO
Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] images2gif.py in grass

[Sören Gebbert]

Hi Anna,
i would prefer to convert the images in a "real" video format to avoid
the limitations of GIF.
Maybe you could try to use PyMedia[1],[2] (well, its pretty old) or
utilize mencoder[3] to create the videos?

[1] http://pymedia.org
[2] http://pymedia.org/tut/src/make_video.py.html
[3] mencoder 'mf://*.png' -mf type=png:fps=10 -ovc lavc -lavcopts
vcodec=wmv2 -oac copy -o animation.avi

Best regards
Soeren

2012/10/16 Anna Kratochvílová :
> Hi,
>
> I'm currently developing new tool for animation (wxpython-based
> replacement of wxwidgets-based xganim, coming soon to addons) and I
> would like to include the possibility to export the animation not only
> as a sequence of images. It seems to me that the easiest possibility
> is to use script images2gif.py [1] for creating animated gif, which is
> under BSD license. Would it be possible to have it in grass?
>
> Thanks,
> Anna
>
> [1] http://visvis.googlecode.com/hg/vvmovie/images2gif.py
> ___
> 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] images2gif.py in grass

[Luca Delucchi]

2012/10/16 Margherita Di Leo :
> Ahoj Anna,
>

Hi

>
> As far as I can undestand, the BSD license is not fully compatible with GPL
> unless it is either the New BSD License/Modified BSD License or the
> Simplified BSD License/FreeBSD License, which have been verified as GPL
> compatible by FSF [1]. Maybe you could consider to use ImageMagik instead,
> which is released under Apache 2 license, which seems compatible with GPL3
> [3].
> Anyhow I'm not an expert and maybe someone may correct me if I'm wrong.
>

Yes you are wrong... Your first link answer the question, "New"  BSD
is compatible with GPL, Anna you can use images2gif.py

> Thanks,
>
> madi
>
>
> [1] http://en.wikipedia.org/wiki/BSD_licenses
> [2] http://www.imagemagick.org/script/license.php
> [3] http://www.apache.org/licenses/GPL-compatibility.html
>>
>>
>

-- 
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] images2gif.py in grass

[Margherita Di Leo]

Ahoj Anna,

On Tue, Oct 16, 2012 at 3:20 PM, Anna Kratochvílová
wrote:

> Hi,
>
> I'm currently developing new tool for animation (wxpython-based
> replacement of wxwidgets-based xganim, coming soon to addons) and I
> would like to include the possibility to export the animation not only
> as a sequence of images.


Wow, looks a great addition.


> It seems to me that the easiest possibility
> is to use script images2gif.py [1] for creating animated gif, which is
> under BSD license. Would it be possible to have it in grass?
>

As far as I can undestand, the BSD license is not fully compatible with GPL
unless it is either the New BSD License/Modified BSD License or the
Simplified BSD License/FreeBSD License, which have been verified as GPL
compatible by FSF [1]. Maybe you could consider to use ImageMagik instead,
which is released under Apache 2 license, which seems compatible with GPL3
[3].
Anyhow I'm not an expert and maybe someone may correct me if I'm wrong.

Thanks,

madi


[1] http://en.wikipedia.org/wiki/BSD_licenses
[2] http://www.imagemagick.org/script/license.php
[3] http://www.apache.org/licenses/GPL-compatibility.html

>
>

-- 
Margherita DI LEO
Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.net.allpairs seems broken

[Michael Barton]

Fixing this makes the module usable. The flaw is near to a bug.

+1

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

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



On Oct 16, 2012, at 4:12 AM, Moritz Lennert 
 wrote:

> Or we decide to break the rule to not change options and backport the 
> alayer/nlayer patches from grass 7 to grass 6, as it is such an obvious 
> design flaw compared to the general logic of the v.net.* modules.
> 
> What do you think ?

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

[GRASS-dev] images2gif.py in grass

[Anna Kratochvílová]

Hi,

I'm currently developing new tool for animation (wxpython-based
replacement of wxwidgets-based xganim, coming soon to addons) and I
would like to include the possibility to export the animation not only
as a sequence of images. It seems to me that the easiest possibility
is to use script images2gif.py [1] for creating animated gif, which is
under BSD license. Would it be possible to have it in grass?

Thanks,
Anna

[1] http://visvis.googlecode.com/hg/vvmovie/images2gif.py
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] working on a add on to calculate MESS

[Paulo van Breugel]

HI,

Hi Martin, thanks for the info. Only reason it is in grass 7 is because
that is what I use (I find it works better for me than grass64). I can move
it to grass 6, I probably need to make one or two small changes first
(separator tag).

Although I appreciate that the preferred language is Python, is it in the
plans to make it possible to install shell extensions using g.extension
later on? For me, I unfortunately I don't know Python, and although I would
love to work in Python, I simply do not have the time at the moment :-(

Cheers,

Paulo


On Tue, Oct 16, 2012 at 1:37 PM, Martin Landa wrote:

> Hi,
>
> 2012/10/16 Paulo van Breugel :
> > Thanks, I just uploaded the r.mess script to the
> grass-addons/grass7/raster.
> > Any feedback is most welcome (adherence to grass and bash scripts coding
> > standards is probably one of the thing to check as I am completely new to
> > this).
>
> please bear in mind that your scripts cannot be currently installed in
> GRASS 7 via g.extension. Building system of GRASS 7 doesn't support
> Shell scripts [1]. Your script really requires GRASS 7? If not,
> probably you should move your script to addons/grass6. Preferable
> scripting language for GRASS 7 is Python not Bash.
>
> Martin
>
> [1] http://grass.osgeo.org/addons/grass7/logs/r.mess.log
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] working on a add on to calculate MESS

[Martin Landa]

Hi,

2012/10/16 Paulo van Breugel :
> Thanks, I just uploaded the r.mess script to the grass-addons/grass7/raster.
> Any feedback is most welcome (adherence to grass and bash scripts coding
> standards is probably one of the thing to check as I am completely new to
> this).

please bear in mind that your scripts cannot be currently installed in
GRASS 7 via g.extension. Building system of GRASS 7 doesn't support
Shell scripts [1]. Your script really requires GRASS 7? If not,
probably you should move your script to addons/grass6. Preferable
scripting language for GRASS 7 is Python not Bash.

Martin

[1] http://grass.osgeo.org/addons/grass7/logs/r.mess.log

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] grass wiki - subpages

[Vaclav Petras]

Hi all,

On 16 October 2012 12:20, Markus Neteler  wrote:
> On Tue, Oct 16, 2012 at 11:58 AM, Martin Landa  wrote:
>> Hi all,
>>
>> 2012/10/13 Martin Landa :
>>
>>> I have enabled subpages [1] in our mediawiki, eg.
>>>
>>> http://grass.osgeo.org/wiki/WxGUI/Map_Swipe
>>
>> you can put also spaces around slash, it's seems to be more readable
>> for me as the title of the page. On the other hand URL is not so nice.
>>
>> http://grass.osgeo.org/wiki/AddOns/GRASS_7/imagery
>>
>> vs.
>>
>> http://grass.osgeo.org/wiki/AddOns_/_GRASS_7_/_imagery
>>
>> What you would prefer?
>
> To me the white spaces look terrible :) ... and ruin the nice urls.
>
> Markus

...and without slashes the page title is harder to read for me.

In any case, I think that is good to have subpage feature available,
so thank you Martin. But I would prefer to use categories as default
option for organization. Even the mediawiki description of subpages
[1] says that:

Subpages are useful for organising information hierarchically. On the
other hand, subpages tend to have a long name that is hard to
remember, so it may be more user-friendly to use them as little as
possible. You can also organize pages with the category feature, which
is more suitable for creating a hierarchical network of information.

The main question for me is for what we want to use subpages?

(Sorry for this basic question but I'm not much familiar with mediawiki.)

Vaclav

[1] http://www.mediawiki.org/wiki/Help:Subpages#Use_of_subpages
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass wiki - subpages

[Markus Neteler]

On Tue, Oct 16, 2012 at 11:58 AM, Martin Landa  wrote:
> Hi all,
>
> 2012/10/13 Martin Landa :
>
>> I have enabled subpages [1] in our mediawiki, eg.
>>
>> http://grass.osgeo.org/wiki/WxGUI/Map_Swipe
>
> you can put also spaces around slash, it's seems to be more readable
> for me as the title of the page. On the other hand URL is not so nice.
>
> http://grass.osgeo.org/wiki/AddOns/GRASS_7/imagery
>
> vs.
>
> http://grass.osgeo.org/wiki/AddOns_/_GRASS_7_/_imagery
>
> What you would prefer?

To me the white spaces look terrible :) ... and ruin the nice urls.

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

Re: [GRASS-dev] grass wiki - subpages

[Martin Landa]

Hi all,

2012/10/13 Martin Landa :

> I have enabled subpages [1] in our mediawiki, eg.
>
> http://grass.osgeo.org/wiki/WxGUI/Map_Swipe

you can put also spaces around slash, it's seems to be more readable
for me as the title of the page. On the other hand URL is not so nice.

http://grass.osgeo.org/wiki/AddOns/GRASS_7/imagery

vs.

http://grass.osgeo.org/wiki/AddOns_/_GRASS_7_/_imagery

What you would prefer?

Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1764: Map Swipe - Add option to export the display to graphics file (PNG)

[GRASS GIS]

#1764: Map Swipe - Add option to export the display to graphics file (PNG)
--+-
 Reporter:  voncasec  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  Map Swipe, wxGUI  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Thanks for your interest. I added this functionality in r53419, however it
 is not possible to choose the image size (as with Map Display) because I
 was not able to preserve the accurate positon of the line between the two
 maps for larger images.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] working on a add on to calculate MESS

[Paulo van Breugel]

Hi Helmut,

Thanks, I just uploaded the r.mess script to the
grass-addons/grass7/raster. Any feedback is most welcome (adherence to
grass and bash scripts coding standards is probably one of the thing to
check as I am completely new to this).

Paulo



On Mon, Oct 15, 2012 at 6:36 PM, Helmut Kudrnovsky  wrote:

> Hi Paulo,
>
> your osgeo id should be activated now.
>
> happy hacking
> Helmut
>
>  *Gesendet:* Montag, 15. Oktober 2012 um 13:34 Uhr
>
> *Von:* "Paulo van Breugel" 
> *An:* grass-...@lists.osgeo.org
> *Cc:* "Helmut Kudrnovsky" 
> *Betreff:* Re: Re: [GRASS-dev] working on a add on to calculate MESS
>  Hi
>
> I am working on a shell script to calculate the multi-environmental
> similarity surface (MESS), which represents how similar a point is to a
> reference set of points, with respect to a set of predictor variables (V1,
> V2, ...) (Elith, J., Kearney, M., & Phillips, S. 2010. The art of modelling
> range-shifting species. Methods in Ecology and Evolution 1: 330–342.).
>
> It would be great if I could get some feedback and to add it to the addon
> wiki eventually. Following the suggestion of Helmut, it would be good if I
> could add it to the GRASS-Addons-SVN repository. I therefore would like
> to request write access to the GRASS-Addons-SVN repository. I have read
> and understood the RFC2. My osgeo id is pvanbosgeo.
>
> Cheers,
>
> Paulo
>
>
>
> On Mon, Oct 15, 2012 at 12:45 PM, Helmut Kudrnovsky  wrote:
>
>>
>> Hi Paulo,
>>
>> please post it in the GRASS PSC-ML [1], so it's getting official.
>>
>>
>> all the best
>> Helmut
>>
>> [1] http://lists.osgeo.org/mailman/listinfo/grass-psc
>>
>>
>>  *Gesendet:* Sonntag, 14. Oktober 2012 um 13:21 Uhr
>> *Von:* "Paulo van Breugel" 
>> *An:* "Helmut Kudrnovsky" 
>> *Betreff:* Re: [GRASS-dev] working on a add on to calculate MESS
>>  Hi Helmut
>>
>> I have no problem having it in add-ons. That requires write access to
>> the GRASS-Addons-SVN repository, for which I have to
>> [v] contact a GRASS developer [doing that right now ;-)]
>> [v] I have read and understood the RFC2.
>> [v] My osgeo id is pvanbosgeo
>>
>> Cheers,
>>
>> Paulo
>>
>>
>>
>> On Sat, Oct 13, 2012 at 2:43 PM, Helmut Kudrnovsky  wrote:
>>
>>> >I would also like to know what else is needed in case I want to add it
>>> to
>>> the addon wiki.
>>>
>>> see
>>> http://grass.osgeo.org/wiki/GRASS_AddOns#Adding_something_new
>>>
>>> http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository
>>>
>>> it would be nice to have it in the addons, so nothing is getting lost in
>>> the
>>> mailing list and it's easier for other's contribution
>>>
>>>
>>>
>>> -
>>> best regards
>>> Helmut
>>> --
>>> View this message in context:
>>> http://osgeo-org.1560.n6.nabble.com/working-on-a-add-on-to-calculate-MESS-tp5008400p5008405.html
>>> Sent from the Grass - Dev mailing list archive at Nabble.com.
>>> ___
>>> 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] v.net.allpairs seems broken

[Moritz Lennert]

On 08/10/12 18:18, Moritz Lennert wrote:

On 08/10/12 18:09, Markus Metz wrote:



I agree. Even though I regard the output of v.net.allpairs in GRASS 6
as nearly unusable, the memory allocation error should be fixed, which
would be a separate ticket.


I'll try to find the time to write a nice reproducible bug...


Well, actually, the error only appears in 6.4.2, but not in 6.4 release 
branch. Here's what I did:


v.category schools_wake out=schools op=sum cat=5
v.net streets_wake points=schools op=connect thresh=200 out=network nlayer=1
v.net.allpairs network cats=5-50167 out=allpairs

Works fine relase branch, but in 6.4.2 I get:

Flattening the graph...
Graph was built
ERROR: G_calloc: unable to allocate 42122 * 4 bytes at main.c:173

But, not worth filing a ticket as it already seems solved.

However, we should probably put a hint into the v.net man page and/or 
the relevant modules man pages that all modules that were coded by 
Daniel do not differentiate alayer and nlayer in the grass6 line and so 
you have to differentiate them by cat numbers in the map.


Or we decide to break the rule to not change options and backport the 
alayer/nlayer patches from grass 7 to grass 6, as it is such an obvious 
design flaw compared to the general logic of the v.net.* modules.


What do you think ?

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

Re: [GRASS-dev] [GRASS GIS] #1745: proposal: make -a flag the default behaviour for g.region

[GRASS GIS]

#1745: proposal: make -a flag the default behaviour for g.region
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Default  | Version:  svn-trunk
Resolution:  wontfix  |Keywords:  g,region 
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by mlennert):

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


Comment:

 Replying to [comment:1 hamish]:
 > > I always find myself in difficulties having to explain to students
 > > why GRASS' default behaviour is the way it is...
 >
 > Consider importing a grid-referenced dataset from 3rd party enviro model
 output:
 >
 > `g.region n=100025 s=49975 w=69975 e=120025 res=50`
 [...]
 > (I don't know about anyone else, but I have to deal with this all the
 time when importing various ocean model data)

 Ok, just wasn't aware of such use cases. Closing this as won't fix.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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