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

[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] 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

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

[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] [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 <evandro.taqu...@gmail.com>
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

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 <evandro.taqu...@gmail.com>
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

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

[Margherita Di Leo]

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Wed, Mar 21, 2018 at 10:47 AM
Subject: Wouldbe GSoC students, please read
To: OSGeo Discussions <disc...@lists.osgeo.org>, 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] [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

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 <nete...@osgeo.org> 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] 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 <peter.z...@gmail.com> 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] 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 <direg...@gmail.com> 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 <sharrygill5...@gmail.com>
> 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 <lucadel...@gmail.com>
>> wrote:
>>
>>> On 7 March 2018 at 09:08, sharry gill <sharrygill5...@gmail.com> 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]

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 2018 project for GRASS GIS

[Margherita Di Leo]

On Tue, Mar 6, 2018 at 5:37 AM, Sanjeet <edu.sanj...@gmail.com> wrote:

> On Sat, Mar 3, 2018 at 10:50 PM, Anna Petrášová <kratocha...@gmail.com>
> 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

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

[Margherita Di Leo]

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

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

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Mon, Jan 8, 2018 at 12:13 PM
Subject: Call for mentors for Google Summer of Code 2018
To: OSGeo Discussions <disc...@lists.osgeo.org>
Cc: "gsoc-adminosgeo.org" <gsoc-ad...@osgeo.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

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

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á <kratocha...@gmail.com>
wrote:

> Hi Vero,
>
> On Wed, Oct 4, 2017 at 11:24 AM, Veronica Andreo <veroand...@gmail.com>
> 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] 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 <hel...@web.de> 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] [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 <pesej.ond...@gmail.com>
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] 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 <nete...@osgeo.org> 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

[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] [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 <ptsch...@ncsu.edu> 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 <adam.st...@anu.edu.au> 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 <ptsch...@ncsu.edu> 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] Fwd: GSoC : Students application period has started!

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Tue, Mar 21, 2017 at 8:56 AM
Subject: GSoC : Students application period has started!
To: OSGeo-SoC <s...@lists.osgeo.org>, 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] Reviewing GSoC 2017 page

[Margherita Di Leo]

On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras <wenzesl...@gmail.com> 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

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 <direg...@gmail.com>
wrote:

>
>
> On Wed, Oct 19, 2016 at 11:56 AM, Margherita Di Leo <direg...@gmail.com>
> 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

[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] Default behavior of g.list displaying all mapsets content

[Margherita Di Leo]

On Wed, Oct 19, 2016 at 11:56 AM, Margherita Di Leo <direg...@gmail.com>
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

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

[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

[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

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 <direg...@gmail.com>
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 <veroand...@gmail.com
>>> <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

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 <veroand...@gmail.com
>> <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]

Hi,

On Fri, Sep 23, 2016 at 12:00 AM, Markus Neteler <nete...@osgeo.org> 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

[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] [SoC]Week-12 WebGrass

[Margherita Di Leo]

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

Il domenica 14 agosto 2016, Mayank Agrawal <mayankagrawal...@gmail.com> 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

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 <direg...@gmail.com>
wrote:

> Markus,
>
> On Sun, Jun 12, 2016 at 5:41 PM, Markus Neteler <nete...@osgeo.org> wrote:
>
>> On Sat, Jun 11, 2016 at 10:10 PM, Margherita Di Leo <direg...@gmail.com>
>> 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=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] Problem georeferencing vectors with g.gui.gcp

[Margherita Di Leo]

Markus,

On Sun, Jun 12, 2016 at 5:41 PM, Markus Neteler <nete...@osgeo.org> wrote:

> On Sat, Jun 11, 2016 at 10:10 PM, Margherita Di Leo <direg...@gmail.com>
> 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=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

[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

[GRASS-dev] Fwd: GSoC 2016: call for mentors

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Wed, Mar 2, 2016 at 6:03 PM
Subject: GSoC 2016: call for mentors
To: OSGeo-SoC <s...@lists.osgeo.org>, OSGeo Discussions <
disc...@lists.osgeo.org>


Dear All,

Following the acceptance of OSGeo as mentor org also this year, we are now
recruiting mentors! Remember that mentors are the building blocks of GSoC:
we are not going anywhere without you! [1]

There is nothing like automatic mentors renewal. If you are available for
mentoring this year (again), you need to fill in this simple form [2] and
read and commit to the mentors’ responsibilities here [3]. If you’re not
yet subscribed to the soc ML [4], please do so. Remember that we require
two mentors for each accepted idea: so please spread the word among your
community and recruit mentors!

Looking forward to build a strong team of geo-mentors!

Madi and Anne

your OSGeo GSoC admins

[1]
https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fi.qkme.me%2F36e89g.jpg=1

[2]
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016_Administrative#Mentors

[3]
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016_Administrative#A_Mentor.27s_Responsibilities

[4] http://lists.osgeo.org/mailman/listinfo/soc


-- 
Margherita Di Leo



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

[GRASS-dev] Fwd: [@Mentors: Action required] GSoC 2016 Ideas page

[Margherita Di Leo]

-- Forwarded message --
From: Margherita Di Leo <direg...@gmail.com>
Date: Tue, Feb 16, 2016 at 11:16 AM
Subject: [@Mentors: Action required] GSoC 2016 Ideas page
To: OSGeo Discussions <disc...@lists.osgeo.org>, OSGeo-SoC <
s...@lists.osgeo.org>
Cc: Anne Ghisla <a.ghi...@gmail.com>


Dear All,

we would like to inform you all that we have applied on behalf of OSGeo, as
a mentor organization for Google Summer of Code 2016. The application can
be found at [1]. We ask your cooperation to set up the ideas page within
few days. It is extremely important that the ideas page looks in good shape
as it is the key page Google will be looking at when evaluating OSGeo. As
usual, each community will set up its ideas page on its own wiki and will
send us the link, that will be added by us to the main page [2]. Please
forward this email to your communities.

As past years, OSGeo welcomes like minded projects that wish to participate
under the org’s umbrella, not being official OSGeo projects. Please contact
us to discuss it further.

Your OSGeo GSoC 2016 Admins

Margherita Di Leo (madi)

Anne Ghisla (aghisla)

[1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Application_2016

[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016_Ideas


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

Re: [GRASS-dev] hierarchical segmentation

[Margherita Di Leo]

On Fri, Jan 22, 2016 at 10:48 AM, Martin Landa <landa.mar...@gmail.com>
wrote:

> Hi,
>
> 2016-01-22 9:34 GMT+01:00 Markus Neteler <nete...@osgeo.org>:
>
> there were more issues, fixed in r67621:3. Ma
>

Thanks, it works now.

>
>
>


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

Re: [GRASS-dev] hierarchical segmentation

[Margherita Di Leo]

On Fri, Jan 22, 2016 at 9:23 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/01/16 11:13, Margherita Di Leo wrote:
>
>> Hi,
>>
>> I haven't been using lately i.segment.hierarchical (addon), at the time
>> I installed it the first time (2014) I remember I had to tweak the
>> installation because it wouldn't compile. Today I tried g.extension and
>> it doesn't compile, but I forgot the trick meanwhile ..
>> I can dig into it, ok, but can't this be fixed?
>>
>
> I don't have time right now, but a few weeks ago I successfully installed
> and used i.segment.hierarchical. IIRC, there was an error message during
> the g.extension run, but the module ran fine nevertheless.


For the record, the trick that worked for me: I svn'ed in
/home/user/.grass7/addons/etc/ the whole i.segment.hierarchical folder, and
copied  i.segment.hierarchical.py into /home/user/.grass7/addons/scripts,
but removed the .py extension.

>
>
> and moreover, as it is
>> such a convenient tool to be used in combination with i.segment,
>> wouldn't its place better be merged with i.segment, perhaps adding an
>> option for performing hierarchical segmentation?
>>
>
> I don't know if it has to be merged (I prefer many specialised modules
> instead of one that does it all), but I agree that it might have its place
> in trunk.
>
> Moritz
>



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

[GRASS-dev] hierarchical segmentation

[Margherita Di Leo]

Hi,

I haven't been using lately i.segment.hierarchical (addon), at the time I
installed it the first time (2014) I remember I had to tweak the
installation because it wouldn't compile. Today I tried g.extension and it
doesn't compile, but I forgot the trick meanwhile ..
I can dig into it, ok, but can't this be fixed? and moreover, as it is such
a convenient tool to be used in combination with i.segment, wouldn't its
place better be merged with i.segment, perhaps adding an option for
performing hierarchical segmentation?
Dai Pietro..! :)

Cheers,

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

[GRASS-dev] problem installing wx.metadata from g.extension

[Margherita Di Leo]

Hi,

I have problem installing wx.metadata via g.extension:

> g.extension wx.metadata
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File
"/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/scripts/g.gui.metadata",
line 45, in 
from mdpdffactory import PdfCreator
  File "../mdlib/mdpdffactory.py", line 13, in 
from reportlab.platypus import Paragraph, Image, Table
ImportError: No module named reportlab.platypus
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat
‘/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/docs/html/g.gui.metadata.html’:
No such file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
WARNING: Installation failed, sorry. Please check above error messages.

GRASS trunk installation updated today. ~/.grass7/addons was clean.
wx.metadata specific dependencies installed

Any pointers?
Thank you in advance

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

Re: [GRASS-dev] problem installing wx.metadata from g.extension

[Margherita Di Leo]

Figured out I missed dependency python-reportlab. Not sure it's written
anywhere in https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support ,
I'm updating now the wiki page.

Thanks




On Mon, Jan 11, 2016 at 11:59 AM, Margherita Di Leo <direg...@gmail.com>
wrote:

> Hi,
>
> I have problem installing wx.metadata via g.extension:
>
> > g.extension wx.metadata
> Fetching  from GRASS GIS Addons repository (be patient)...
> Compiling...
> Traceback (most recent call last):
>   File
> "/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/scripts/g.gui.metadata",
> line 45, in 
> from mdpdffactory import PdfCreator
>   File "../mdlib/mdpdffactory.py", line 13, in 
> from reportlab.platypus import Paragraph, Image, Table
> ImportError: No module named reportlab.platypus
> make[1]: *** [g.gui.metadata.tmp.html] Error 1
> Installing...
> /usr/bin/install: cannot stat
> ‘/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/docs/html/g.gui.metadata.html’:
> No such file or directory
> make[1]: *** [install] Error 1
> make: *** [installsubdirs] Error 2
> WARNING: Installation failed, sorry. Please check above error messages.
>
> GRASS trunk installation updated today. ~/.grass7/addons was clean.
> wx.metadata specific dependencies installed
>
> Any pointers?
> Thank you in advance
>
> --
> 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] [OSGeo-Discuss] Call For papers Geospatial devroom @FOSDEM 2016

