[GRASS-dev] Re: Grass Architecture overview

[Margherita Di Leo]

Hello Sudeep,

maybe [0] could be useful.

Good luck,

madi

[0] http://grass.osgeo.org/programming7/


> From: Sudeep Singh 
> To: grass-dev@lists.osgeo.org
> Date: Mon, 30 May 2011 16:27:29 +0530
> Subject: [GRASS-dev] Grass Architecture overview
> Hi,
>
> I wanted to know if a detailed description of grass Architecture is
> available ? . Also, what will be the useful documentation helpful to start
> with editing the source for WxGUI.
>
> Thanks and regards
> Sudeep
>
>
>
-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 2 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

[Margherita Di Leo]

Hi All,

this is to inform you about updates in my GSoC project.

== Work done during week 2 ==

During current week

* I studied some of the r.stream modules to be managed by the GUI. The idea
is to manage the hydrological study in two steps, as detailed on my
project's wiki page [0].
* I opened a repository on github [1] in order to upload my helloworlds and
the pieces of code that currently can be run standalone. My very first
helloworld in wxpython has been committed and I have to say that the first
approach to wx has been soft (i.e. not traumatic yet ;-) ). That's joke, I'm
starting to have fun.

== Work to do in week 3 ==

In the next week i plan

* to learn more functionalities of wxpython, i.e. how to manage tabs,
previews of images from a folder etc.
* to keep studying r.stream modules, in order to plan how the GUI shall
manage the tasks.
* to keep my project's wiki page up-to-date.

Regards,

madi


[0] http://grass.osgeo.org/wiki/Wx.stream_gsoc2011#Bulletin_Board
[1] https://github.com/madi

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 3 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

[Margherita Di Leo]

Hi all,

in the current week I've not been able to dedicate time at my project
because I had to prepare my third year PhD exam. I did it yesterday and went
fine, so in the coming week I will dedicate most of my effort to go ahead in
my project.

Regards

madi

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: Weekly reports #2 wxNviz

[Margherita Di Leo]

>
>
> -- Forwarded message --
> From: Moritz Lennert 
> To: "Anna Kratochvílová" 
> Date: Fri, 10 Jun 2011 15:34:57 +0200
> Subject: Re: [GRASS-dev] Weekly reports #2 wxNviz
> On 10/06/11 15:03, Anna Kratochvílová wrote:
>
>>
>>   Původní zpráva 
>>> Od: Moritz Lennert 
>>> Předmět: Re: [GRASS-dev] Weekly reports #2 wxNviz
>>> Datum: 10.6.2011 14:48:44
>>> --**--
>>> On 10/06/11 14:02, Anna Kratochvílová wrote:
>>> > Hi,
>>> >
>>> > 1) What do I have completed this week?
>>> >
>>> > I changed the layout of view page. I added cutting planes
>>> functionality, I'm
>>> considering
>>> > changing the XY control, but I'm not sure how it should look like yet.
>>> >
>>>
>>> Thank you for the great work. I just updated my source and reompiled
>>> and trying to launch 3d view immediately crashes the entire GUI,
>>> without any error message on the console. I tried with export
>>> WX_DEBUG=5, but still not message. Any hints how I could debug this to
>>> get some idea why this is happening ?
>>>
>>> Moritz
>>>
>>>
>>>
>>>
>> Sorry, I have no idea what's happening. What platform do you use and
>> which data have you loaded?
>> By me everything is OK. I tried it on two computers (both Ubuntu).
>>
>
> I'm running this on Debian stable, with wx 2.8.10.1. I just noticed that I
> have a similar problem with the wxgui digitizer: launch digitization of a
> new map, select points, click to digitize point -> crash. Same with lines:
> the crash occurs when I right-click to finish the line.
>
> But, at this stage, I'm not looking for a solution (obviously if someone
> has one off the hand, perfect), but for a way to debug this with meaningful
> messages instead of a silent crash without any visible trace...
>
> Moritz
>
>
>
On my Debian stable it works fine.

madi

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 4 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

[Margherita Di Leo]

Hi All,

this is to inform you about progress in my soc project. I spent most of my
time studying the reference book of wxpython [0] and reproducing exercises.
With Jarek, we completely re-designed the GUI, details here [1].
Any comment welcome.

Regards,

madi


[0] http://wiki.wxpython.org/wxPythonInAction
[1] http://grass.osgeo.org/wiki/Wx.stream_GSoC_2011#Bulletin_Board

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GUI architecture in G7

[Margherita Di Leo]

Hi,

I am trying to figure out the architecture of the main wxGUI in G7. My aim
is to add "Network Modeling" in the Layer Manager menubar, under Layer
Manager -> Raster -> Hydrologic Modeling. I looked into [0], but clicking
"GUI" and "Interfaces" gives me "404 Not Found" error. So, I am trying to
figure out the architecture by tracking back the variable names, and
discovered that I probably should add the string "Network Modeling" in the
file file gui/wxpython/menustring.py but I still don't have clear where I
should add the third level menu, the event and the binding function ..  I
feel a bit lost.

Also, I don't understand where is located the wxGUI for each command. I
mean, for example typing r.watershed in the terminal raises the GUI.. where
is it written? I am sorry if I ask probably silly questions, but could
anyone kindly address me where I can learn more about that? So far I have
scripted just for grass 6.5 and it is fairly different to programming on G7,
so any hints are very welcome.
Thanks

madi


[0] http://grass.osgeo.org/programming7/index.html

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

Office: +39-0971205360
Web page:
http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC Week 5 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

[Margherita Di Leo]

Hi all,

I am in delay with my project, this is due to the fact that I am used to
code in python in procedural way and now I am facing the object oriented, or
better, the "event oriented" way. I am studying the Wxpython reference book
and I am learning a lot. I am not giving up at all!!

I also need a little help from you devs to solve some issues.

In the Layer Manager I have added "Network Modeling" under Raster ->
Hydrologic Modeling. This command should raise the GUI of wx.stream. When
user has filled every box dialogs, he/she should select a point on Map
Display and click a button in wx.stream called "update preview", in order to
see the preview over a small region. If user doesn't select any point and
clicks the button, raises a warning message like "please select a point on
the map display". When the point is selected, ad the parameters are
correctly inserted, the wx.preview GUI raises (this should be a second
independent module). It shows an image browser and a bigger image display.
User can click over an image in the image browser and the image is displayed
in the bigger frame. User can change the parameters in wx.stream GUI and
then clicking the same button "update preview" a new image is generated in
the preview image browser and can be selected to be displayed.

Preview widget, as Hamish suggested, should be as general as possible, so it
can be used by all commands instead of just r.stream. Preview widget IMHO
should generate png images stored in a temp folder. And here are my issues.

1) First problem is that input of preview widget are passed by r.stream GUI
(as a command line, so actually a string), and by Map Display (as a point,
actually a tuple). String can be processed by preview GUI using
os.system(cmd), BUT in order to convert the output of the command in a png
file and to export it in the temporary folder, it is necessary to know the
name of the output map that has to be exported. Output has a name given by
user and passed as string (actually parsing a command line is not big deal,
but problem is how to recognize output name, because every command has
different name for output, it's not always output = something, but can be
acc = something for instance). And also:

2) How to convert the output of the command in a png file and how to export
it in the temporary folder in G7? In grass 6.5 I simply would do:

grass.run_command( 'd.mon', start = 'x0' )
grass.run_command( 'd.rast', map = 'sc_elev' )
grass.run_command( 'd.out.file', output = os.path.join(fpath, prefix +
'_elevation'), format = 'png', resolution = 2, flags = 't' )

Thanks for any suggestion..

madi

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

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

[GRASS-dev] GSoC Week 6 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS

[Margherita Di Leo]

Hi all,

this week I didn't work at my SoC project because I have been involved in
the organization of a Summer School in Surface Hydrological Processes [0].
In the coming week I will have more time to work at SoC.

Cheers,

madi