[Margherita Di Leo]

Hi All,

this is a gentle reminder that the deadline for talk proposals is tomorrow,
**1st December 2015**.
Looking forward to see your contributions.

Thank you and best regards,


On Mon, Nov 2, 2015 at 8:22 AM, Johan Van de Wauw <johan.vandew...@gmail.com
> wrote:

> 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 the last weekend ofJanuary
> 30 - 31 2016. This year for the second time there will be a Geospatial
> devroomon Sunday 31/1/2016, organised by members of the OSGeo,
> Locationtech and OpenStreetMap communities.
>
> Geospatial technology is becoming rapidly mainstream. The idea
> underpinning the geospatial devroom is bringing together developers
> with different backgrounds to disclosethe opportunities offered by
> cutting-edge open source geospatial technologies. Due to the success
> of last years devroom, a Belgium local chapter of OSGeo, OSGeo.be was
> founded, and is now taking part of the organisation of the devroom as
> driving community.
>
> The Geospatial devroom is the place to talk about the state of the art
> of open, geo-related data, free and open source geospatial software
> and its ecosystem. This includes standards and tools, e.g. spatial
> databases, online mapping tools, geospatial services, used for
> collecting, storing, delivering, analysing, and visualizing geodata.
> We welcome submissions about:
>
> * Web and desktop GIS applications
> * Interoperable geospatial web services and specifications
> * Collection of data using sensors/drones/satellites
> * Open hardware for geospatial applications
> * Geo-analytic algorithms/libraries
> * Geospatial extensions for classical databases (indexes, operations)
> and dedicated databases
> * Collaborative editing/versioning of geodata
> * Big geodata, scalable GIS applications
> * Volunteered Geograpic information - Crowdsourced data
>
> 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 using the Pentabarf event planning tool at:
>
> https://penta.fosdem.org/submission/FOSDEM16
>
> Make sure to select the 'Geospatial devroom' as  'Track'. Please,
> specify in the notes if you prefer for your presentation either a
> short timeslot (lightning talks ~10 minutes) or along timeslot (20
> minutes presentation + discussion). However, note that time slots are
> indicative and will be assigned according to the needs of the session.
>
> The DEADLINE for submissions is Tuesday **1st December 2015**.
> Notification of acceptance will be sent to the Authors by Friday
> 11/12/2015 at the latest.
>
> Should you have any questions, please do not hesitate to get in touch
> with the organisers of the devroom at fosdem-geospat...@gisky.be!
>
> Johan Van de Wauw
> Margherita Di Leo
> Astrid Emde
> Anne Ghisla
> Martin Hammitzsch
> Andy Petrella
> Dirk Frigne
> Olivier Courtin
> Thomas Gratier
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss




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

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Margherita Di Leo]

On Mon, Jun 22, 2015 at 4:35 PM, Martin Landa landa.mar...@gmail.com
wrote:

 Hi,

 2015-06-22 16:32 GMT+02:00 Margherita Di Leo direg...@gmail.com:
  (known)
  https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS

 probably should be moved (merged) to

 https://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

  http://gismentors.cz/mentors/landa

I would keep the two pages separated for historical reasons (two GSoC
projects in two different years) but I suggest to cross link the two pages
and move the todo list to the new one. Maybe also to file a bug request for
each task?


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Margherita Di Leo]

On Mon, Jun 22, 2015 at 4:44 PM, Margherita Di Leo direg...@gmail.com
wrote:



 On Mon, Jun 22, 2015 at 4:35 PM, Martin Landa landa.mar...@gmail.com
 wrote:

 Hi,

 2015-06-22 16:32 GMT+02:00 Margherita Di Leo direg...@gmail.com:
  (known)
  https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS

 probably should be moved (merged) to

 https://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

  http://gismentors.cz/mentors/landa

 I would keep the two pages separated for historical reasons (two GSoC
 projects in two different years) but I suggest to cross link the two pages
 and move the todo list to the new one. Maybe also to file a bug request for
 each task?

 whereas I suppose the stable documentation should eventually land on the
(same as last year project) wiki page
http://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Margherita Di Leo]

Hi,

On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I understand
 correctly that by default, neither the basic, nor the inspire template
 contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the metadata.
 What help is the bounding box info, if we don't know in which CRS it is ?


I agree that it sounds strange, however the bounding box is given in
geographic (unprojected) coordinates, and the ISO 19115:2003, where the
GeographicBoundingBox comes from, reads (B.3.2.1): geographic position of
the dataset NOTE This is only an approximate reference so specifying the
coordinate reference system is unnecessary 


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Margherita Di Leo]

On Mon, Jun 22, 2015 at 4:02 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 On 22/06/15 15:40, Margherita Di Leo wrote:

 Hi,

 On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert
 mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be
 wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I
 understand correctly that by default, neither the basic, nor the
 inspire template contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the
 metadata. What help is the bounding box info, if we don't know in
 which CRS it is ?


 I agree that it sounds strange, however the bounding box is given in
 geographic (unprojected) coordinates, and the ISO 19115:2003, where the
 GeographicBoundingBox comes from, reads (B.3.2.1): geographic position
 of the dataset NOTE This is only an approximate reference so specifying
 the coordinate reference system is unnecessary 


 Using g.gui.metadata on the hospitals map in nc_spm_08, I get:

   gmd:extent
 gmd:EX_Extent
 gmd:geographicElement
 gmd:EX_GeographicBoundingBox
 gmd:westBoundLongitude
 gco:Decimal308097.937400562/gco:Decimal
 /gmd:westBoundLongitude
 gmd:eastBoundLongitude
 gco:Decimal20235.5644005626/gco:Decimal
 /gmd:eastBoundLongitude
 gmd:southBoundLatitude
 gco:Decimal914347.8748615/gco:Decimal
 /gmd:southBoundLatitude
 gmd:northBoundLatitude
 gco:Decimal156998.1718615/gco:Decimal
 /gmd:northBoundLatitude
 /gmd:EX_GeographicBoundingBox
 /gmd:geographicElement
 /gmd:EX_Extent
 /gmd:extent

 Looks like projected coordinates to me...


I would say this is a bug.



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Margherita Di Leo]

On Mon, Jun 22, 2015 at 4:12 PM, Margherita Di Leo direg...@gmail.com
wrote:



 On Mon, Jun 22, 2015 at 4:02 PM, Moritz Lennert 
 mlenn...@club.worldonline.be wrote:

 On 22/06/15 15:40, Margherita Di Leo wrote:

 Hi,

 On Mon, Jun 22, 2015 at 10:18 AM, Moritz Lennert
 mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be
 wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I
 understand correctly that by default, neither the basic, nor the
 inspire template contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the
 metadata. What help is the bounding box info, if we don't know in
 which CRS it is ?


 I agree that it sounds strange, however the bounding box is given in
 geographic (unprojected) coordinates, and the ISO 19115:2003, where the
 GeographicBoundingBox comes from, reads (B.3.2.1): geographic position
 of the dataset NOTE This is only an approximate reference so specifying
 the coordinate reference system is unnecessary 


 Using g.gui.metadata on the hospitals map in nc_spm_08, I get:

   gmd:extent
 gmd:EX_Extent
 gmd:geographicElement
 gmd:EX_GeographicBoundingBox
 gmd:westBoundLongitude

 gco:Decimal308097.937400562/gco:Decimal
 /gmd:westBoundLongitude
 gmd:eastBoundLongitude

 gco:Decimal20235.5644005626/gco:Decimal
 /gmd:eastBoundLongitude
 gmd:southBoundLatitude
 gco:Decimal914347.8748615/gco:Decimal
 /gmd:southBoundLatitude
 gmd:northBoundLatitude
 gco:Decimal156998.1718615/gco:Decimal
 /gmd:northBoundLatitude
 /gmd:EX_GeographicBoundingBox
 /gmd:geographicElement
 /gmd:EX_Extent
 /gmd:extent

 Looks like projected coordinates to me...


 I would say this is a bug.


(known)
https://trac.osgeo.org/grass/wiki/GSoC/2014/MetadataForGRASS#TODOIDEAS


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.proj produces null map

[Margherita Di Leo]

Hi,

on G7, I made several tentatives trying to reproject raster maps using
r.proj, it doesn't yield error but the map is completely empty (null). I
made several tentatives on several maps, then also exported and reprojected
with gdalwarp, to test if the problem was related to the data. Can someone
reproduce this, before i open a ticket.

Thank you

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.proj produces null map

[Margherita Di Leo]

[forgot the list ]

On Mon, May 18, 2015 at 8:35 AM, Margherita Di Leo direg...@gmail.com
wrote:



 On Mon, May 18, 2015 at 8:18 AM, Martin Landa landa.mar...@gmail.com
 wrote:



 are you sure that you have set in destination location region
 correctly? See r.proj's -g flag.


 I think so, unless I can't see the obvious... here's an example

 r.proj -g input=accum location=GMTED2010-wgs84
 mapset=res075
 n=3036289.28490875 s=1327842.48956189 w=3859987.52509802
 e=5240836.36134497 rows=7200 cols=7200

 the region in the destination mapset is
 g.region -p
 projection: 99 (Lambert Azimuthal Equal Area)
 zone:   0
 datum:  etrs89
 ellipsoid:  grs80
 north:  3036500
 south:  1327500
 west:   3859750
 east:   5241000
 nsres:  250
 ewres:  250
 rows:   6836
 cols:   5525
 cells:  37768900


 r.proj input=accum location=GMTED2010-wgs84 mapset=res075 output=acc_prova
 method=nearest

 Input:
 Cols: 7202 (7200)
 Rows: 7200 (7200)
 North: 49.999861 (49.999861)
 South: 34.999861 (34.999861)
 West: 364.995694 (4.999861)
 East: 379.999861 (19.999861)
 EW-res: 0.002083
 NS-res: 0.002083

 Output:
 Cols: 5524 (5525)
 Rows: 6834 (6836)
 North: 3036250.00 (3036500.00)
 South: 1327750.00 (1327500.00)
 West: 3859750.00 (3859750.00)
 East: 5240750.00 (5241000.00)
 EW-res: 250.00
 NS-res: 250.00

 Allocating memory and reading input raster map...
 Projecting...
 r.proj complete.


 r.info acc_prova

  
 ++
  | Map:  acc_prova  Date: Mon May 18 08:26:37
 2015|
  | Mapset:   wetness-idxLogin of Creator:
 user|
  | Location:
 GMTED2010-LAEA   |
  | DataBase:
 /home/user/GIS/grassdata |
  | Title: ( acc_prova
 )   |
  | Timestamp:
 none|

  
 ||
  |
 |
  |   Type of Map:  raster   Number of Categories:
 0   |
  |   Data Type:
 DCELL  |
  |   Rows:
 6834   |
  |   Columns:
 5524   |
  |   Total Cells:
 37751016   |
  |Projection: Lambert Azimuthal Equal
 Area|
  |N:3036250S:1327750   Res:
 250 |
  |E:5240750W:3859750   Res:
 250 |
  |   Range of data:min = -nan  max =
 -nan |
  |
 |
  |   Data
 Description:|
  |generated by
 r.proj |
  |
 |
  |
 Comments:|
  |r.proj input=accum location=GMTED2010-wgs84 mapset=res075
 outp\   |
  |ut=acc_prova method=nearest
 memory=300  |
  |
 |

  
 ++




 --
 Best regards,

 Dr. Margherita DI LEO
 Scientific / technical project officer

 European Commission - DG JRC
 Institute for Environment and Sustainability (IES)
 Via Fermi, 2749
 I-21027 Ispra (VA) - Italy - TP 261

 Tel. +39 0332 78 3600
 margherita.di-...@jrc.ec.europa.eu

 Disclaimer: The views expressed are purely those of the writer and may not
 in any circumstance be regarded as stating an official position of the
 European Commission.




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

On Tue, May 5, 2015 at 3:30 AM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2015-05-05 12:28 GMT+02:00 Margherita Di Leo direg...@gmail.com:

  being name one of the two options (name, pat) that could be identifier=
 or
  something better. In this case, it would be possible to type the former
  command or the extended form:
 
  g.remove type=vect identifier=name name=foo -f
  or
  g.remove type=vect identifier=pattern name=f* -f
  (g.remove vect pat f* -f)
 
  what do you think?

 no idea, in any case it's issue for GRASS 8. Martin


Sure. Is there any place (track? wiki?) already where to collect and
discuss ideas? I saw recently in ML another post about r.shaded.relief, I
haven't followed up but perhaps also that discussion could be included.

Thanks

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

Hi Moritz,

On Tue, May 5, 2015 at 2:27 PM, Moritz Lennert mlenn...@club.worldonline.be
 wrote:

 On 05/05/15 12:28, Margherita Di Leo wrote:

 Dear All,

 I find the current syntax of g.remove a bit cumbersome, because it
 doesn't seem to me in line with what happens with other commands.
 If I want to remove the vector file foo, I have to type:

 g.remove vect name=foo -f

 Without the name= it won't work, which is not in line to the usage of
 other commands.
 To me it would be more natural (and indeed i always type wrong the first
 time) something like:

 g.remove vect name foo -f

 being name one of the two options (name, pat) that could be identifier=
 or something better. In this case, it would be possible to type the
 former command or the extended form:

 g.remove type=vect identifier=name name=foo -f
 or
 g.remove type=vect identifier=pattern name=f* -f
 (g.remove vect pat f* -f)

 what do you think?


 AFAIK, this would mean a fundamental change in the way the parser works.


hmm.. I don't understand why. I tried to tailor this proposal on the
current behavior of the parser, as far as I could understand it. Can you
explain a bit more?


 I think it might be better to create small wrapper scripts, e.g.:

 g.remove.vect

 which could use just the name option of g.remove to have a syntax such as
 this:

 g.remove.vect foo -f

 If you use GNU/Linux you can also do this very simply by defining a
 function in .grass7/bashrc:

 g.remove.vect ()
 {
 g.remove type=vect name=$@
 }


Thanks for the idea, I'll try .



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

Dear All,

I find the current syntax of g.remove a bit cumbersome, because it doesn't
seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:

g.remove vect name=foo -f

Without the name= it won't work, which is not in line to the usage of
other commands.
To me it would be more natural (and indeed i always type wrong the first
time) something like:

g.remove vect name foo -f

being name one of the two options (name, pat) that could be identifier= or
something better. In this case, it would be possible to type the former
command or the extended form:

g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name=f* -f
(g.remove vect pat f* -f)

what do you think?

Thank you

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Select vector feature - Error

[Margherita Di Leo]

Hi,

when i try to select a feature with the select vector feature button from
map display, I get an Error pop up that reads:

Error occured during calling of handler: _onMapClickHandler
Handler was unregistered.

Reason: VectorSelectBase instance has no attribute 'map'

Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/gui/wxpython/mapwin/base.py, line 191, in
HandlersCaller
handler(event)
  File /usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py, line
187, in _onMapClickHandler
vWhatDic = self.QuerySelectedMap()
  File /usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py, line
272, in QuerySelectedMap
message=_(Failed to query vector map(s) %s.) % self.map)
AttributeError: VectorSelectBase instance has no attribute 'map'

Thanks

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Make it clearer that GRASS 7.0 is the version to go for now

[Margherita Di Leo]

Hi,

On Tue, Feb 24, 2015 at 4:15 PM, Vaclav Petras wenzesl...@gmail.com wrote:



 Others, feel free to go through the website and catch obsolete info such
 as what is current release. There might be more.


 Probably also
http://grass.osgeo.org/documentation/general-overview/#AboutGRASS6
http://grass.osgeo.org/documentation/general-overview/#AboutGRASS7

Should be updated accordingly. (*GRASS GIS 7* is under development with a
first releases in preparation)

Perhaps the about GRASS6 should become less visible, as now is the first
that meets the eye.



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Make it clearer that GRASS 7.0 is the version to go for now