[0] http://www.unibas.it/utenti/manfreda/SSSHP2011.htm

-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

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

[GRASS-dev] Problem georeferencing vectors with g.gui.gcp

[Margherita Di Leo]

Hi,

I have a group of vectors to georeference, but can't create a group of
vectors using g.gui.gcp.
At the first menu: Select map type and location/mapset, i successfully
select vector radio button and location and mapset.
At the next menu, i have to create the group, but the menu is partly not
responsive. In the field 'select group' I can't neither write nor browse
any options. If I add vector maps to group (but i guess first i have to
name/create a group) I can pick the layers that i want to add, but they are
not added to anything, the 'next' button is grey and can't be pushed, and
in the terminal appears:

Traceback (most recent call last):
  File "/usr/local/grass-7.1.svn/gui/wxpython/gcp/manager.py", line 529, in
OnVGroup
dlg.MakeVGroup()
  File "/usr/local/grass-7.1.svn/gui/wxpython/gcp/manager.py", line 2262,
in MakeVGroup
f = open(self.vgrpfile, mode='w')
IOError: [Errno 2] No such file or directory:
'/home/madi/grassdata/non_georef/PERMANENT/group/VREF'

If I go on create/edit group, in the field 'select existing group or enter
name of new group' I write a name, then 'select all' - 'add' opens a menu
in which i can't select 'vector' but only raster. I guess i should be able
to select vector because there is an arrow down to the raster option, but
raster is the only option i can actually select. I find it counter
intuitive since i have already made the choice in the previous menus
between raster and vectors. However, from this menu I get stuck, if i push
apply, with select all option, I get the strange message of 'no raster maps
selected'. (why raster?). In the end, I'm not able to create a group of
vector.

Perhaps I'm missing something?

Tested it on grass 7.1.svn (r65171) on Fedora.

Thank you in advance
Cheers,


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

Re: [GRASS-dev] Problem georeferencing vectors with g.gui.gcp

[Margherita Di Leo]

Markus,

On Sun, Jun 12, 2016 at 5:41 PM, Markus Neteler  wrote:

> On Sat, Jun 11, 2016 at 10:10 PM, Margherita Di Leo 
> wrote:
> ...
> > Tested it on grass 7.1.svn (r65171) on Fedora.
>
> Your version is from May 1, 2015
> (
> https://trac.osgeo.org/grass/timeline?from=2015-05-01T03%3A25%3A58-07%3A00&precision=second
> ),
> i.e. 14 months ago.
>
> Any chance to update first?
>

Thanks for looking into this. I updated to the latest version but there is
no difference



> Markus
>



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

Re: [GRASS-dev] Problem georeferencing vectors with g.gui.gcp

[Margherita Di Leo]

On Tue, Jun 14, 2016 at 11:04 AM, Margherita Di Leo 
wrote:

> Markus,
>
> On Sun, Jun 12, 2016 at 5:41 PM, Markus Neteler  wrote:
>
>> On Sat, Jun 11, 2016 at 10:10 PM, Margherita Di Leo 
>> wrote:
>> ...
>> > Tested it on grass 7.1.svn (r65171) on Fedora.
>>
>> Your version is from May 1, 2015
>> (
>> https://trac.osgeo.org/grass/timeline?from=2015-05-01T03%3A25%3A58-07%3A00&precision=second
>> ),
>> i.e. 14 months ago.
>>
>> Any chance to update first?
>>
>
> Thanks for looking into this. I updated to the latest version but there is
> no difference
>

Please let me know if you advise to open a ticket. I wanted to confirm the
behavior first, in case I'm doing something wrong.

>


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

Re: [GRASS-dev] [SoC]Week-12 WebGrass

[Margherita Di Leo]

http://lists.osgeo.org/pipermail/soc/2016-August/003478.html

Il domenica 14 agosto 2016, Mayank Agrawal  ha
scritto:

> Hi everyone,
>
> I am Mayank Agrawal and I am working on webgrass.
>
> my report for the week 12
>
> Q. What did you get done this week?
>
>- Selection tab for the "Add Raster" and "Add Vector"
>- Listing of the respective(raster or vector) layers
>- creation of the layer from the data when layer is selected
>
>
> Q. What do you plan on doing next week?
>
>- display of the created layer
>
>
>
>
>

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

[GRASS-dev] GRASS GIS contributors meetup(s) in Ispra (VA) Italy

[Margherita Di Leo]

Hi,

this is just to let you know that we are planning to meetup in Ispra (VA)
on the lake Maggiore, Italy. I have created a page [1] that I will keep
updated with dates / time / participants / activities done. If you live in
the surroundings and want to join, you are welcome! The meetups are open to
newcomers as well. In this initial phase, just drop me an email saying that
you'e interested, and I'll get back to you as soon as we have details about
when / where.
I have to confess I have taken this initiative inspired by Yann Chemin, he
has recently joined at JRC, and made me realize once again that meeting in
person like-minded people boosts the enthusiasm in contributing to open
source! Which is more or less the scope of meetups... keeping the
enthusiasm high!!

Cheers!
madi


[1] https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Margherita Di Leo]

Hi,

On Fri, Sep 23, 2016 at 12:00 AM, Markus Neteler  wrote:

> Hi,
>
> in order to not hinder the addition of important new flags/parameters
> to modules while keeping things optionally easy it would be good to
> implement some expert mode to the parser.
>
> The flags and parameters for advanced users should be hidden by
> default (maybe by using an extra definition in order to "tag" them in
> the source code). Then e.g. by setting a variable they would become
> visible in the help text and GUI.
> Probably they should be always accepted when being invoked.
>

 This makes sense to me. If I type name.module --help and the command line
yield too long a list of parameters, I normally prefer reading it on the
manual page, where it is more clear, and I find extremely useful the usage
examples of the flags. I don't find it very informative to list all the
flags in command line, even the less used. There could be for example a
--ext-help for extended help display. So for example, typing only --help
would list only most used options and would end with "type --ext-help for
extended help" or something like that.

My 2 c

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

Re: [GRASS-dev] Adding an expert mode to the parser

[Margherita Di Leo]

Hi,

On Tue, Sep 27, 2016 at 7:13 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 26/09/16 23:50, Vaclav Petras wrote:
>
>>
>> On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo > <mailto:veroand...@gmail.com>> wrote:
>>
>> I'm with MaDi in that if I see a very long list of flags and
>> parameters in the terminal when using --h, i just go to the
>> manual... I just use --h in CLI for a quick recalling of
>> flags/options... A reduced list of most commonly used flags would be
>> nice, but still keep the possibility to get the advanced
>> flags/parameters as well, if the user needs more info...
>>
>>
>> If the --help is just for scanning and the issue is that it simply too
>> long, hiding some parameters is not the only option we have. For many
>> (and more in the future hopefully) parameters we have (short) label and
>> (longer) description. --help prints both (if both are present, that's at
>> least 2 lines per parameter). Additionally, if the option has predefined
>> values which have descriptions, there is one line for each of those. So,
>> the question is would it be helpful (at least as a first step) if --help
>> would print less information for each parameter but still provided all
>> parameters?
>>
>
> In line with your other mail where you caution about "hiding" useful
> information, how about not changing the --help output, but rather adding a
> "--simple-help" or somthing like this which would output a simplified help.


+1.


> Although:
>
> and manual pages then (a tab or section for advanced
>> flags/parameters)...
>>
>>
>> Considering that we have currently as system of (gui) sections which
>> place the options to individual tabs in GUI, isn't showing the different
>> sections in the manual the right thing to do?
>>
>
> I would prefer this: show everything, but structure it differently, i.e.
> possibly introduce a new parser keyword (advanced: yes) which would put the
> option into a specific section of the manual. IMHO, this should be
> independent of the GUI sections logic as one might to group less advanced
> and advanced options in the same thematic tab...


+1 also here :-)

>
>
> IMHO, a major issue however is the lack of examples for the usage
>> of
>> more advanced flags or options (or even the required and more
>> common
>> ones). Take the case of several i.* modules, for example... but
>> maybe
>> this should go in a separate thread :-)
>>
> >
> >
> > Good point. If you have an explanation and example for a flag, perhaps
> > you can understand it and it is not so advanced at the end.
>
> I think this is actually a major issue: man pages without description,
> notes and example sections are almost useless IMHO. At the foss4g.be last
> week someone presented a simple use of GRASS GIS (to create this map [1]
> for television) and explained how he actually found the GRASS GIS manual
> system extremely well done and useful, because of the explanations and
> examples...
>

+1000 :-)
So this afternoon at the GRASS meetup [
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016] we can give
a meaningful example on how users can contribute to GRASS without coding
:-)

Cheers,
madi

>
> Moritz
>
> [1] http://www.rtbf.be/services/meteo/apere
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] Adding an expert mode to the parser

[Margherita Di Leo]

On Tue, Sep 27, 2016 at 9:15 AM, Margherita Di Leo 
wrote:

> Hi,
>
> On Tue, Sep 27, 2016 at 7:13 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> On 26/09/16 23:50, Vaclav Petras wrote:
>>
>>>
>>> On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo >> <mailto:veroand...@gmail.com>> wrote:
>>>
>>> I'm with MaDi in that if I see a very long list of flags and
>>> parameters in the terminal when using --h, i just go to the
>>> manual... I just use --h in CLI for a quick recalling of
>>> flags/options... A reduced list of most commonly used flags would be
>>> nice, but still keep the possibility to get the advanced
>>> flags/parameters as well, if the user needs more info...
>>>
>>>
>>> If the --help is just for scanning and the issue is that it simply too
>>> long, hiding some parameters is not the only option we have. For many
>>> (and more in the future hopefully) parameters we have (short) label and
>>> (longer) description. --help prints both (if both are present, that's at
>>> least 2 lines per parameter). Additionally, if the option has predefined
>>> values which have descriptions, there is one line for each of those. So,
>>> the question is would it be helpful (at least as a first step) if --help
>>> would print less information for each parameter but still provided all
>>> parameters?
>>>
>>
>> In line with your other mail where you caution about "hiding" useful
>> information, how about not changing the --help output, but rather adding a
>> "--simple-help" or somthing like this which would output a simplified help.
>
>
> +1.
>


For inspiration, looking at gdal: http://www.gdal.org/ogr2ogr.html

$ ogr2ogr --help-general
Generic GDAL/OGR utility command options:
[...]

$ ogr2ogr --help
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
   [-select field_list] [-where restricted_where]
   [-progress] [-sql ] [-dialect dialect]
   [-preserve_fid] [-fid FID]
   [-spat xmin ymin xmax ymax] [-geomfield field]
   [-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]
   [-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]
   dst_datasource_name src_datasource_name
   [-lco NAME=VALUE] [-nln name] [-nlt type] [-dim
2|3|layer_dim] [layer [layer ...]]

Advanced options :
[...]
Note: ogr2ogr --long-usage for full help.

$ ogr2ogr --long-usage
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
  [...]

Advanced options :
   [...]

 -f format_name: output file format name, possible values are:
  [...]



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

[GRASS-dev] Next GRASS GIS meetup in Ispra (VA) on Tuesday 18 October

[Margherita Di Leo]

Dear All,

this is to let you know that after the success of the first one, the next
GRASS GIS meetup in Ispra (VA) will be happening on Tue 18 October. Join us
and bring your friends! Tweet about it and spread the word ;-)

https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016

Regards,

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

[GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

Dear all,

currently the default behavior of g.list is to display all the files
present in all mapsets (which corresponds to g.list mapset=*), without
indicating where they are.
I would very much prefer g.list mapset=. as a default behavior, ignoring
what there is in other mapsets.
If this is really not possible, at least specifying the mapset where the
maps are, if different from the current.
Perhaps:

g.list vect
vect1
vect2
PERMANENT
vect3

or:

g.list vect
vect1
vect2
PERMANENT/vect3

What do you think?
Thanks

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 11:47 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 19/10/16 11:22, Margherita Di Leo wrote:
>
>> Dear all,
>>
>> currently the default behavior of g.list is to display all the files
>> present in all mapsets (which corresponds to g.list mapset=*), without
>> indicating where they are.
>> I would very much prefer g.list mapset=. as a default behavior, ignoring
>> what there is in other mapsets.
>>
>
> -1
>
> For me the current default behaviour, i.e. showing maps of all mapsets in
> the current search path is much more useful.
>
> If this is really not possible, at least specifying the mapset where the
>> maps are, if different from the current.
>> Perhaps:
>>
>> g.list vect
>> vect1
>> vect2
>> PERMANENT
>> vect3
>>
>> or:
>>
>> g.list vect
>> vect1
>> vect2
>> PERMANENT/vect3
>>
>> What do you think?
>>
>
> Have you seen the '-m' flag ?
>

Yes, thanks.

>
> And otherwise, the '-p' flag gives you pretty printed output by mapset.
>
> I guess we could discuss whether '-p' should be the default...
>

Yes indeed it is the 'default behavior' what I'm referring to

>
> There was a discussion about these questions on the ML at the time:
> https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html


I must have missed that, or perhaps I had no strong opinion at that time,
sorry about that.
The reasons I don't like the current behavior is that, on one side is not
much informative (the maps sitting in the current mapset are likely the
ones I want to access the names most often, for other maps I find it
intuitive to explicitly ask for), and on the other side if you happen to
have several maps in a couple of mapset you end up with an unreadable blob.

Thanks

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 11:56 AM, Margherita Di Leo 
wrote:

>
>
> On Wed, Oct 19, 2016 at 11:47 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> On 19/10/16 11:22, Margherita Di Leo wrote:
>>
>>>
>>>
>> There was a discussion about these questions on the ML at the time:
>> https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html
>
>
> I must have missed that, or perhaps I had no strong opinion at that time,
> sorry about that.
>

It seems to me that the whole thread ended up with a general agreement that
the -m should be reverted?


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

[GRASS-dev] Fwd: Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Margherita Di Leo]

*Apologies for cross posting!*

Call for Presentations

Please forward!

FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source
software developers and communities a place to meet and share thoughts. The
participation is free of charge, although donations are welcome. The next
edition will take place on 4 - 5 February 2017. For the third (!) time
there will be a Geospatial devroom and will be happening on Sunday 5/2/2017!

Geospatial technologies and mapping used to be specialist work, but
nowadays location and maps are becoming part of many projects/applications,
which usually use only a small subset of the possibilities the data and
software offer.

The geospatial devroom is the place to talk about open, geo-related data
and software and their ecosystem. This includes standards and tools, e.g.
for spatial databases, and online mapping, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing purposes.

We welcome submissions about:

   -

   Web and desktop GIS applications;


   -

   Collaborative editing / versioning of geodata and metadata;
   -

   Interoperable geospatial web services and specifications;
   -

   Collection of data using sensors / UAVs / satellites;
   -

   Geo-analytic algorithms / libraries;
   -

   Geospatial extensions for classical databases (indexes, operations) and
   dedicated databases;
   -

   Big geodata, scalable GIS applications;
   -

   Volunteered Geographic information - Crowdsourced geodata.


HOW TO SUBMIT YOUR PROPOSAL FOR A TALK

Are you thrilled to present your work to other open source developers?
Would you like to run a discussion? Any other ideas?

Please submit your proposal at:

 https://fosdem.org/submit

Make sure to select the 'Geospatial devroom' as 'Track'. If you have an
account from previous years, you should be using the same.

Please specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes
presentation + discussion). However, note that time slots are indicative
and will be assigned according to the timing of the session.

The DEADLINE for submissions is Thursday **1st December 2016**.

Notification of acceptance will be sent to the Authors by 11/12/2016 at the
latest.

Should you have any questions, please do not hesitate to get in touch with
the organisers of the devroom at fosdem-geospatial at gisky.be!