[Margherita Di Leo]

On Tue, Feb 24, 2015 at 5:23 PM, Paulo van Breugel p.vanbreu...@gmail.com
wrote:



 On Tue, Feb 24, 2015 at 4:58 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Feb 24, 2015 at 4:25 PM, Margherita Di Leo direg...@gmail.com
 wrote:
  Probably also
  http://grass.osgeo.org/documentation/general-overview/#AboutGRASS6
  http://grass.osgeo.org/documentation/general-overview/#AboutGRASS7
 
  Should be updated accordingly. (GRASS GIS 7 is under development with a
  first releases in preparation)
 
  Perhaps the about GRASS6 should become less visible, as now is the
 first
  that meets the eye.



 Agree, and therefore I would put 'About GRASS GIS 7' first, followed by
 the 'About GRASS GIS 6' paragraph (or leave the latter out altogether).

 That paragraph also links to the wikipedia about GRASS should perhaps be
 added to the paragraph 'About GRASS GIS 7' instead (The *GRASS GIS 7* 
 (Wikipedia
 entry http://en.wikipedia.org/wiki/GRASS_GIS) ...). And there is a
 small typo in that paragraph: A full temporal framwork - e missing in
 framework.

 This btw means the Wikipedia article should be adapted too. I would
 suggest the sentence 'GRASS 6.4.0 introduced a new generation of graphical
 user interface called *wxGUI*. wxGUI is designed using Python
 http://en.wikipedia.org/wiki/Python_%28programming_language%29
 programming language and wxPython http://en.wikipedia.org/wiki/WxPython
 graphical library' should be replaced with the short description, perhaps
 based on the above mentioned 'About GRASS GIS 7' paragraph?, i.e.,

 The latest  stable release version (LTS) is GRASS GIS 7, which is
 available since 2015. It offers, amongst others, large data support, an
 improved topological 2D/3D vector engine and much improved vector network
 analysis. Attributes are managed by default in SQLite format. The display
 manager has been improved for usability. The NVIZ visualization tool was
 completely rewritten. Image processing has also been improved. A full
 temporal framework has been added. See more details at New Features
 https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures.


 I agree with all these changes and I would bring the sentence: GRASS GIS
6.x is the old stable version. as starting sentence of the paragraph GRASS
GIS 6.


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Which GRASS version to install in a university Lab?

[Margherita Di Leo]

Ciao Nikos,

On Thu, Feb 12, 2015 at 11:06 AM, Nikos Alexandris n...@nikosalexandris.net
wrote:

 Dear devs, and power-users,

 which GRASS GIS version would you recommend for a University Lab with 40
 computers?  Stay with 6.4  or  jump into 7.0 RC2?  I recommended to wait
 some time as important changes may be backported from trunk to 7.0, just
 before the final release.


From my experience as a user, G7 has improved dramatically respect to 6, in
new functionalities but especially for the capacity of handling large data
sets.

cheers,
madi


 Thank you, Nikos

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




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Preparation of ideas pages for GSoC 2015 (deadline: 18th February!)

[Margherita Di Leo]

Dear All,

*(Apologies for cross posting)*

*GSoC 2015* was officially announced earlier this year. The applications
for mentoring organizations are now open and this year Hamish Bowman and
myself will be applying for OSGeo's participation.

The application deadline for mentoring organizations is the 20th of
February, and right after that, Google will proceed examining the
organizations. The showcase for evaluating the applications are the GSoC
ideas pages [1], and for this reason, they need to be in perfect shape.
This means that OSGeo teams are required to set up and shape their pages *this
week*, coordinating their teams through their dev mailing lists. The pages
will then linked to the main GSoC 2015 ideas page on the wiki.

Please bear in mind that there is no guarantee whatsoever of the acceptance
by Google based on the success of previous years, but they will judge the
organizations *only on the basis of ideas pages for 2015.*

Please forward this email to your project leaders and past GSoC mentors,
and start listing ideas right away!

Please cc soc list with your doubts and questions.


 [1] http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] G71 errors at startup

[Margherita Di Leo]

Hi,

just updated GRASS 7.1.svn (r64526), (after make clean, make distclean, svn
up etc..)
At start up I get the following:

r.area: Unable to fetch interface description for command 'r.area'.

Details: ERROR: Module built against version $Revision: 59317 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

r.regression.series: Unable to fetch interface description for command
'r.regression.series'.

Details: ERROR: Module built against version $Revision: 60387 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

r.stream.basins: Unable to fetch interface description for command
'r.stream.basins'.

Details: ERROR: Module built against version $Revision: 59317 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

r.stream.order: Unable to fetch interface description for command
'r.stream.order'.

Details: ERROR: Module built against version $Revision: 62060 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

r.stream.snap: Unable to fetch interface description for command
'r.stream.snap'.

Details: ERROR: Module built against version $Revision: 62060 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

r.stream.stats: Unable to fetch interface description for command
'r.stream.stats'.

Details: ERROR: Module built against version $Revision: 62060 $ but trying
to use
   version $Revision: 63930 $. You need to rebuild GRASS GIS or
   untangle multiple installations.

wx.metadata: Unable to fetch interface description for command
'wx.metadata'.

Details: [Errno 2] No such file or directory



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G71 errors at startup

[Margherita Di Leo]

On Mon, Feb 9, 2015 at 3:03 PM, Margherita Di Leo direg...@gmail.com
wrote:

 Hi,

 just updated GRASS 7.1.svn (r64526), (after make clean, make distclean,
 svn up etc..)
 At start up I get the following:

 r.area: Unable to fetch interface description for command 'r.area'.

 Details: ERROR: Module built against version $Revision: 59317 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 r.regression.series: Unable to fetch interface description for command
 'r.regression.series'.

 Details: ERROR: Module built against version $Revision: 60387 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 r.stream.basins: Unable to fetch interface description for command
 'r.stream.basins'.

 Details: ERROR: Module built against version $Revision: 59317 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 r.stream.order: Unable to fetch interface description for command
 'r.stream.order'.

 Details: ERROR: Module built against version $Revision: 62060 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 r.stream.snap: Unable to fetch interface description for command
 'r.stream.snap'.

 Details: ERROR: Module built against version $Revision: 62060 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 r.stream.stats: Unable to fetch interface description for command
 'r.stream.stats'.

 Details: ERROR: Module built against version $Revision: 62060 $ but trying
 to use
version $Revision: 63930 $. You need to rebuild GRASS GIS or
untangle multiple installations.

 wx.metadata: Unable to fetch interface description for command
 'wx.metadata'.

 Details: [Errno 2] No such file or directory


I removed all the addons and now I don't get the error any longer. But
still don't understand why i got this.


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G71 errors at startup

[Margherita Di Leo]

Luca,

On Mon, Feb 9, 2015 at 3:21 PM, Luca Delucchi lucadel...@gmail.com wrote:

 Ciao Madi,

 On 9 February 2015 at 15:11, Margherita Di Leo direg...@gmail.com wrote:
 
 
  I removed all the addons and now I don't get the error any longer. But
 still
  don't understand why i got this.
 


 http://osgeo-org.1560.x6.nabble.com/check-on-GRASS-revision-number-td5175139.html


Thank you. However it seems to me that the behavior is different. In the
case of Michael, he is launching r.flip and getting the error. This has
happened to me in the past with some addons, and i have reinstalled them
against current version. However in this  case, I'm just launching grass,
and getting error without calling any addons.




 --
 ciao
 Luca

 http://gis.cri.fmach.it/delucchi/
 www.lucadelu.org




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2

[Margherita Di Leo]

Hi,

On Thu, Feb 5, 2015 at 9:18 AM, Vincent Bain b...@toraval.fr wrote:

 Hi,

 prior to plan or not voting, maybe everyone could give his/her opinions
 on the talk page Martin set up last friday:

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

 (I made an update of the proposal this morning)


what an amazing range of proposals, is really difficult to choose. Thank
you for your work !
Perhaps in D1 the grass symbol and the writing perhaps should be slightly
moved to right, because the symbol appears cut.
Is there particular reason why grass is in bold and gis not? I would
like it better to have the same rule for both words, because a different
style is already applied to the slogan, I would reduce the diversity.

Thank you again!
madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Margherita Di Leo]

On Fri, Jan 23, 2015 at 2:30 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:

 On Fri, Jan 23, 2015 at 1:14 PM, Yann Chemin yche...@gmail.com wrote:
 
 
 
  hmm that would be cool !
  running r(v).in.* without GISDBASE or Location or mapset could trigger a
  wizard to set them up...

 This is the current location wizard.

 The original topic was import and on-the-fly reprojection without the
 need to create a new location. This can be easily done by either a new
 script that calls r.in.gdal/v.in.ogr + r.proj/v.proj which creates the
 new location internally and deletes it when done, or a wizard doing
 the same thing. The user does not even notice that a temporary
 location was created. Sextante for example works this way.