Want to know what FOSDEM geospatial is like? Check out the videos and the
presentations of our previous two editions: [1,2]

The organizers

Johan Van de Wauw

Margherita Di Leo

Anne Ghisla

Martin Hammitzsch

[1] https://archive.fosdem.org/2015/schedule/track/geospatial/

[2] https://archive.fosdem.org/2016/schedule/track/geospatial/


-- 
Margherita Di Leo



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

Re: [GRASS-dev] [GRASS-user] Fwd: Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Margherita Di Leo]

Hi,

On Thu, Oct 20, 2016 at 4:00 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> After our latest discussions I think it might be interesting if someone
> could present the GRASS GIS testing framework.
>
> Anyone interested amongst those who know it well ?
>

Right, this is a very welcome topic! I hope someone is willing to present
it? If you're not familiar with it, please feel free to propose more topics
as well!
Regards,

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

Re: [GRASS-dev] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

Hi,

sorry for bringing back this topic again,

On Wed, Oct 19, 2016 at 2:17 PM, Margherita Di Leo 
wrote:

>
>
> On Wed, Oct 19, 2016 at 11:56 AM, Margherita Di Leo 
> wrote:
>
>>
>>
>> On Wed, Oct 19, 2016 at 11:47 AM, Moritz Lennert <
>> mlenn...@club.worldonline.be> wrote:
>>
>>> On 19/10/16 11:22, Margherita Di Leo wrote:
>>>
>>>>
>>>>
>>> There was a discussion about these questions on the ML at the time:
>>> https://lists.osgeo.org/pipermail/grass-dev/2014-October/071381.html
>>
>>
>> I must have missed that, or perhaps I had no strong opinion at that time,
>> sorry about that.
>>
>
> It seems to me that the whole thread ended up with a general agreement
> that the -m should be reverted?
>

what about a -c flag that prints only maps in current mapset?

Regards,


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

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Margherita Di Leo]

On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras  wrote:

>
> [...]
>
> Not directly related. Jupyter Notebook is independent and with some
> additions of interactive maps it could be used as a web interface for
> advanced or Python aware users. It can be used even now, but for
> visualization, you need to deal with d.* commands (which is fine in general
> but not for zooming, panning, ...) or you need to plug in other solution
> for visualization (like MapServer reading from GRASS GIS Database). There
> might be some code sharing between (some/any) web GRASS and Jupyter on the
> side of Python API or JavaScript map display (if applicable).
>


>
See: https://github.com/SylvainCorlay/ipyleaflet

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

[GRASS-dev] Fwd: GSoC : Students application period has started!

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo 
Date: Tue, Mar 21, 2017 at 8:56 AM
Subject: GSoC : Students application period has started!
To: OSGeo-SoC , OSGeo Discussions <
disc...@lists.osgeo.org>, geofor...@lists.osgeo.org


Dear All,

Yesterday students application period has started. We seek motivated
proactive students!

@Students: Start browsing the ideas page at [1] and carefully read the
recommendation for students, particularly the application instructions at
[2].
Quoting verbatim from Google Admins: "Historically, the students with the
best proposals reach out to the orgs early to receive feedback before
submitting their final proposal. " So don't wait until it is to late to
give you feedback, but instead join the communication channels of your
chosen software community and discuss over the proposal.

@Mentors: I see that there are still proposals with only 1 mentors. There
is still time to subscribe as a co-mentor, remember that we need at least 2
mentors otherwise the proposal will be discarded, no matter how good is the
student that applied for it. Furthermore, remember to offer small code
challenges to your would-be students, possibly in line with the purpose of
the gsoc proposal.

Let's rock!

*Please forward this email to your software communities*


[1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2017_Ideas
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_
Recommendations_for_Students#Application_instructions


-- 
Margherita Di Leo



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

Re: [GRASS-dev] [SoC] Week 01 Report - Integration Of PDAL into GRASS GIS

[Margherita Di Leo]

Hi Paul,

in grass-dev ML you can likely find guidance, putting it in cc. Thanks.

On Tue, Jun 6, 2017 at 9:51 PM, Paul Schrum  wrote:

> Thank you Adam.
>
> I was able to build PDAL from source following instructions at Unix
> Compilation <https://www.pdal.io/development/compilation/unix.html>.  I
> then ran all of the unit tests based on Testing
> <https://www.pdal.io/development/testing.html#pdal-test>.
>
> Later I realized that I am not able to read .laz files.  Doing so will be
> essential to my project's success.  The way I know it can't read laz is,
> from the command line, I enter:
>
> pdal info autzen.laz
>
> and it responds:
>
> PDAL: readers.las: Can't read compressed file without LASzip or LAZperf
> decompression library.
>
> Do I need to download LASzip source and build that, then rebuild pdal?
>
> - Paul
>
>
> On Mon, Jun 5, 2017 at 4:53 PM, Adam Steer  wrote:
>
>> Hi Paul
>>
>> What issues are you having with PDAL and LAZ compression? I don’t know if
>> I can help for your use case, but I do have a working PDAL/laszip/laz-perf
>> system natively installed on Linux without docker.
>>
>> Also I’m not officially a mentor of your or any project, but happy to
>> help - and happy to discuss with your mentor(s) also if need be.
>>
>> Cheers
>>
>> Adam
>>
>> --
>> Dr. Adam Steer
>> Earth systems data service specialist
>> National Computational Infrastructure
>> Leonard Huxley Building, Mills Road
>> The Australian National University
>> Acton ACT 2600 Australia
>>
>> adam.st...@anu.edu.au
>> +61 2 6125 1413
>> http://nci.org.au
>>
>>
>>
>>
>> > On 5 Jun 2017, at 11:13 am, Paul Schrum  wrote:
>> >
>> > Submitted by Paul Schrum
>> > Also available at Integration Of PDAL into GRASS GIS
>> >
>> >   • What did you get done this week?
>> >   • Built GRASS73 from source from my local repo directoy.
>> >   • Stepped into a module (v.in.ascii) using the debugger to watch
>> it work at the source code level. This was only proving the concept of
>> stepping into the code – just getting it to work.
>> >   • Talked with my mentor about the nature of the existing
>> v.in.pdal module and what are some of the things which must be changed,
>> fixed, or improved.
>> >   • What do you plan on doing next week?
>> >   • Continue stepping through v.in.ascii to see how it works at the
>> source level in order to understand how to write points to a vectormap.
>> >   • Get GRASS 73 to link to current version of PDAL.
>> >   • Fix broken references to PDAL data structures in the GRASS
>> source
>> >   • Refactor existing v.in.pdal so that operations which r.in.pdal
>> and r3.in.pdal will need are in a separate module and available as
>> functions to be called from all three of them.
>> >   • Learn the process of calling PDAL and how to get it to do the
>> basic operation of reading a lidar file and handing over the data to the
>> caller.
>> >   • Set up a basic set of test data for PDAL, open it from pdal
>> without GRASS, then open it using pdal through GRASS with only the most
>> basic options in operation.
>> >   • Get PDAL to be able to read .laz (compressed) files. For some
>> reason it can’t do that after build-from-source.
>> >   • Are you blocked on anything?
>> > I had two listed on the Wiki when I originally posted it, but my mentor
>> helped me work through those before the end of the reporting period for
>> Week 1. So there are currently no issues blocking me.
>> >
>> > ___
>> > SoC mailing list
>> > s...@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/soc
>>
>>
>
> ___
> SoC mailing list
> s...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/soc
>



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

[GRASS-dev] Python grass script error

[Margherita Di Leo]

Hi,

I have GRASS 7.3.svn (r71212). In python , calling grass.script I get:

>>> import grass.script as grass
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/grass-7.3.svn/etc/python/grass/script/__init__.py", line
5, in 
from .core   import *
  File "/usr/local/grass-7.3.svn/etc/python/grass/script/core.py", line 35,
in 
gettext.install('grasslibs', os.path.join(os.getenv("GISBASE"),
'locale'))
  File "/usr/lib64/python2.7/posixpath.py", line 70, in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'

Anyone can reproduce this error?

Thank you in advance


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

Re: [GRASS-dev] Python grass script error

[Margherita Di Leo]

Maris, thank you for checking this!! Was my mistake, I hadn't noticed that
I had a duplication of import grass.script as grass, the one throwing the
error was at the top of the script before declaring GISBASE. need
holidays I guess.. sorry for the noise.

On Fri, Jun 30, 2017 at 11:59 AM, Maris Nartiss  wrote:

> Works just fine here.
> What is the output of os.getenv("GISBASE")? Are you trying to run this
> code outside of GRASS GIS session (this could explain lack of GISBASE
> environmental setting)?
>
> Māris.
>
>
> 2017-06-29 18:00 GMT+03:00 Margherita Di Leo :
> > Hi,
> >
> > I have GRASS 7.3.svn (r71212). In python , calling grass.script I get:
> >
> >>>> import grass.script as grass
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/usr/local/grass-7.3.svn/etc/python/grass/script/__init__.py",
> line
> > 5, in 
> > from .core   import *
> >   File "/usr/local/grass-7.3.svn/etc/python/grass/script/core.py", line
> 35,
> > in 
> > gettext.install('grasslibs', os.path.join(os.getenv("GISBASE"),
> > 'locale'))
> >   File "/usr/lib64/python2.7/posixpath.py", line 70, in join
> > elif path == '' or path.endswith('/'):
> > AttributeError: 'NoneType' object has no attribute 'endswith'
> >
> > Anyone can reproduce this error?
> >
> > Thank you in advance
> >
> >
> > --
> > Margherita Di Leo
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] git repo for new Web site created

[Margherita Di Leo]

Please add me.
My account is madi

https://git.osgeo.org/gogs/madi

On Sat, Jul 22, 2017 at 8:04 PM, Markus Neteler  wrote:

> Hi,
>
> during the FOSS4G-Europe 2017 code sprint we decided to create a git
> repo the upcoming GRASS GIS web site (there is the long standing plan
> to get a new beautiful web site :-)
>
> To join, please register here - by using your OSGeo-ID:
>
> https://git.osgeo.org/gogs/grass_gis
>
> Then we can enable you for the repo.
>
> Best,
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev




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

Re: [GRASS-dev] [SoC] GSoC 2017 Weekly Report 12 - SOS tools in GRASS GIS

[Margherita Di Leo]

Hi Ondrej,

Thank you for your report.
Note that this is your final report and was supposed to be a summary of
your work. Please, read
https://lists.osgeo.org/pipermail/soc/2017-August/003827.html and
re-elaborate your report to meet the given template

Thanks

Il giorno ven 18 ago 2017 alle 14:58 Ondřej Pešek 
ha scritto:

> Hi everyone!
>
> Here is the twelfth report of my GSoC project - SOS tools in GRASS GIS.
> You can see my project at wiki at [1]
>
> What did you get done this week?
>
> all modules
> * made quiet, e.g. when creating temporal dataset with hundreds of maps,
> it doesn't show hundreds of builds
>main commits: [2]
> * worked on documentation
>main commits: [3]
>
> t.vect.in.sos
> * uses yet existing timestamped layers instead of creating new ones
>main commits: [4] [5]
>
> v.to.rast
> * created
>main commits: [6] [7]
>
> r.in.sos
> * updating yet existing maps instead of creating new ones
>main commits: [8] [9]
> * option for granularity and aggregations
>main commits [10]
>
> What do you plan on doing next week?
>
>  * Work on documentation
>  * clean code
>  * upgrading t.vect.to.rast
>  * preparing to submit the final product
>
> Are you blocked on anything?
>
> No
>
> Regards,
> Ondrej
>
> [1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
> [2]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/e028f3da2b47b894c96ad22e32be7e6436d83f07
> [3]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/03acaede08612c7bf4e418b5c3059110e3f72f9c
> [4]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/0c15705ec7f4d0368fb869f6c60df2878a6ec573
> [5]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/9fa89ab7056589a91f35722cdef6e392afb12c35
> [6]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/5e323045dfc4d94097daaa562898ee594d2e66c7
> [7]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/c5e285bc57acf662b377453b4c690b068082d66b
> [8]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/43ef1d83df16e0fa887b81eb1ba77a689952863d
> [9]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/7bb8f453e11140fe1d0645aee3d37a027617d0e4
> [10]
> https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/ec75da4f6582aeb4083f0b416519577ceb82da3b
> ___
> SoC mailing list
> s...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/soc

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

Re: [GRASS-dev] Fwd: [SoC] Google Code In (GCI) 2017 just announced! And we want to participate

[Margherita Di Leo]

Hi,

On Mon, Sep 25, 2017 at 9:47 PM, Helmut Kudrnovsky  wrote:

> Veronica Andreo wrote
> > Ciao Lu,
> >
> > I signed in and will attend the meeting tonight through IRC chat. I had
> > some ideas in mind:
> >
> > - Design the t-shirt for the next code-sprint
> > - Add examples to xx manual pages
> > - Make a promo video for GRASS GIS
> > - Make new tutorial videos for GRASS GIS
> > - Enhance the visual index
> > - Make screenshots for release pages (eg.
> > https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74)
> > - Create screenshot for the next 74 release announcement
> >
> > what do you think? too simple? too complicated?
>
> looks good to me. it should be tasks doable in just a couple of hours.
>

Actually (3-5 hours)
https://developers.google.com/open-source/gci/how-it-works
All the tasks you listed are just perfect, only we will need a large mentor
capacity, other orgs refer that hundreds of students participate, and even
if tasks review only takes 15 minutes, it needs a large pool of people to
review.

>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] We need mentors for Google Code-In

[Margherita Di Leo]

Dear Anna,

On Wed, Oct 4, 2017 at 7:41 PM, Anna Petrášová 
wrote:

> Hi Vero,
>
> On Wed, Oct 4, 2017 at 11:24 AM, Veronica Andreo 
> wrote:
> > Hey devs,
> >
> > As the subject reads: We need more mentors for Google Code-In :)
> >
> > GCI is a competition addressed to high-school students aged 13-17, as an
> > introduction to the open source world. They are supposed to complete as
> much
> > tasks as possible to win the contest. These tasks should be short simple
> > stuff (3-5 hours), but since they have to complete several to win, we
> need
> > to plan lots of them and be available to review what the students submit
> > rather quickly, so they can start with a new one. For that reason, it is
> > better if we are more mentors.
> >
> > Here is the GRASS wiki [0] with more details and a collection of ideas
> for
> > tasks that should then be further explained and developed in the format
> of
> > tasks. I think the ideas are nice and this could be a funny experience.
> > Moreover, we could attract new generations and benefit from their
> creativity
> > ;)
> >
>
> this is probably not very helpful response, but I am little bit
> skeptical about this and maybe you can clarify some things. My main
> problem is that GRASS is not the type of software you just start to
> use and understand it right away. Even making useful screenshots
> requires decent knowledge of the software and geospatial data/models.
> Do you think these students have any ideas about GIS? I confess I
> haven't spent much time thinking about this program yet, but I see a
> lot of time spent by mentors defining precise tasks without too much
> gain. I can see this could be useful for things like designing
> promotional materials, but not much beyond that. But I am open to be
> convinced otherwise.
>
>
>
I had the same doubts as you have, and I think only experience can give us
the answer. I partly overcame my doubts talking to other organizations that
run the code in. They suggested preparing some beginner tasks like
- "Install the software following the instructions here XXX and make a
screenshot"
- "Follow this tutorial XXX and make a screenshot of the result"
- "Prepare a video of 20 minutes, explaining how to get started with the
software to your fellow GCI students"
I think the more complicated is the software, the more work we need to
prepare tasks that are approachable. The good news is that, after the first
year, things get smoother, mentors learn a lot from the students, students
prepare some good material that can be reused for next editions and also
for promoting the software, and students often even come back to mentor
other students.
I have the feeling that if we never try, we never know how will end up.. ;-)


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