This would be lovely to have! Perhaps using ogr2ogr / gdalwarp before
importing would be even faster.


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Margherita Di Leo]

Hi,

On Fri, Jan 23, 2015 at 2:10 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:


 That is why I suggested a minimal (minimal information content)
 welcome screen with one OK button and one change button. The OK button
 should be prominently placed, the user must immediately see that all
 is needed to get started is to press OK. This welcome screen could be
 written such that practically nothing but wx needs to be imported,
 which means that the splash screen can go away. Because of the little
 amount of content (text + buttons), there would be enough space for
 graphics even on small screens.

 You could have drop-down boxes for location and mapset to offer a
 choice instead of fixed text.


Do I understand correctly that such drop-down boxes to change current
location and mapset are to be found at the stage when GRASS is already
started? Meaning that you are in a XY empty location and you can choose to
go directly to a different one without restarting GRASS? If this is your
proposal, I  think that this would indeed do a huge difference to anyone
working in grass, not only newcomers, in terms of practicality





-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Margherita Di Leo]

Hi,

On Wed, Jan 21, 2015 at 4:55 PM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, Jan 21, 2015 at 8:16 PM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:
  On 21/01/15 19:35, Markus Neteler wrote:
  In my opinion we should not have the location selection dialog at all.
  Revolution!
 
  We should start GRASS right away in latlong like most GIS in the world.
 
  Then let the user open the dialog to change projection if desired from
  inside.
 
  This would avoid a lot of questions right away.
 
  Please don't do this !

 OK, now being back from phone to a real keyboard, I can write a few more
 lines.

 I am thinking about this issue for seeral years meanwhile (hint: I
 started in 1993 to use the software, getting stuck at the text start
 screen not having a manual :-).

 So my full suggestions are
 - beautify the actual screen (hence my recent suggestion which is
 lively discussed here),
 - optionally (!) allow to start GRASS without welcome/loc/mapset
 screen but to open it in LatLong as described above. Again, as an
 option. We could implement that in trunk and see how it goes. All the
 tools to select locations, projections and such are there.


I understand that for some users GRASS looks strange at first sight,
because I'm aware that nearly nobody reads the manual *before* trying to
start a new software. Because humans work like this, at first they want to
try, and later, if the process of natural curiosity is supported by
positive feedback of experience, they keep on going, learn new stuff, read
the manual etc.
What I don't understand here is how an empty lat lon location would help in
this.
If the purpose is to allow the user to explore the software without any
previous knowledge (well actually something can be done also here, we could
create a getting started video) why not allowing the user to double click
on their map and open grass from it. This would not need any change in the
grass structure itself, it could just be a demo. I think to a script in
python that reads the info from a file (gdalinfo), creates a demo location,
opens grass and import the file.

Just thoughts

cheers,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call

[Margherita Di Leo]

Hi,

I read the document and support it,

On Wed, Jan 7, 2015 at 10:20 PM, Markus Neteler nete...@osgeo.org wrote:



 Last doubts:

 * Step1:  The Project manager (or if exists the Release manager)
 then collects reactions to decide whether there is sufficient support
 for this proposal. 

 -- this sufficient is still a bit elastic. If one developer is
 against it, others in favour, it is fine to start? Leave it to
 democratical debates? Just to be sure.


To me this makes sense, because it's a good thing that the release manager
should have the chance to make a decision on a case by case basis. I'm more
in favor of do-ocracy rather than democratical debate ;-) but it's just my
opinion


  Just a minor comment is that we shall probably clearly specify who is
  responsible for the mentioned actions: call for soft, hard freeze etc.

 That's the release manager. But I added that now (looks more dramatic
 than it is, trac doesn't highlight well this time).:


 http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=16old_version=13

 ... makes sense?


+1

Thank you
Margherita



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] gui crashes G7

[Margherita Di Leo]

Hi,

I'm experiencing several GUI crashes in a row. Here's what I do:

* Load a raster map in map layer.
* Load a vector map (points) and customize symbol. Here an error message
appears in terminal: (python:23987): Gtk-CRITICAL **:
IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed
* Add legend for raster map from GUI. Sometimes it crashes at this stages.
Some other times it crashes the instant when I click on Save display to
file. It doesn't crash all the times but, say, 50% of the times.

Fedora 20
GRASS 7.1.svn (r63559)
wxPython-2.8.12.0-5
Python 2.7.5

Is anyone able to reproduce that or is it a local problem?
Thank you

madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gui crashes G7

[Margherita Di Leo]

Markus,

On Tue, Dec 30, 2014 at 7:36 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Dec 30, 2014 at 7:23 PM, Margherita Di Leo direg...@gmail.com
 wrote:
 
  appears in terminal: (python:23987): Gtk-CRITICAL **:
  IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

 ... this GTK problem happens on many systems with various software
 packages. The internet is full of such reports, so it is probably not
 an issue.


I know, I reported for completeness.


 No error message? Not even in the (wxGUI) console?


Actually there was no wxgui console left after crash to see...  the only
error was several times the GTK stuff in the terminal.



 I have also Fedora 20, revision=63875M, works fine.
 Be sure to run make distclean when recompiling. We made heavy changes
 lately.


 it seems to work after updating. Thank you!

cheers,
madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: FOSDEM 2015

[Margherita Di Leo]

Hi,

On Mon, Nov 24, 2014 at 2:19 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 On 21/11/14 10:23, Markus Neteler wrote:

 On Thu, Nov 20, 2014 at 10:10 AM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:

 On 17/11/14 15:45, Moritz Lennert wrote:

 As you can see below, Margherita contacted me concerning a GRASS
 presentation at the geospatial devromm foreseen for the first time at
 the upcoming FOSDEM.


 (here the conf link: https://fosdem.org/2015/ - Brussels / 31 January
  1 February 2015)

  I can present something, but would like to know

 1) if other devs are planning to attend and if yes, if they were
 planning to present anything


 I would be interested to go.


 Great !

  2) which themes you think would be the most interesting to present from
 a GRASS perspective

 Currently, I've been thinking about two themes:

 - The obvious what's new in GRASS 7, but I'm not sure that this is the
 most appropriate for the mostly developper crowd present at a FOSDEM.


 I have never participated but I could offer talks at various tech level :)

  - A focus on the different APIs in GRASS from C to pygrass to
 grass.script, explaining structure and use cases of each.

 Any other ideas ?


 - GRASS GIS and HPC (satellite data processing)


 If you want to go for one of the two themes, you are probably better
 qualified than me to present them. But I am willing to help where I can.

 Margherita, I don't know how many slots there are, but I guess that one
 for the GRASS project is enough ?


It is great to have you both there! Yes I think that dedicating one slot to
the grass project will make the conference more balanced respect to other
projects as well. Does it sound reasonable to you to share one slot?
Regarding the time available for each slot, I can't say nothing yet,
because we will try to balance the time according to all the proposals that
are coming. I'll keep you posted.

Thank you!


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: FOSDEM 2015

[Margherita Di Leo]

Hi,

On Mon, Nov 17, 2014 at 3:45 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 Hello,

 As you can see below, Margherita contacted me concerning a GRASS
 presentation at the geospatial devromm foreseen for the first time at the
 upcoming FOSDEM.

 I can present something, but would like to know

 1) if other devs are planning to attend and if yes, if they were planning
 to present anything
 2) which themes you think would be the most interesting to present from a
 GRASS perspective

 Currently, I've been thinking about two themes:

 - The obvious what's new in GRASS 7, but I'm not sure that this is the
 most appropriate for the mostly developper crowd present at a FOSDEM.

 - A focus on the different APIs in GRASS from C to pygrass to
 grass.script, explaining structure and use cases of each.

 Any other ideas ?

 Moritz



Thank you Moritz for bringing the discussion in ML. Just to put it in
context, see at:
http://geofemengineering.blogspot.it/2014/10/call-for-papers-geospatial-devroom.html

Hope to see many of you there!!

cheers,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

[Margherita Di Leo]

Hi,

On Tue, Oct 7, 2014 at 6:22 PM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2014-10-07 17:32 GMT+02:00 Markus Neteler nete...@osgeo.org:

 [...]

  Concerning the release branch of GRASS 7, in r59606 the r.stream.*
  modules got disabled.
  If they are not yet production ready, should we move them back to Addons?

 MarkusM: Is there any chance to fix them before releasing G70?

 If not I would suggest to move them back to Addons... Martin


 Can I urge please to take a decision, either ways.

Thank you,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

[Margherita Di Leo]

Hi Swapan,


On Sun, Jul 20, 2014 at 10:47 PM, Swapan Ghosh swap.g...@gmail.com wrote:

 Dear all,

 I succesfully the module r.hazards.flood.py in windows xp but fail in
 windows 7.


how does it fail? do you get any error messages? do you have the
dependencies installed (r.area) ?
which revision of grass are you using?
standalone or osgeo4w?
have you tried also running it on grass 6.4.4 and/or nightly build 7.0.0?

Please let us know.