Re: [GRASS-dev] improve resolution of bands

[Margherita Di Leo]

On Fri, Oct 20, 2017 at 3:08 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/10/17 11:37, Luca Delucchi wrote:
>
>> Hi devs,
>>
>> I just discovered this [0], I think it could be really useful this
>> functionality in GRASS too, what do you think? The code is LGPL so it
>> could be ported "easily" in GRASS.
>>
>>
>> [0] http://nicolas.brodu.net/recherche/superres/index.html
>>
>
> +1
>
> IIUC, it's a new technique for image fusion ? As of now, we have
> i.pansharpen in core which offers very basic fusion techniques and
> Nikos' i.fusion.hpf in addons. New techniques would certainly be welcome.
>
> A while ago, I was looking at Bayesian fusion methods, notably R-FUSE [1],
> for which Matlab code is available [2], but haven't had the time to go
> further. That might be another method that would be great to implement.
>
> Maybe also something to keep in mind for next GSoC ?
>

This sounds like a great idea, please don't let it fade out, it's always a
good time to collect the ideas into the ideas page

Thanks


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

[GRASS-dev] Fwd: Call for mentors for Google Summer of Code 2018

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo 
Date: Mon, Jan 8, 2018 at 12:13 PM
Subject: Call for mentors for Google Summer of Code 2018
To: OSGeo Discussions 
Cc: "gsoc-adminosgeo.org" 


Dear members of the community,

while we're still very busy in Google Code-in, which is, by the way, a big
success so far, it's already time to apply for Google Summer of Code 2018!
In fact, the admins team is making shifts to cope with all these energetic
pre-school students and meanwhile preparing the application for next GSoC..

*We need you!*

At this time of the year, software communities should brush up their list
of ideas, create a new ideas page and send the URL to us admins at  <
gsoc-ad...@osgeo.org>. We need to receive your URLs by *Jan 20*.  If you
are willing to act as a mentor, fill in this form: https://goo.gl/forms/
jMvPl7ns2NG1BL6Q2

Please, forward this email to your developer mailing list.

Here [1] is the timeline.

Looking forward to another great GSoC edition!
Let's keep fingers crossed for our application!

Cheers

-The GSoC / GCI admins team


[1] https://developers.google.com/open-source/gsoc/timeline

-- 
Margherita Di Leo



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

[GRASS-dev] Fwd: [Action required] Please prepare the ideas page for GSoC 2018

[Margherita Di Leo]

-- Forwarded message --
From: Margherita Di Leo 
Date: Tue, Jan 9, 2018 at 3:57 PM
Subject: [Action required] Please prepare the ideas page for GSoC 2018
To: OSGeo Discussions , OSGeo-SoC <
s...@lists.osgeo.org>
Cc: "gsoc-adminosgeo.org" 


Dear members of the Community,

this is a reminder that to participate in GSoC also this year we need you
to send us (admins:  ) the URL for your project's
ideas page.

Every idea should indicate a title, a description, 2 mentors and a test for
the students to submit to your evaluation. The test aims at evaluating if
the student is capable for the project, so please design the test having in
mind the skills required to complete the project.

Time is short, we need to collect all URLs by Jan 20.

Thanks and please forward to your project community.

Cheers,

-- 
Margherita Di Leo



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

Re: [GRASS-dev] GSOC 2018 project for GRASS GIS

[Margherita Di Leo]

On Tue, Mar 6, 2018 at 5:37 AM, Sanjeet  wrote:

> On Sat, Mar 3, 2018 at 10:50 PM, Anna Petrášová 
> wrote:
> > Basically, the GUI is mostly ported to work with wxPython4 (phoenix),
> > which is (unlike wxpython 3) Python 3 ready. So far we are running the
> > GUI on Python 2.7 only. There are some loose ends and depreciation
> > warnings, which would be nice to get rid of. Since we need to keep
> > backwards compatibility with wxpython 3, we wrapped some GUI classes
> > (gui/wxpython/gui_core/wrap.py), so you can start there. You need to
> > test your changes under both wxpython 3 and 4. Let me know if you need
> > more clarification. More info what is Attribute Table manager:
> >
> > https://grass.osgeo.org/grass75/manuals/wxGUI.dbmgr.html
> > https://grasswiki.osgeo.org/wiki/WxGUI_Attribute_Table_Manager
>
> Hi Anna,
>
> I've created a patch file for the ticket #3510.
>
> > To post a patch in that ticket, you need to get osgeo id:
> > https://www.osgeo.org/community/getting-started-osgeo/osgeo_userid/
>
> I'm waiting for 'mantra' to create the osgeo user id, so that I can
> upload the patch file.
>

What's your username?

>


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

Re: [GRASS-dev] GSoC Project

[Margherita Di Leo]

Hi,

I see that you have indicated in the first week: to design the tool,
actually you should be doing this now, as well as compiling the source
code, which you put in the bonding period. Rationale: how do you/we know
that you will be able to develop such tool if you haven't neither designed
it, nor compiled the source code and studied basic documentation.

Thanks

On Sat, 10 Mar 2018 at 07:10, sharry gill  wrote:

> Hi,
>
> Here is the draft proposal, I fixed it: Link To Proposal
> 
>
> If any improvements are required, please let me know.
>
> Thank You
> Supreet Singh
> https://singhsupreet.github.io/
>
> On Wed, Mar 7, 2018 at 9:49 PM, Luca Delucchi 
> wrote:
>
>> On 7 March 2018 at 09:08, sharry gill  wrote:
>> >
>> > Hello,
>>
>> hi,
>>
>> >
>> > May be this is poasible that, if we allow user only to select modules,
>> and
>> > flags will be automatic.
>>
>> yes, so please improve your proposal..
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Project

[Margherita Di Leo]

After designing the tool, you should spend some time and reconsider what
you have written in the timeline, which currently says absolutely nothing
about the actual implementation, as you use generic sentences about writing
"the code" and compiling "the code".
Please, take a look at former years student proposals to get a hint of how
to structure a meaningful proposal, how to design your project and how to
split up the project in milestones for your timeline.

Thanks and regards,

On Sat, 10 Mar 2018 at 09:21, Margherita Di Leo  wrote:

> Hi,
>
> I see that you have indicated in the first week: to design the tool,
> actually you should be doing this now, as well as compiling the source
> code, which you put in the bonding period. Rationale: how do you/we know
> that you will be able to develop such tool if you haven't neither designed
> it, nor compiled the source code and studied basic documentation.
>
> Thanks
>
> On Sat, 10 Mar 2018 at 07:10, sharry gill 
> wrote:
>
>> Hi,
>>
>> Here is the draft proposal, I fixed it: Link To Proposal
>> <https://docs.google.com/document/d/1G3cAkTXh_DAGyG26Mi1Sw3Ot2IL1msReG-_KFTSp2Nc/edit?usp=sharing>
>>
>> If any improvements are required, please let me know.
>>
>> Thank You
>> Supreet Singh
>> https://singhsupreet.github.io/
>>
>> On Wed, Mar 7, 2018 at 9:49 PM, Luca Delucchi 
>> wrote:
>>
>>> On 7 March 2018 at 09:08, sharry gill  wrote:
>>> >
>>> > Hello,
>>>
>>> hi,
>>>
>>> >
>>> > May be this is poasible that, if we allow user only to select modules,
>>> and
>>> > flags will be automatic.
>>>
>>> yes, so please improve your proposal..
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> www.lucadelu.org
>>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

[Margherita Di Leo]

Ciao Pietro and all,

On Mon, Mar 12, 2018 at 11:05 AM, Pietro  wrote:

>
>>
> I'm available to co-mentoring this GSoC.
>
>
>  may I remind to subscribe as a mentor filling the form https://goo.gl/
forms/kddSWrLkna84oXyb2 , it's not too late for new mentors, but the sooner
the better. Thanks!



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