cheers,
madi



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] gsoc2014 grass metadata week 6

[Margherita Di Leo]

Hi Stefan,
On Thu, Jul 3, 2014 at 9:46 AM, Blumentrath, Stefan 
stefan.blumentr...@nina.no wrote:

 Hi Matej,



 Thanks for your reply.

 Metadata is a current topic I my organization at the moment, so your work
comes exactly at the right time for me. Here in NINA people are using many
different kinds of GIS software and we are considering introducing
GeoNetwork as a central metadata storage solution, which makes metadata
management to some extend independent from the GIS software used. Among
public and environmental organisations, GeoNetwork is quite popular for
metadata management (amongst others Mapping authorities from Netherlands,
Switzerland, and the Nordic countries are using it, see also:
http://geonetwork-opensource.org/gallery/gallery.html).



 I have no real personal experience with GeoNetwor (yet), but from what I
read in the documentation I could imagine two ways how GRASS metadata could
make their way into such a central metadata catalogue:

 1)  XML import (+ this option is in place when GRASS metadata is
written to XML, - import requires manual labor)

 2)  Metadata harvesting (GeoNetwork can “harvest” metadata from other
CSWs, so maybe pycsw already provides automatic an interface in that
direction(?). That would be great!)

pycsw is a CSW server that allows to harvest information from other OGC
services, as well as Geonetwork. This latter offers also the editor, while
pycsw doesn't, but is used internally by other applications which offer
full metadata management (and a GUI), such as CKAN, GeoNode, etc. and the
idea is to add GRASS to this list as well :-)
If you want to stick with geonetwork, you can harvest the metadata from the
pycsw, there's no need of manual work.




 When it comes to consistent metadata, I guess e.g. lists with values for
metadata fields will in practice have to be more or less dynamic (as new
staff member are being employed, new topics for spatial analysis arise
(requiring new keywords), new types of data being developed and so on). Not
sure if manipulating the templates is convenient enough for average users
(seems to be mainly suitable for users with some degree of programming
experience). However, good to know that providing a custom set of values is
already possible through the templates.

 If you start working on a DB for metadata related content, feel free to
let me know if I can support you by any means (yet I will be on leave for
almost the rest of the year, which means I can spend only a limited amount
of time).

The idea is to allow user to generate a custom template using the gui, that
can be reused for any metadata generated afterwards. Your idea of a
database deserves consideration as well

Thanks
Madi


 However, I had a second look on GeoNetwork in this regard, and GeoNetwork
is (naturally) using a database for metadata management (one option here is
PostgreSQL). If it would be possible to just connect to that same DB (e.g.
for fetching and storing key words, data on contact persons…), that would
be really, really great, as this ensures that metadata produced in GRASS
are 100% compliant to metadata standards used in GeoNetwork (if GRASS users
also use GeoNetwork).



 Anyway, Rome was not built in a day and I am 100% sure that your work
will be very, very useful already from what you planned for GSoC.



 All the best,

 Stefan


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


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.

Hi Matej,



Thanks for your reply.

Metadata is a current topic I my organization at the moment, so your work
comes exactly at the right time for me. Here in NINA people are using many
different kinds of GIS software and we are considering introducing
GeoNetwork as a central metadata storage solution, which makes metadata
management to some extend independent from the GIS software used. Among
public and environmental organisations, GeoNetwork is quite popular for
metadata management (amongst others Mapping authorities from Netherlands,
Switzerland, and the Nordic countries are using it, see also:
http://geonetwork-opensource.org/gallery/gallery.html).



I have no real personal experience with GeoNetwor (yet), but from what I
read in the documentation I could imagine two ways how GRASS metadata could
make their way into such a central metadata catalogue:

1)  XML import (+ this option is in place when GRASS metadata is
written to XML, - import requires manual labor)

2)  Metadata harvesting (GeoNetwork can “harvest

[GRASS-dev] type of parameter resolution in g.region vs r.proj

[Margherita Di Leo]

Hi,

Apparently, for unprojected reference systems, r.proj doesn't accept the
parameter resolution expressed in DD:MM:SS, but only in decimal degrees (at
least for me, any other experience?), while for example g.region does
accept this format. The type of the parameter resolution is float for
r.proj and integer for g.region (as far as i can understand digging into
the source code). My (probably naive) question is : Wouldn't it make sense
to adopt integer type also for r.proj?

Thanks for any pointers

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo Google Summer of Code: 23 accepted students for 2014

[Margherita Di Leo]

FYI
Congrats to accepted students!

Cheers,
madi

-- Forwarded message --
From: Anne Ghisla a.ghi...@gmail.com
Date: Mon, Apr 21, 2014 at 9:13 PM
Subject: [OSGeo-Discuss] OSGeo Google Summer of Code: 23 accepted students
for 2014
To: OSGeo Google Summer of Code list s...@lists.osgeo.org, OSGeo Discuss
list disc...@lists.osgeo.org, ICA OSGeo Labs list 
ica-osgeo-l...@lists.osgeo.org


Hello all, and sorry for cross posting,

let us warmly welcome the 23 accepted students and their mentors for
this round of GSoC!

We received over 60 proposals from a variety of geospatial projects -
choosing wich ones to accept has been a difficult task, and we apologise
for not being able to take all the outstanding ones.

We accepted the following students (in software's alphabetical order):
* Cartaro: Naveen Panwar
* GDAL/OGR: Varun Saraf and Mikhail Gusev
* GeoNode: Vikas Mishra
* GRASS GIS: Vaclav Petras, Matej Krejci and Anna Petrasova
* gvSIG: Manuel Madrid and Oscar Martinez
* istSOS: Priska Pietra
* MapServer: Jessica Lapointe
* Neo4j: William Lyon
* Opticks: Roberta Ravanelli
* OpenStreetMap: Lukasz Gurdek
* OSSIM: Martina Di Rita
* Orfeo Toolbox (OTB): Martina Porfiri
* PostGIS: Mohit Kumar
* pgRouting: Manikanta Kondeti and Mukul Priya
* pyWPS: Anna Homolka
* Software packaging: Jerome Villeneuve Larouche
* QGIS: Nishith Maheshwari
* uDig/GeoTools: Silvia Franceschi

This list includes OSGeo projects (official and incubating) and
like-minded projects - let GSoC be a gathering of tribes, an occasion
to improve communication among all geospatial open source initiatives.

See the full list of OSGeo accepted proposals here:
https://www.google-melange.com/gsoc/org2/google/gsoc2014/osgeo

We wish all students and mentors a great summer!

Anne, Hamish and Dustan
OSGeo GSoC Admins

___
Discuss mailing list
disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.


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

Re: [GRASS-dev] TOC in the manual

[Margherita Di Leo]

Hi Martin,


On Fri, Apr 11, 2014 at 10:38 AM, Martin Landa landa.mar...@gmail.comwrote:

 Hi all,

 in r59673 I introduced simple mechanism to add TOC to the manual pages. It
 needs
 some testing, anyway it seems to work. TOC is now fixed and width of
 body part is 80%, see eg. [1]. Since wxPython widget doesn't support
 most of css, it's shown before DESCRIPTION and not as fixed.


Thank you! Looks very fancy!

Talking about documentation, since GRASS has strong ties with academia,
what do you think about adding also a section cite as for the relevant
modules?

Thank you,
Madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

[Margherita Di Leo]

Rashad,

On Thu, Mar 6, 2014 at 10:28 AM, Rashad M mohammedrasha...@gmail.comwrote:

 Hello All,

 I would like to check with grass-devs about the possibility of having a
 web version of GRASS GIS as a part of SoC 2014. I had done some behind the
 scenes work for web version using C++ web toolkit Wt[1]. This involves
 running a grass modules online just like you do on Desktop with a UI that
 resembles that of wxGUI. I had been in touch with one of my juniors in my
 lab and he is interested to work on it. I could mentor this project as I
 had experience with Wt, GRASS and GSoC. I hope this web version will be
 very useful in both users and developers.

 Comments and suggestions are most welcomed.

 [1] http://www.webtoolkit.eu/wt


FWIW, I like this idea and would like to see it developed. Do you have a
prototype already?

Thanks,
madi




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] IDRA14: Open-source computing per le applicazioni idrologiche e idrauliche

[Margherita Di Leo]

Cari Colleghi e Amici,

nell'ambito del XXXIV Convegno Nazionale di Idraulica e Costruzioni
Idrauliche che si terrà a Bari l'8-10 Settembre 2014, desideriamo invitarvi
a partecipare alla sessione Open-source computing per le applicazioni
idrologiche e idrauliche.

La sessione prevede una breve presentazione dei contributi in forma orale,
una presentazione poster degli stessi, e la possibilità di effettuare in
loco dimostrazioni pratiche.

Ulteriori informazioni sono disponibili sul sito:
http://idra14.it/?q=node/74

La scadenza per l'invio dei sommari è fissata al 15 Marzo 2014.
Le istruzioni per l'invio dei contributi sono disponibili all'indirizzo:
http://idra14.it/?q=content/info-call-abstracts-e-registrazione-al-sito

Cordiali saluti,

Margherita Di Leo
Giuseppe Formetta
Attilio Castellarin
Alberto Viglione

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] IDRA14: Open-source computing per le applicazioni idrologiche e idrauliche

[Margherita Di Leo]

Oops
this was meant for grass-italia ML


2014-02-28 14:50 GMT+01:00 Margherita Di Leo direg...@gmail.com:

 Cari Colleghi e Amici,

 nell’ambito del XXXIV Convegno Nazionale di Idraulica e Costruzioni
 Idrauliche che si terrà a Bari l'8-10 Settembre 2014, desideriamo invitarvi
 a partecipare alla sessione Open-source computing per le applicazioni
 idrologiche e idrauliche.

 La sessione prevede una breve presentazione dei contributi in forma orale,
 una presentazione poster degli stessi, e la possibilità di effettuare in
 loco dimostrazioni pratiche.

 Ulteriori informazioni sono disponibili sul sito:
 http://idra14.it/?q=node/74

 La scadenza per l'invio dei sommari è fissata al 15 Marzo 2014.
  Le istruzioni per l'invio dei contributi sono disponibili all'indirizzo:
 http://idra14.it/?q=content/info-call-abstracts-e-registrazione-al-sito

 Cordiali saluti,

 Margherita Di Leo
 Giuseppe Formetta
 Attilio Castellarin
 Alberto Viglione

 --
 Best regards,

 Dr. Margherita DI LEO
 Scientific / technical project officer

 European Commission - DG JRC
 Institute for Environment and Sustainability (IES)
 Via Fermi, 2749
 I-21027 Ispra (VA) - Italy - TP 261

 Tel. +39 0332 78 3600
 margherita.di-...@jrc.ec.europa.eu

 Disclaimer: The views expressed are purely those of the writer and may not
 in any circumstance be regarded as stating an official position of the
 European Commission.

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




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Margherita Di Leo]

Hi All,


On Mon, Feb 24, 2014 at 8:22 PM, Martin Landa landa.mar...@gmail.comwrote:

 Hi,

 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová tfiedler...@gmail.com:
  finally I considered the metadata topic is probably the most appropriate
 for
  me. My aim now is to find out as much as I can about it to have better
 idea
  what is going on. If you have any additional information or resources I
  could study, please let me know. Thanks


Tereza, I'm glad to hear that. As several hints have already come, I'd
suggest to set a page in the trac where we can store all these inputs that
otherwise would be difficult to find again.


 perfect, in this regard I would like to open discussion whether to
 speak just about metadata (ISO, Inspire) or also about  supporting
 Inspire services (view and download)...


Martin, this makes sense, but I'd stick with a target that is reachable
within the GSoC. Of course the occasion is suitable to gather all the ideas
which can be developed in the future.

Thanks,
MaDi



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Margherita Di Leo]

Hi Tereza!


On Thu, Feb 20, 2014 at 9:08 AM, Tereza Fiedlerová tfiedler...@gmail.comwrote:


 And one more question. Is any of these topics suitable for me if I am not
 experienced in GRASS at all?

 Please consider the idea on metadata, that requires a limited knowledge of
GRASS I would say



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Proposal for GSoC idea on INSPIRE

[Margherita Di Leo]

Hi,


On Tue, Jan 28, 2014 at 5:30 PM, Vaclav Petras wenzesl...@gmail.com wrote:




 On Tue, Jan 28, 2014 at 11:12 AM, Moritz Lennert 
 mlenn...@club.worldonline.be wrote:

 On 28/01/14 16:00, Margherita Di Leo wrote:

 Hi All,

 I'd like to bring a proposal for the forthcoming GSoC, that is the
 support for INSPIRE. This proposal is twofold, one regarding the
 metadata support, the other regarding the support for the data
 transformation to meet the inspire schema. I would like to know your
 opinion before drafting the idea into the trac. I'm willing to mentor
 for the INSPIRE POV, and since I'm working at JRC I have the opportunity
 to take advantage of a direct contact with the very people who are
 developing the Directive. Martin Landa kindly made himself available to
 co-mentor from the GRASS POV.


 +1, but I think we should aim for generic metadata handling and then
 allow the use of specific schemas such as INSPIRE.

 INSPIRE is using some more general ISO standards, isn't it?


Correct: it is build on ISO 19100 series of International Standards. See
[1].
I fully agree that the general aim should be a unified system to handle
metadata (as Yann said, interchangable and exportable into online systems).
As I see it, the editor should remain general, to meet the users needs. See
for example Geonetwork, it's possible to add or remove fields without
restriction.
The INSPIRE schema is a plus for the user, meaning that there will be
specific hints to guide the user, i.e. direct links with the parts of the
regulation involved in the compilation of each field of the metadata (see
for example [2]), the possibility to validate the metadata calling the API
of the INSPIRE validator [3], etc.


 QGIS metatools is a nice example of such a generic tool allowing for
 specification of different schemas and for different outputs through the
 use of XSLT conversion.

 QGIS compatibility would be appreciated by a lot of users and it might
 even show the way to go.


I agree.


 Some other thing to consider is how this metadata support would interact
 with existing r.support, r.timestamp etc. I remember that Yann and NikosA
 was talking about this in Genova in 2013.


If the GSoC idea will be accepted, I'd appreciate their contribution to the
discussion.

[1]
http://geostandards.geonovum.nl/index.php/6.4.6_ISO_19100_series_of_International_Standards
[2] http://inspire-geoportal.ec.europa.eu/editor/
[3] http://inspire-geoportal.ec.europa.eu/validator2/

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Proposal for GSoC idea on INSPIRE

[Margherita Di Leo]

Hi All,

I'd like to bring a proposal for the forthcoming GSoC, that is the support
for INSPIRE. This proposal is twofold, one regarding the metadata support,
the other regarding the support for the data transformation to meet the
inspire schema. I would like to know your opinion before drafting the idea
into the trac. I'm willing to mentor for the INSPIRE POV, and since I'm
working at JRC I have the opportunity to take advantage of a direct contact
with the very people who are developing the Directive. Martin Landa kindly
made himself available to co-mentor from the GRASS POV.

cheers,
madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

[Margherita Di Leo]

Hi


On Thu, Jan 9, 2014 at 1:25 PM, Johannes Radinger 
johannesradin...@gmail.com wrote:



 So for the meanwhile I can use the workaround with compiling r.stream.*
 directly with the source for G7, however maybe other users in future are
 also interested in using these add-ons and will face similar problems I did.


sorry if OT but did I miss something? I thought r.stream* were going to
core..?

cheers,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] EGU 2014

[Margherita Di Leo]

** Apologies for any cross posting **

Dear All,

for your info, there will be a couple of appointments of interest for FOSS
users/developers/strugglers at EGU 2014 [1]:

HS3.3 Open Source Computing in Hydrology | PICO
Sessionhttp://meetingorganizer.copernicus.org/EGU2014/session/14311

and

ESSI2.7: Free and Open Source Software (FOSS) for Geoinformatics and
Geosciences http://meetingorganizer.copernicus.org/EGU2014/session/15502

The *deadline* for submissions is *16 January 2014* (13:00 CET)

As past years, there will be also Splinter session to discuss FOSS GIS
within EGU/AGU, followed by a meeting with local FOSS activists. The point
of contact for the latter is Mr Helmut Kudrnovsky (in CC).

Happy new year!


[1] European Geosciences Union http://www.egu2014.eu/, General Assembly
2014, Vienna, Austria, 27 April – 2 May, 2014

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.null apparently doesn't work on vrt via r.external on G7

[Margherita Di Leo]

Hi All,

Is it an expected behaviour that r.null doesn't affect vrt raster linked
via r.external?
Tested on forest map 2000 available for download from
http://forest.jrc.ec.europa.eu/download/data/forest-data-download/
I build the mosaic with gdalbuildvrt and then use r.external
then I want to set to null the values 0,2,3:
r.null mosaic setnull=0-2-3
this command doesn't have any effect on the map.

thanks

madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] Vienna Code Sprint 2014: Meet (also) GRASS GIS developers

[Margherita Di Leo]

Hi All


On Tue, Dec 17, 2013 at 10:43 PM, Anne Ghisla a.ghi...@gmail.com wrote:

 On Tue, 17 Dec 2013 21:13:16 +0100
 Martin Landa landa.mar...@gmail.com wrote:

  Dear all,
 
  2013/12/14 Markus Neteler nete...@osgeo.org:
   OSGeo » Code Sprint 2014
  Get together, hack, decide, tackle large geospatial problems,
   have fun, and explore a city.
   March 24th to 28th. Vienna, Austria.
   http://vienna2014.sprint.osgeo.org/
  
   Register at:
   http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014
  
   We could consider it as a GRASS GIS Community Sprint oppurtunity,
   too :-)
 
  one big +1 for this idea. BTW, QGIS hackfest will be also there.

 Same for me, Stephan confirmed that there is plenty of space
 http://vienna2014.sprint.osgeo.org/2013/12/16/venue.html

 Shall we decide for an official GRASS hackfest there, as QGIS did?