Re: [GRASS-dev] New dev team on github for initial tests

[Margherita Di Leo]

Hi,

Il giorno sab 17 mar 2018 alle 18:27 Markus Neteler  ha
scritto:

> Hi,
>
> as per
>
> https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#Move_to_Git
>
> I have created a "GRASS GIS dev" team here:
> https://github.com/orgs/OSGeo/teams/grass-gis/members
>
> ... who wants to join, please speak up (and send your account name).


Please add me https://github.com/madi

Thanks!

>
>
> We need to experiment with it to then decide what we really want to do
> with our SVN repo.
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] [GSOC 2018] - Implement a series of image fusion algorithms in GRASS GIS

[Margherita Di Leo]

Hi Tudor,

Please share your proposal as public, because you have submitted it as
final, but we cannot either see it until deadline either comment it, so you
cannot benefit from feedback and we will evaluate it as it is. Also, please
read the recommendations at
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students
and
introduce yourself in soc mailing list.

Good luck!
Cheers



Il giorno ven 2 mar 2018 alle 10:35 Tudor-Emil COMAN (25633) <
tudor_emil.co...@stud.acs.upb.ro> ha scritto:

> Hi,
>
>
> My name is Tudor-Emil Coman and I study Computer Science at the Faculty of
> Automatic Control and Computer Science in Bucharest, Romania as a MSc
> student.
>
> I'm currently researching geospatial image processing technologies and I
> have
> primarly worked with Sentinel 2 data on numerous frameworks like ESA SNAP,
> GDAL, GeoDjango, PostGIS and of course GRASS GIS.
>
> I'm very interested in working this summer for a project I have seen
> proposed
> on the GSOC 2018 idea page regarding the development of image fusion
> algorithms.
> An already existing fusion algorithm is the High-Pass Filter Addition
> technique
> implemented in the i.fusion.hpf module [1]. The scope of the project would
> be
> to expand the capabilities of GRASS to combine data from different sensors.
>
> The first algorithm I would implement is based on Nicolas Brodu's paper
> named
> Super-resolving multiresolution images with band-independant geometry of
> multispectral pixels [2]. The algorithm presented in this paper would
> increase
> the resolution of certain low resolution bands by inferring some geometric
> characteristics from high resolution bands. As opposed to the already
> existing
> HPFA fusion method, this one does not require a panchromatic band making it
> suitable for satellites that do not produce panchromatic bands.
>
> I'm sure some other fusion algorithms are needed in GRASS-GIS that are not
> yet
> implemented. I'm interested in suggestions about such algorithms so that I
> can
> read about them and incorporate them into my final proposal.
>
> [1] - https://grass.osgeo.org/grass74/manuals/addons/i.fusion.hpf.html
> [2] - https://arxiv.org/abs/1609.07986
>
> Cheers,
> Tudor
>
> _______
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[GRASS-dev] Fwd: Wouldbe GSoC students, please read

[Margherita Di Leo]

-- Forwarded message --
From: Margherita Di Leo 
Date: Wed, Mar 21, 2018 at 10:47 AM
Subject: Wouldbe GSoC students, please read
To: OSGeo Discussions , OSGeo-SoC <
s...@lists.osgeo.org>


Dear students,

this is a reminder that we will be accepting students proposals until March
27, that is only 1 week away from now. As a general remark, we know that
late submissions are not our best shot, as we usually find them incomplete,
so be aware that the sooner you submit your proposals, the better chances
you have to adjust them to mentors' requirements, and in the end, better
chances to be selected.
We have noticed some proposals have been submitted as final. We cannot
access them until deadline, so, unless you also share the google docs as
public, we don't have a way to give you feedback and we will be evaluating
your final proposal as it is, so you have less chances, or none at all if
your proposals hasn't been discussed anywhere in public channels.
Even if you have had some contact with a potential mentor, remember that
the proposals discussion must happen in public channels, as it is always
the case in open source communities.
Last but not least, remember that GSoC is a highly competitive program, we
prioritize quality over quantity, this means that we only accept excellent
proposals. So please read carefully and thoroughly our recommendations at
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_
Recommendations_for_Students and don't forget to introduce yourself in SOC
mailing list.

Good luck everyone

@All: please forward to your software community mailing list


-- 
Margherita Di Leo



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

Re: [GRASS-dev] [SoC] Just in time: Seeking mentors for development of a Deep Learning model applied to Remote Sensing Data

[Margherita Di Leo]

Hi Evandro,

thank you for your proposal, I put in cc also the GRASS GIS dev mailing
list, as it might be a suitable project candidate if anyone is available
for mentoring it. It is usually a bit more difficult to find mentors when
the proposal comes from a student and it is not listed in our ideas page,
however not impossible, and your idea sounds very interesting. Are you
familiar with GRASS GIS?
I'd like to point you out our recommendations for students at
https://wiki.osgeo.org/index.php?title=Google_Summer_of_Code_Recommendations_for_Students
, particularly our guidelines on how to submit a proposal.

Thanks,

On Thu, Mar 22, 2018 at 5:49 PM, Evandro Carrijo 
wrote:

> Hello there!
>
> I'm a Computer Science Master's Degree student whose research if focused
> on Deep Learning algorithms applied to Remote Sensing. Currently working at
> the Laboratory of Image Processing and Geoprocessing
> <https://github.com/lapig-ufg> settled at Federal University of Goiás -
> Brazil. I'm also member of the High Performance Computing group of the same
> university (more information here
> <http://dgp.cnpq.br/dgp/espelhogrupo/7985061476854055>).
>
> Below I present an idea to explain how I can contribute to OSGeo
> community and I'm seeking for mentors interested in assist my development.
> Please, feel free to argue me any matter about the project idea.
>
> I would also appreciate a lot if you guys indicate a potential interested
> mentor to my project idea or a OSGeo Project suitable to it.
>
> Hope there's some Interested ones out there!
>
> Idea
>
> The increasing number of sensors orbiting the earth is systematically
> producing larger volumes of data, with better spatiotemporal resolutions.
> To deal with that, better accurate machine learning approaches, such as
> Deep Learning (DL), are needed to transform raw data into applicable
> Information. Several DL architectures (e.g. CNN, semantic segmentation)
> rely only at spatial dimension to perform, for example, land-cover/land-use
> (LCLU) maps, disregarding the temporal dependencies between pixels
> observations over the time. Also, high-res remote sensing data (e.g.
> Planet, Sentinel) may provide more consistent time-series, that can be use
> in the identification of important LCLU classes, like crop, pastureland and
> grasslands.
>
> This potential can be explored using Recurrent Neural Networks (RNN), a
> specific family of DL approaches which can take into account time
> dimension. A promising project idea would be implement a RNN approach (e.g.
> LSTM) to classify a Sentinel time-series, that will organize and preprocess
> an input data set (e.g. labeled time-series), calibrate and evaluate a RNN
> model, and finally classify an entire region (i.e. 2 or 3 scenes) to
> produce a map for one or more LCLU class. It will be great evaluate the
> accuracy and the spatial consistent of a map produced with a RNN approach.
>
> A simple example on classifying LCLU with two classes (pastureland and
> non-pastureland):
>
> [image: itapirapua]
> <https://user-images.githubusercontent.com/37085598/37687055-cc5236a8-2c78-11e8-8892-d113df44e235.jpg>
> *Target region (input)*
>
> [image: itapirapua_ref]
> <https://user-images.githubusercontent.com/37085598/37732806-ec792782-2d24-11e8-8ad9-18867768e998.jpg>
> *Generated LCLU map (output)*
> Best,
>
> Evandro Carrijo Taquary
> Federal University of Goiás
>
> ___
> SoC mailing list
> s...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/soc
>



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

Re: [GRASS-dev] [SoC] Just in time: Seeking mentors for development of a Deep Learning model applied to Remote Sensing Data

[Margherita Di Leo]

Evandro,

On Thu, Mar 22, 2018 at 6:59 PM, Evandro Carrijo 
wrote:

> Hi Margherita,
>
> I really appreciate for your feedback! I'm not much familiar with GRASS
> GIS as I had only developed standalone codes in Python using directly
> libraries like GDAL and RIOS <http://rioshome.org> and used QGIS for
> layers visualization. But, as I observed here
> <http://grass.osgeo.org/programming6/pythonlib.html> and here
> <https://grasswiki.osgeo.org/wiki/GRASS_and_Python>, Python scripts can
> easily be integrated within GRASS GIS and I could seamlessly adapt my
> programming skills to work with that. That way, I could compromise myself
> in integrating my already done codes (and new ones) into GRASS GIS
> software/libraries.
>

That's really good for you to familiarize with writing code in GRASS, as
that would give your idea more chances.

>
> Also, if allowed, I could edit the Ideas' wiki page to contemplate my own
> idea,
>

No, that is not necessary


> so that it could be visible to a broader audience. If I get a mentor in
> time, I will make a detailed proposal for the mentors/community be able to
> understand better the idea.
>

Actually it works the other way around, you're supposed to write and submit
your proposal at this stage, so that potential mentors can comment on it
and give you feedback, and decide whether it's feasible and if they want to
mentor it. Please, follow the guidelines I linked to you to submit a
proposal, and share it publicly also in GRASS mailing list for developers
to comment.

Good luck!

>
> Thank you very much,
>
> Evandro Carrijo Taquary
> Federal University of Goiás
>

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

[GRASS-dev] t.rast.univar Unable to get statistics for raster map

[Margherita Di Leo]

Hi,

I have a strds and I try to get statistics for an area within a mask. A
couple of images have no data within the masked area, and t.rast.univar
gives the warning message:  "Unable to get statistics for raster map". In
the resulting csv, the missed dates are skipped, and this is sort of
unexpected and creates hurdles when for example I compare it with the
behavior of t.rast.what, that keeps the date and associates a no-data to
it. Wouldn't it be better if also t.rast.univar would yield a no-data
rather than skip the date?

Thanks
Regards,

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

Re: [GRASS-dev] t.rast.univar Unable to get statistics for raster map

[Margherita Di Leo]

Hi,

On Wed, Dec 5, 2018 at 1:36 PM Veronica Andreo  wrote:

> Hi,
>
> El mié., 5 dic. 2018 a las 11:04, Moritz Lennert (<
> mlenn...@club.worldonline.be>) escribió:
>
>> On 5/12/18 10:47, Margherita Di Leo wrote:
>> > Hi,
>>
>> This can probably somehow be solved within t.rast.univar, but IIUC the
>> actual issue comes from the underlying r.univar call which has the same
>> behaviour, for example when call with the 'zones' parameter and the '-t'
>> flag: data is just absent if there are only null values in a given zone.
>> I've been struggling with that, for example for addon modules such as
>> i.segment.stats. I don't know how easy it would be to change that within
>> r.univar, but it would be nice.
>>
>> IIUC, the issue comes from stats.c [1]:
>>
>> 123 if (stats[z].n == 0)
>> 124 continue;
>>
>> Maybe a flag to fill the stats with NULL values, instead of ignoring
>> them, would be appropriate ?
>
>
>
[...]


> +1!!
>
> But I don't know what an good NULL value would be here.
>>
>
> IIRC, r.out.xyz and t.rast.out.xyz use the '*' character.
>

Indeed, this is the case also for t.rast.what

It would be good to create a ticket for this, no? As to not forget
> afterwards...
>

Yes. I'm not sure if this should be put as a ticket for r.univar, or for
t.rast.univar or 2 separate tickets referring to each other?


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

Re: [GRASS-dev] t.rast.univar Unable to get statistics for raster map

[Margherita Di Leo]

On Thu, Dec 6, 2018 at 10:42 AM Margherita Di Leo 
wrote:

>
>  I'm not sure if this should be put as a ticket for r.univar, or for
> t.rast.univar or 2 separate tickets referring to each other?
>

Done in one ticket: https://trac.osgeo.org/grass/ticket/3703#ticket

Thanks
regards,

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

[GRASS-dev] Fwd: Reminder GSoC 2019 - Call for ideas and mentors

[Margherita Di Leo]

FYI

-- Forwarded message -
From: Margherita Di Leo 
Date: Fri, Feb 1, 2019 at 8:58 AM
Subject: Reminder GSoC 2019 - Call for ideas and mentors
To: OSGeo-SoC , OSGeo Discussions <
disc...@lists.osgeo.org>, ICA OSGeo Labs list <
ica-osgeo-l...@lists.osgeo.org>


Dear OSGeo Community,

this is a gentle reminder to our call for GSoC 2019 mentors and ideas.

If you want to mentor [1], fill in this form:

 https://goo.gl/forms/njL27YLWBVensZ3m1

To complete OSGeo’s GSoC application 2019, we need an ideas list. If you
want to participate proposing ideas, you need to send us (admins:
) the URL for your project's ideas list. Last
years’ ideas [2] are always a good starting point to prepare the new list
for 2019 [3].

Each project on the Ideas list should include:

a) a project title/description
b) more detailed description of the project (2-5 sentences)
c) expected outcomes
d) skills required/preferred
e) 2 possible mentors.
f) if possible, an easy, medium or hard rating of each project.
g) A test for the students to submit to your evaluation. The test aims at
evaluating if the student is capable for the project, so please design it
having in mind the skills required to complete the project.

For any questions, just ping us admins by  

Time is short, we need to collect all URLs by Feb 4. After that date,
Google's admins will start evaluating the organizations based on the
submitted ideas pages and decide which orgs will be accepted for this
edition.

Thanks for your cooperation!

Kind regards
OSGeo GSoC admins

[1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2019_Administrative
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2018_Ideas
[3] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2019_Ideas


-- 
Margherita Di Leo


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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] [FOSS4G] OSGeo Projects swag

[Margherita Di Leo]

Hi!
Love the cheat sheet idea... and talking about T-shirt, I'd love something
like this https://store.xkcd.com/products/linux-cheat-shirt... LOL
Cheers,

On Thu, Jul 8, 2021 at 3:20 AM Vaclav Petras  wrote:

> Issue for the cheatsheet created by Anna:
>
> https://github.com/OSGeo/grass/issues/1713
>
> On Wed, Jul 7, 2021 at 3:53 PM Brendan  wrote:
>
>> A GRASS cheat sheet would be great. I'd be happy to help. What do you
>> envision on the cheat sheet?
>> Would it focus on commands and operations? Or concepts like regions,
>> rasters, vectors?
>> -Brendan
>>
>>
>> On Wed, Jul 7, 2021 at 11:35 AM Luca Delucchi 
>> wrote:
>>
>>> On Wed, 7 Jul 2021 at 16:19, Anna Petrášová 
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>>
>>> Hi,
>>>
>>> > what I think would be actually useful would be a GRASS cheatsheet,
>>> something like this:
>>> > https://pandas.pydata.org/Pandas_Cheat_Sheet.pdf
>>> > That is obviously a lot of work, but maybe we could put together
>>> something much simpler, at least for this occasion.
>>> >
>>>
>>> I like it, what do you think about a latex template?
>>> I found this [0], it looks like a good starting point, better than
>>> this [1] and this [2]
>>>
>>> I try to find something in svg, scribus and libreoffice but I had not
>>> result (maybe wrong query)
>>>
>>> [0] http://tug.ctan.org/info/latex-refsheet/LaTeX_RefSheet.tex
>>>  http://tug.ctan.org/info/latex-refsheet/LaTeX_RefSheet.pdf
>>> [1] https://www.latextemplates.com/template/cheatsheet
>>> [2]  http://wch.github.io/latexsheet/
>>>
>>> > Anna
>>> >
>>>
>>> --
>>> ciao
>>> Luca
>>>
>>> www.lucadelu.org
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>


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