+1

ciao madi



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G7 compilation error

[Margherita Di Leo]

* SOLVED *

On Thu, Dec 12, 2013 at 2:18 PM, Margherita Di Leo 
dileomargher...@gmail.com wrote:


 compiling the fresh grass trunk I get several compilation issues on tgrass
 and some wxpython modules (animation, vdigit, iclass) and the problem
 resides into:
 ImportError: /usr/local/lib/libgdal.so.1: undefined symbol:
 sqlite3_column_table_name


The problem resides in an old version of sqlite that I was using, coming
from package:

=

$ rpm -qi sqlite3-dbf.x86_64
Name: sqlite3-dbf  Relocations: (not relocatable)
Version : 2011.01.24
Vendor: Fedora Project
Release : 1.el6 Build Date: Sat 11 Feb 2012
10:50:28 AM CET
Install Date: Mon 16 Dec 2013 10:58:33 AM CET  Build Host:
x86-15.phx2.fedoraproject.org
Group   : Applications/Text Source RPM:
sqlite3-dbf-2011.01.24-1.el6.src.rpm
Size: 49144License: GPLv3+
Signature   : RSA/8, Sat 11 Feb 2012 05:49:50 PM CET, Key ID
3b49df2a0608b895
Packager: Fedora Project
URL : http://sqlite.mobigroup.ru/wiki?name=sqlite3-dbf
Summary : Converter of XBase / FoxPro tables to SQLite
Description :
SQLiteDBF converts XBase databases, particularly FoxPro tables with memo
files,
into a SQL dump. It has no dependencies other than standard Unix libraries.

SQLiteDBF is designed to be incredibly fast and as efficient as possible.

This use code base of the PgDBF project (http://pgdbf.sourceforge.net/).

=

compiling sqlite from scratch solved the issue.
Thanks Markus and Yann for the pointers.

cheers,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G7 compilation error

[Margherita Di Leo]

Dear Markus,

thank you for answering, but I'm still struggling.


On Thu, Dec 12, 2013 at 2:41 PM, Markus Neteler nete...@osgeo.org wrote:

 On Thu, Dec 12, 2013 at 2:18 PM, Margherita Di Leo
 dileomargher...@gmail.com wrote:
  Hi All,
 
  compiling the fresh grass trunk I get several compilation issues on
 tgrass
  and some wxpython modules (animation, vdigit, iclass) and the problem
  resides into:
  ImportError: /usr/local/lib/libgdal.so.1: undefined symbol:
  sqlite3_column_table_name
  I just updated also the gdal trunk. Any pointers on whether this is a
  problem in gdal, grass or sqlite3 (I use the EPEL sqlite-devel pakage)

 Be sure that all used packages are built against the same library version.
 The ldd command is useful to figure out the who calls whom.


cool command, thanks. But I don't know if in this case is useful:
http://pastebin.com/h7ig0iT0 doesn't tell me a lot.
What I did in order to try to solve the issue:

I removed the fresh gdal trunk installation and opted for the package
coming from ELGIS (I had also tried with the version 1.9.2 compiled by
myself, because i used to have it compiled without problem before upgrading
to gdal trunk and before updating the grass trunk). As a result, I receive
the same compilation error: http://pastebin.com/S8EUEZjK

Of course at any tentative I ran make clean and make distclean.
Any pointers?

Thanks

madi




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] G7 compilation error

[Margherita Di Leo]

Hi All,

compiling the fresh grass trunk I get several compilation issues on tgrass
and some wxpython modules (animation, vdigit, iclass) and the problem
resides into:
ImportError: /usr/local/lib/libgdal.so.1: undefined symbol:
sqlite3_column_table_name
I just updated also the gdal trunk. Any pointers on whether this is a
problem in gdal, grass or sqlite3 (I use the EPEL sqlite-devel pakage)

Thank you in advance


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: Google Summer of Code 2014

[Margherita Di Leo]

FYI

-- Forwarded message --
From: Carol Smith car...@google.com
Date: Tue, Oct 8, 2013 at 9:02 PM
Subject: Google Summer of Code 2014
To: Google Summer of Code Announce 
google-summer-of-code-annou...@googlegroups.com


Hi all,

We're pleased to announce that Google Summer of Code will be happening
for its tenth year this year. Please check out the blog post [1] about
the program and read the FAQs [2] and Timeline [3] on Melange for more
information. We're doing a bunch of things to celebrate the 10th
anniversary of the program. Check out our blog post to learn more!

[1] -
http://googleblog.blogspot.com/2013/10/50-million-lines-of-code-and-counting.html
[2] -
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page
[3] - http://www.google-melange.com/gsoc/events/google/gsoc2014

Cheers,
Carol

--
You received this message because you are subscribed to the Google Groups
Google Summer of Code Announce group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-annou...@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-summer-of-code-announce.
For more options, visit https://groups.google.com/groups/opt_out.



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Problem installing r.modis on trunk

[Margherita Di Leo]

Hi,


On Tue, Oct 8, 2013 at 9:13 AM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Oct 8, 2013 at 4:46 AM, Pierre Roudier pierre.roud...@gmail.com
 wrote:
  Hi,
 
  I'm having a wee problem trying to compile r.modis on the trunk
  version of GRASS. It does not seem to compile the pymodis library if
  I'm getting that right:

 On Fedora 19 no problem:


I confirm Pierre's problem, with slightly different messages (Red Hat):

Fetching r.modis from GRASS-Addons SVN (be patient)...
Compiling...
/bin/sh:
/space/gis/grass_trunk/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c:
No such file or directory
sed: couldn't flush stdout: Broken pipe
make[1]:
[/space/gis/grass_trunk/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c]
Error 1 (ignored)
/bin/sh:
/space/gis/grass_trunk/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c:
No such file or directory
sed: couldn't flush stdout: Broken pipe
make[1]:
[/space/gis/grass_trunk/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c]
Error 1 (ignored)
Installing...
Updating metadata file...
Installation of r.modis successfully finished





  GRASS 7.0.svn (eda-rsr):~  g.extension ext=r.modis
  Fetching r.modis from GRASS-Addons SVN (be patient)...
  WARNING: gnome-keyring:: couldn't connect to:
  /tmp/keyring-CTEtVP/pkcs11: No such file or directory
  Compiling...
  /bin/sh: 1: cannot create
 
 /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c:
  Directory nonexistent

 Does at least /usr/local/grass-7.0.svn/locale/ exist?


In my case it does.

HTH,
madi


-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Problem installing r.modis on trunk

[Margherita Di Leo]

Markus,


On Tue, Oct 8, 2013 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Oct 8, 2013 at 9:45 AM, Margherita Di Leo
 dileomargher...@gmail.com wrote:
  On Tue, Oct 8, 2013 at 9:13 AM, Markus Neteler nete...@osgeo.org
 wrote:
  
 /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c:
   Directory nonexistent
 
  Does at least /usr/local/grass-7.0.svn/locale/ exist?

 So this one is missing?
 /space/gis/grass_trunk/grass-7.0.svn/locale/scriptstrings/


Yes I confirm that one is missing.
Another strange fact that might be of interest: the r.modis folder is
download in:
/space/gis/grass_trunk/grass-7.0.svn/
Is it the expected behavior?

Thanks,
madi



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Video Flashback 1987: Shatner Tells You Where You Can Stick Your Maps

[Margherita Di Leo]

Dear GRASS people,

you must see this piece of history :-) (thanks to Peter Loewe who
discovered it on the web)
http://www.wired.com/wiredscience/2013/08/shatner-loves-digital-maps/

cheers,
madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] redirect graphic output of r.spread

[Margherita Di Leo]

Hi,


On Wed, Sep 18, 2013 at 1:07 AM, Hamish hamis...@yahoo.com wrote:

 Margherita wrote:
  Any idea on how to (and IF it's possible to) redirect the graphic
  output of r.spread module to a gif or mov or avi file instead of
  to (or beside to) the monitor?

 not directly, but you might see the screencast section in:
   http://grasswiki.osgeo.org/wiki/Movies


Thanks for the link. But I don't understand how to put this in practice. I
mean, as far as I understand, you're suggesting to run r.spread in a loop,
each step producing a final map as image and then compose together as a
video, right? I had also thought something of the kind, but I was looking
for a way to save the detailed fire evolution as it is generated by
r.spread, hence a way to redirect the output directly to a video, or at
least save several static images while r.spread is running, and then to
compose them as a movie. Is that feasible?

Thanks



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] redirect graphic output of r.spread

[Margherita Di Leo]

Hi!

Any idea on how to (and IF it's possible to) redirect the graphic output of
r.spread module to a gif or mov or avi file instead of to (or beside to)
the monitor?

Many thanks in advance

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev