Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi there,

st 13. 3. 2024 v 1:36 odesílatel Vaclav Petras  napsal:
> On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek  wrote:
>> @Vaclav: Do you have some more points against the master-children
>> schema? It seems that the general agreement is *for* the restructuring
>> into parent and children teams. So far the only point against was "I
>> didn't find team nesting particularly useful and we already had a
>> couple of top-level teams."
>
>
> ...and I didn't see it working for GDAL with people both in the parent team 
> and child teams and repos being assigned to both levels.
>
> How do you suggest we do it? Empty parent team without repos? Would that look 
> good?

According to [1], all the child teams inherit the rights of their
parents. Therefore, I guess that having one empty parent with no
rights is okay and the correct way (also, you can see all children
members there, so it does not "look" empty even if it does not have
any member). Then we could go one of the two ways:
* Having all the current teams as child teams of the master team
* Having it more structured (grass-addons, grass, grass-website/promo)

I prefer the second way (some rights could then be propagated, I
guess) but would appreciate even the first one as it would clean up
the overview a lot.


>> Although I appreciate all the work you
>> dedicate to the GitHub management, I don't think that this is a valid
>> point against when compared to the positive ones (although it's
>> understandable that nobody wants to drop something that they have just
>> created).
> Thanks. It is more that before it was a high priority for me to get access 
> rights in order (access rights to individuals both directly and through 
> teams, inactive people from 2000s and early 2010s grandfathered into GitHub 
> write access, ...). These parent-child teams are low priority compared to 
> that.

Okay, thanks for the explanation. I see the reasoning behind the drop
of the priority and cannot disagree - nobody even seemed to notice
that before. I agree that there are many more important things to do.
Although I still think it would help the situation in the github
teams.

st 13. 3. 2024 v 1:57 odesílatel Even Rouault
 napsal:
> FYI I see this thread referencing the GDAL github team organization. As far 
> as I know, nobody has "designed" it with deep thoughts. It has the current 
> structure most likely as an accident of history... If I were to design it, I 
> would keep it simple and stupid. With git workflows, the concept of 
> "committer" as in SVN era is kinda irrelevant. You just need a sufficient 
> number of people with appropriate push rights to merge the flow of incoming 
> PRs, but if you have more than 10 people with push rights in a single repo, 
> that is already quite big. My 2 cents, and running away as I've no idea how 
> the GRASS team works ;-)

Thanks for the insight, Even. It seems that I am very much on the side
of the accidental structure :-).

[1] 
https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#nested-teams
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi again,

Sorry to start revive the conversation from the silence but I have the
feeling that it would be good to reach some consensus before we should
let it rest.

@Vaclav: Do you have some more points against the master-children
schema? It seems that the general agreement is *for* the restructuring
into parent and children teams. So far the only point against was "I
didn't find team nesting particularly useful and we already had a
couple of top-level teams." Although I appreciate all the work you
dedicate to the GitHub management, I don't think that this is a valid
point against when compared to the positive ones (although it's
understandable that nobody wants to drop something that they have just
created).

Cheers from the discussion underworld,
Ondrej

čt 22. 2. 2024 v 9:35 odesílatel Ondřej Pešek  napsal:

>
> Sweet devs,
>
> Looking at the GitHub teams within the OSGeo organisation [1], it is
> impossible not to notice the fact that the GRASS people are very good
> in making themselves visible through visual weed infestation. On one
> side, it is nice to see GRASS all over the dance floor; on the other
> one, I don't find it particularly polite to storm the org and see that
> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
> total).
>
> Wouldn't it be better to follow the example of GDAL instead? Creating
> only one master team (grass) and then 11 child teams (grass-write,
> grass-addons-write, ...)? It would make the org team overview much
> cleaner. Also, you could see all grass child teams' members in one
> place.
>
> In the name of New GitHub Order,
> Ondrej
>
> PS: I also believe that we should reduce the number of GRASS teams and
> consolidate some (grass-addons-subversion-committers ->
> grass-addons-write) but I guess this is for another and much more
> contentious discussion.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Hi Vaclav, Huidae,

I was afraid of a long discussion (I know that the teams were changed
recently and expected the consolidation to need more talks) and that's
why I wanted to split it into two different threads: 1) master team
and child teams, 2) necessity of all the teams we have. But whatever,
let's then continue in both.

Before inline comments, let me say that I understand that we somehow
feel a "need" to have more teams than the other. I have never been
against that, only mentioning that maybe we don't need such a vast
number and that the master team would make it look nicer.

čt 22. 2. 2024 v 22:20 odesílatel Vaclav Petras  napsal:
> If we say we want to cut down the number of teams, we can remove one or more 
> of the following: 1 or 2 Subversion teams (legacy, but both are in use now), 
> homebrew-docker team (complete legacy), grass-addons-write (could be merged 
> with grass-write depending on how much it will be used, it has one person who 
> is not in grass-write), grass-promo-write (can be merged with 
> grass-website-write depending on in which way the grass-promo repo will be 
> used).

I would vote for getting rid of the legacy teams. I believe that the
subversion team members could be consolidated into grass-write and
grass-addons-write. I don't see any added value of the subversion ones
except for flexing with "I've been here before you". I don't have
anything against keeping those two separate as I see a difference in
the repo's nature - the fact that the users are almost the same is
just a current state and could change in the future.

I don't have a strong opinion on the need of extra grass-promo-write.
If you think it could be merged with grass-website-write, cool with me
but I see some meaning there (as you answered to Huidae, "We may trust
someone to manage a collection of materials in grass-promo, but we may
want higher scrutiny for the grass-website repo which goes live after
PR is merged")

> We are not yet making use of the Maintain team (1 extra team).

Is there a plan for what it will be used? The members are the same as
of grass-admin. Is its purpose so different from the one of the admin
team?

> On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev 
>  wrote:
>>
>> Ondrej,
>>
>> I agree with you that there are too many teams for GRASS [1] and they should 
>> be consolidated (or not, but at least moved) as child teams.
>>
>> Do we still need these subversion teams?
>> * grass-subversion-committers GRASS GIS Subversion committers
>> * grass-addons-subversion-committers GRASS GIS Addons Subversion committers
>
>
> These are people who had access in the Subversion times. We want these past 
> Subversion-time contributors to have Triage rights (whatever that means). The 
> grass-addons repo works differently, so the Subversion-time group has Write 
> access there, but that can be changed in the future easily as this group from 
> pre-GitHub times is separate from the active group in grass-addons-write.

Isn't there grass-triage group for those whom we want to have Triage rights?

>> I think we need this team.
>> * grass-docker-homebrew-users Users for automated dockerhub and homebrew 
>> builds
>
>
> I don't know why we have that. It works for notifications, but I haven't seen 
> that used.

Another potential candidate for disintegration then?

>> On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev 
>>  wrote:
>>> Looking at the GitHub teams within the OSGeo organisation [1], it is
>>> impossible not to notice the fact that the GRASS people are very good
>>> in making themselves visible through visual weed infestation. On one
>>> side, it is nice to see GRASS all over the dance floor; on the other
>>> one, I don't find it particularly polite to storm the org and see that
>>> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
>>> total).
>
> Is that a practical problem for anyone?

Not being a practical problem does not mean it cannot be done in a better way.

>>>
>>> Creating
>>> only one master team (grass) and then 11 child teams (grass-write,
>>> grass-addons-write, ...)? It would make the org team overview much
>>> cleaner.
>
> Seeing how GDAL handles that, I didn't find team nesting particularly useful 
> and we already had a couple of top-level teams.
>
>>>
>>> Also, you could see all grass child teams' members in one
>>> place.
>
> That is still the only advantage I see, but then again, we already had 
> several teams and I created the new ones on the same level.

I meant one master team not several ones.

I personally do find a structured way of storing information useful
(more than in an unstructured way).

[GRASS-dev] GRASS Teams on GitHub

[Ondřej Pešek via grass-dev]

Sweet devs,

Looking at the GitHub teams within the OSGeo organisation [1], it is
impossible not to notice the fact that the GRASS people are very good
in making themselves visible through visual weed infestation. On one
side, it is nice to see GRASS all over the dance floor; on the other
one, I don't find it particularly polite to storm the org and see that
GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in
total).

Wouldn't it be better to follow the example of GDAL instead? Creating
only one master team (grass) and then 11 child teams (grass-write,
grass-addons-write, ...)? It would make the org team overview much
cleaner. Also, you could see all grass child teams' members in one
place.

In the name of New GitHub Order,
Ondrej

PS: I also believe that we should reduce the number of GRASS teams and
consolidate some (grass-addons-subversion-committers ->
grass-addons-write) but I guess this is for another and much more
contentious discussion.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Ondřej Pešek via grass-dev]

so 30. 9. 2023 v 16:12 odesílatel Markus Neteler via grass-dev
 napsal:
> As far as I see the git on Windows issue has been solved as well as
> many wxGUI bugs.
> Still a few to go which are under review. Shall we wait for them?
> Please let me know.

Not only Windows wxGUI issues. It is impossible to change the layout
from single window to the original one. I am using the original one
with students, meaning that I am still using 8.2.x with them.
Releasing 8.3.1 (where it is fixed) would let me to use 8.3.x versions
with them without forcing them to compile it on their own. (the
8.3.0-broken r.watershed is also used there)

So a new release would be appreciated also at my side.

But that's just my two cents.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8.3.0

[Ondřej Pešek]

čt 23. 3. 2023 v 10:53 odesílatel Markus Neteler  napsal:
> - i.vi: support soil_line_slope for PVI #2561, pesekon2

Merged in #2561. A follow-up update of the manual [1] is waiting for a
review and ready to be merged.

[1] https://github.com/OSGeo/grass/pull/2903
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GitHub backport label proposal

[Ondřej Pešek]

út 22. 11. 2022 v 14:24 odesílatel Markus Neteler  napsal:
> Our generic "backport" label seems to be mildly confusing (backport to
> which branch?).
>
> My suggestion is to adopt the approach of GDAL:
>
> - backport release 7.8
> - backport release 8.2
> ...

I like that.

But maybe keeping just the last versions? E.g., once the current
version of GRASS will be 8.7, it probably does not make sense to keep
the label backport_release_8.2, right? (just to avoid having 50 labels
just for backporting)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] new addon

[Ondřej Pešek]

út 1. 2. 2022 v 12:40 odesílatel Francesco Geri 
napsal:

> *git clone g...@github.com:fra-lab/grass.git
> *
>
> *Clone in 'grass' in corso...*
> *The authenticity of host 'github.com  (140.82.121.3)'
> can't be established.*
> *ECDSA key fingerprint is
> SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.*
> *Are you sure you want to continue connecting (yes/no/[fingerprint])? yes*
> *Warning: Permanently added 'github.com ,140.82.121.3'
> (ECDSA) to the list of known hosts.*
> *g...@github.com : Permission denied (publickey).*
> *fatal: Impossibile leggere dal repository remoto.*
> *Assicurati di disporre dei privilegi d'accesso corretti*
> *e che il repository esista.*
>
> In english:
>
>
>
>
> *fatal: Unable to read from remote repository. Make sure you have the
> correct access privileges and that the repository exists.*
>

Did you fork the repository before trying to clone it? I cannot see your
fork in the list of forks and also not on your profile when stalking it.

You can do it interactively at the website by going to [1] or [2]
(depending on whether you want to fork GRASS itself, or the addons
repository) and clicking on "Fork" in the upper right corner. If you didn't
do that, then the repository fra-lab/grass does not exist and therefore
couldn't be cloned.

[1] https://github.com/OSGeo/grass
[2] https://github.com/OSGeo/grass-addons
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Community sprint at FOSS4G 2021

[Ondřej Pešek]

Ciao,

st 29. 9. 2021 v 23:04 odesílatel Vaclav Petras 
napsal:

> We are having a community sprint on Saturday, October 2nd, 2021.
> Is anybody interested in working together during the European morning
> instead of waiting for the conference day to start?
>

I wanted to make a quick visit in the European morning, but just to do
something with the addons (as the grass8 branch is going to be created for
the sprint, right?). Maybe in the end I'll do also some source GRASS work,
but I am still not sure if I'll have enough time for that.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 8 addons

[Ondřej Pešek]

Hi Vaclav,

po 6. 9. 2021 v 3:39 odesílatel Vaclav Petras  napsal:

> The plan is to create one. You can follow the progress here:
> https://github.com/OSGeo/grass-addons/issues/528
>

I guess that I should finally clean my glasses. I have tried to check the
issues, but I have completely missed this one. Sorry for duplication then.
But I can still start one more conversation on GitHub discussions if you
want. :-)


> I'm waiting with the v8 addon branch for the v8 branch in core or close to
> 8.0.0 release. Partially, to avoid people having to make changes to both
> addon branches. However, it might be more advantageous at this point to
> create the v8 branch in addons since some infrastructure needs to be
> updated anyway. (Martin?)
>

Well, in the issue, there is a note that "The grass7 branch will be
superseded by the a branch called grass8 before the 8.0.0 release (likely
before branching off release branch for the 8.0 series)".

I support that because as far as I understand, the new version of
g.extension takes into consideration the current version of GRASS.
Therefore, having grass8 branch for addons should not hurt the current
behaviour (also we could then get rid of the if statement at [1] that does
not seem very self-justifying, at least to me - and it's exactly one of
those that gets forgotten in the source code and stays for aeons until
nobody knows what it does). We could keep the grass7 branch the default
one, start fixing the anticipated bugs, and then just switch the default to
grass8. What do you (all) think?

We would need to do some cherry-picking meanwhile probably, for those who
will not notice such change before grass8 becomes the default branch, but
there is not so much traffic in the addons; also, I guess that people
working with their own compiled version of GRASS will notice that.

Cheers,
Ondrej

(and sorry for the schisma of splitting the conversation between the mails
and the GH issue)

[1]
https://github.com/OSGeo/grass/blob/main/scripts/g.extension/g.extension.py#L245-L246
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 8 addons

[Ondřej Pešek]

Hey you lovely devs,

In some GRASS modules (e.g. v.db.select), there were certain changes
altering their interface between GRASS GIS 7 and the messianic GRASS GIS 8.
My question is - how to deal with that in the addons?

Currently, there is no GRASS 8 branch in the addons repo. Is there a plan
to create one, or are the changes considered too minor to open a new branch
for that? These changes probably do not affect a lot of addons, but there
are some, and we should approach them minorities with the same solicitude
and concernment as we do with the majorities.

Another solution is having some version checks in the GRASS 7 branch. But
personally, I do not support this idea as it seems weird to me to have an
if statement "if grass.__version__ > 7" in a code that is explicitly
defined as designated for GRASS 7.

Keep that GRASS growing strong,
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Website does not work with www for me

[Ondřej Pešek]

pá 14. 8. 2020 v 1:17 odesílatel Markus Neteler  napsal:

> Ondřej Pešek  schrieb am Do., 13. Aug. 2020,
> 23:50:
>
>> when I go to the GRASS website the lazy way without typing www (
>> grass.osgeo.org), I can load the page without a problem. However, when I
>> want to try it with www (www.grass.osgeo.org), I get the "Page not
>> found" error message.
>>
>> Is it just me? Is it normal?
>>
>
> It's expected as we don't have a DNS record for that
>
> Do we want that, too? I'd find it confusing, with and without www. But
> let's hear opinions!
>

As so far more voices can be heard saying yes, I have opened an issue for
that [1]. Feel free to tag the issue later with the `wontfix` label and
close it, but at least there will be a record of that decision.

[1] https://github.com/OSGeo/grass-website/issues/219
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Website does not work with www for me

[Ondřej Pešek]

Howdie,

when I go to the GRASS website the lazy way without typing www (
grass.osgeo.org), I can load the page without a problem. However, when I
want to try it with www (www.grass.osgeo.org), I get the "Page not found"
error message.

Is it just me? Is it normal? Is it internet mimicry? Is it something I
should open an issue at [1] for?

Thank you,
Ondřej

[1] https://github.com/OSGeo/grass-website
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] missing logs for Windows addons

[Ondřej Pešek]

Hi Moritz,

po 6. 1. 2020 v 16:56 odesílatel Moritz Lennert <
mlenn...@club.worldonline.be> napsal:

> I see that r.object.activelearning also fails with:
>
> "ModuleNotFoundError: No module named 'scipy'"
>
> Should this module be changed somehow to wrap the import in a way to
> only make it fail at runtime ? ISTR, there was a technique for that, or ?
>

A lazy import should do this for you.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS at FOSS4G

[Ondřej Pešek]

Hi,

st 5. 6. 2019 v 22:21 odesílatel Moritz Lennert <
mlenn...@club.worldonline.be> napsal:

> - Have you all booked housing already ? If not, should we try to find
>   some place (e.g. appartment) which could also be a place to work
>   together, or should we ask whether a room might be available at the
>   FOSS4G premises ?
>
>
So what's the state of this? Should I book something on myself or do we
want to try to set up a grassy place?

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

Re: [GRASS-dev] GRASS GIS at FOSS4G

[Ondřej Pešek]

Hi Moritz,

st 5. 6. 2019 v 22:21 odesílatel Moritz Lennert <
mlenn...@club.worldonline.be> napsal:

> - Who else will be in town at the beginning of the
> week ?
>

Most probably me. I still haven't booked the flight, but I think I will
book it either on Sunday or Monday.


> - Should we organise some form of small GRASS sprint on Monday and
>   Tuesday ?
>

I would be in.


> - Have you all booked housing already ? If not, should we try to find
>   some place (e.g. appartment) which could also be a place to work
>   together, or should we ask whether a room might be available at the
>   FOSS4G premises ?
>

The same as with tickets. Still haven't booked anything. And I don't have a
problem with a shared place.

Ciao,
Ondřej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] FOSS4G 2019 Bucharest Call for Contributions Open

[Ondřej Pešek]

so 9. 2. 2019 v 5:49 odesílatel Moritz Lennert 
napsal:

> On 8/02/19 18:03, Ondřej Pešek wrote:
> > Fr 8. 2. 2019 15:27 Veronica Andreo  > <mailto:veroand...@gmail.com>> wrote:
> >
> > Will you attend the conference, Ondrej?
> >
> >
> > Yes.
>
> And would you be willing to participate in the organisation of a remote
> sensing workshop in which we present the OBIA toolchain, but also your
> deep learning modules ?
>

I may try something. Unfortunatelly, only for the detection module I think.
Because a workshop for the training module would take a few days to train a
model.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] FOSS4G 2019 Bucharest Call for Contributions Open

[Ondřej Pešek]

Fr 8. 2. 2019 15:27 Veronica Andreo  wrote:

> Will you attend the conference, Ondrej?
>

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

Re: [GRASS-dev] Python scripts in GRASS GIS: conditional loading of external libraries?

[Ondřej Pešek]

Hi,

pá 19. 10. 2018 v 17:18 odesílatel Martin Landa 
napsal:

> pá 19. 10. 2018 v 16:45 odesílatel Markus Neteler 
> napsal:
> > we are currently writing a Python script which needs to import some
> > heavy external libraries.
>
> if I understand well, a lazy import could help
>
> """
> def main:
> from mylib import xyz
> ...
>
>return 0
>
> if __name__ == "__main__":
> opt, flg = grass.parser()
> sys.exit(main())
> """
>

In my  AddOn [1], I followed exactly this approach to avoid double import
of TensorFlow.

If I remember correctly, libraries imported before the call of
`grass.parser()` are imported also during the installation through
`g.extension` because of checks or something and you really don't want to
import quite heavy TensorFlow (which is moreover printing some warnings
during the import on most of computers) making your installation slow. The
same applied to the double import when running the script.

[1]
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.ann.maskrcnn/i.ann.maskrcnn.train/i.ann.maskrcnn.train.py?rev=72730#L181
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Access to GRASS GIS addons

[Ondřej Pešek]

čt 11. 10. 2018 v 17:24 odesílatel Vaclav Petras 
napsal:

> A 2016 GSoC project took different approach which could be reused in QGIS
> independently from the current GRASS Plugin or Processing plugin
> approaches. This is a good base for future work, perhaps even for
> auto-generating the files needed for GRASS plugin or Processing plugin.
>
> https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI
>


If you start QGIS from the GRASS GIS shell, then you can use a module
g.pyqt from the above-mentioned GSoC project and parse the name of the
AddOn as a parameter. It will generate the fully-working GUI for you.

So if you want to create a QGIS plugin and don't want to create the GUI
from scratch, then you can call something like `g.pyqt r.estimap` after
clicking on the icon of the plugin and it's done. However, it will still
work just with maps in GRASS, it will not import them into QGIS or
something, and there is also this strange thing about running QGIS from the
GRASS GIS shell.

And I didn't touch the code for some time, so there are still some places
which should be improved. But it should be working if you have your AddOn
installed in GRASS.

PS: I believe that the code can be also re-written to generate the QGIS
plugin GUI without all those strange necessities without so much work, but
unfortunately I don't have enough time to do it in the near future.
___
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

[Ondřej Pešek]

Hi Madi,

oh, I'm sorry. I have read that manual, but I have thought that the final
report will be the next one. My fault. So here it is reelaborated.

*Project Title:*
SOS tools in GRASS GIS

*Organization:*
Google Summer of Code 2017
Open Source Geospatial Foundation (OSGeo)
GRASS GIS

*Abstract:*
Intended modules would enable the user to create a vector, a raster based
on some aggregations and create a space time vector or raster dataset,
everything directly from user's access to the SOS server. t.vect.to.rast
would also allow the user to convert a space time vector dataset into a
raster dataset. The user should be also allowed to get the capabilities to
get info about sensors from these modules and filter the results.

*Pre-GSoC:*
GRASS GIS didn't have any module to work with Sensor Observation Service
(SOS). When the user wanted to use data from his SOS server, he had to
access them through OWSLib, convert them into GRASS GIS or OGR supported
format ad then import it somehow to GRASS GIS as one huge file.

*Added value:*
v.in.sos imports data from SOS server as a vector map to GRASS GIS. It
creates one layer for each offering and observed property.
r.in.sos imports data from SOS server as a raster maps to GRASS GIS. It
creates new raster map for each timestamp. User is allowed to use some
aggregations and granularity to filter data.
t.vect.in.sos imports data from SOS server to GRASS GIS as a
spatio-temporal vector dataset. It creates new stvds for each offering and
observed property (created from one vector map as an intermediate).
t.rast.in.sos imports data from SOS server to GRASS GIS as a
spatio-temporal raster dataset. It creates new strds for each property and
each procedure (registered from raster maps created as intermediates).
t.vect.to.rast doesn't import data from SOS server to GRASS GIS. It
converts a space time vector dataset into a space time raster dataset.

*Continued Work:*
There are some issues or possible enhancements in the modules.
v.in.sos uses timestamps as column names for each layer. The problem is
that it is not possible to have more than 3000 columns in SQLite table
(GRASS GIS attribute table) without SQLite recompilation. It will be little
bit solved by granularity and this module isn't so necessary when there is
t.vect.in.sos, but it is still useful for some purposes and this is really
lack.
t.vect.to.rast is working, but if you take  look at t.rast.to.vect, you can
see much more options. It would be great to involve them also into this
module.
It would be also great to have a flag for ignoring empty procedures in all
the modules.


*Link:*
The modules github repository:
https://github.com/pesekon2/GRASS-GIS-SOS-tools
(they should be moved into the official GRASS GIS add-ons repository in the
future)

*One image to show how can visualized sensors look on the OSM map:*
https://raw.githubusercontent.com/pesekon2/GRASS-GIS-SOS-tools/d566c868a50f12ba6fc4e1d6b953e9708e4b0061/image_vector_import.png


2017-08-18 22:22 GMT+02:00 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
>
> --
> Margherita Di Leo
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Ondřej Pešek]

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

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 11 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the eleventh 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?

v.in.sos
* finally working the desired way even with more layers
   main commits: [2] [3]
 * uses yet existing columns for timestamps instead of creating new ones
   main commits: [4]
t.vect.in.sos
* finally working with layers-based vectors
   main commits: [5] [6]
t.rast.in.sos
   main commits: [7]

What do you plan on doing next week?

 * Work on documentation
 * t.vect.to.rast
 * still have some ideas how to improve yet existing modules (for example
option for granularity)

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/6ac65b2ba2b42d63973652f6d4cdd155313f3b11
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/bc98deb0663e9d15f993ca0837014f197c718c0d
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/12a415ad12098ca876c431e8c2457148c477f601
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/4a435453b6281736719653e0c12a1576c9a906e1
[6]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/dc8d7e0724ff07d040755ee10ae9fc153391cd57
[7]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/c985f8e8115a6fa9ded608d4697a1dbba44110f2
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 10 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the tenth 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?

r.in.sos
* flag for deleting vector maps created as intermediates
   main commits: [2]
* importing vectors and values in one step
   main commits: [3]
v.in.sos
* importing vectors and values in one step
   main commits: [4]
All modules
* not stop when using just -g flag
   main commits: [5]
* code cleaning and manuals updates
A little pull request for istSOS
* allow user to define offering in csv2istsos
   main commits: [6]

What do you plan on doing next week?

* I hope that me, Luca and Pietro will solve somehow a problem with layers
in pygrass (if possible, I would like to rewrite t.vect.in.sos and v.in.sos
to support layers)
* t.rast.in.sos

Are you blocked on anything?

* Yes. I am blocked on an unexpected behaviour of Vector and VectorTopo
classes in pyGRASS. We are trying to solve it and we have contacted also
Pietro Zambelli, so I hope in a good ending. Due to this I am little bit in
delay, but I have a little buffer in my timeline and I have some sketches
of future code for t.rast.in.sos, so I hope that it will be quick after
solving those problems.

Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/ed75568b96dc85c7938828dbfb21ff01e478ddcc
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/9cad14e47a827f2dbf3cf2212fc56fc595695c09
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/2505c2a50f0e0aefa2e5252c112a91ace629246e
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/5f4edf66341714225bd91c7df6810c1a9412fc59
[6] https://github.com/istSOS/istsos2/pull/19
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 9 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the ninth 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?

* updated shell script style output to all modules
   main commits: [2]
* handle import errors
   main commits: [3]
* every flag works with multiple offerings
   main commits: [4]
* observed properties can be given as their ids
   main commits: [5]
* not given options are generated just temporary
   main commits: [6]
* t.vect.in.sos creating stvds
   main commits: [7] [8] [9]
* r.in.sos creating raster maps
   main commits: [10]

What do you plan on doing next week?

* Final updates of t.vect.in.sos and r.in.sos
* t.rast.in.sos

Are you blocked on anything?

* I hope not


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/553742e87f33141febf674c145c4c7ddcab89ef9
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/0124555dccfa7ec08d0a09345d59b8fce431ac57
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/98e3771b5fa47bd69e3e64b3efaaf496f46b2d76
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/1ecd149a99f182ac843baaf1c5f157c89c36efd6
[6]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/e9148fb48f7952ceeeb0d6e12a9a7dc72192c089
[7]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/9c3803282c281cae5acec3208a0faf24d3e4728c
[8]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/d0bbf98da8d8d07b58495db142555851d62a504e
[9]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/57f8b5c4d33ead47325265ad4baaf58e0f29c907
[10]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/c3960ccac6448ec867355d520821e301c65741fc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 8 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the eighth 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?

* t.vect.in.sos creates new vector for each offering and observed property
   main commits: [2], [3], [4]
* implemented shell script style output into modules
   main commits: [5]
* first shuck of r.in.sos
   main commits: [6]
* get exhausted at FOSS4G-E

What do you plan on doing next week?

* I hope that me and Luca will solve somehow a problem with temporalization
in t.vect.in.sos, because I would like to finish this module
* If possible, I would like to finish also r.in.sos (or at least approach
the end)

Are you blocked on anything?

* In t.vect.in.sos, I'm stuck on the temporalization of a vector map with
layers (based on timestamps). I have opened an issue for that [7] and me
and Luca are working on the solution.


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/b9d81443ec20d92737a50b78c4f7e0f042a5b90a
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/4b5728973d9a3417ec641e9a27d6788f6abbe7a5
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/090cc580603bbefca27176df7127a8ca353f1dfb
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/11dcefd601a061f786ddcaf4cb1a11ee0c06a10b
[6]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/e513796000da6ed2ee5d9028be492221956c8cb3
[7] https://github.com/pesekon2/GRASS-GIS-SOS-tools/issues/18
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 7 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the seventh 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?

* As I declared in my timeline and proposal, I was out of internet and
electricity during the last week. So I wasn't able to do anything connected
with GSoC.

What do you plan on doing next week?

* I will attend FOSS4G-Europe in Paris, where I want to attend especially
Fully Open Monitoring System workshop which is also related to my project
* I would like to finish t.vect.in.sos and start works on r.in.sos

Are you blocked on anything?

* No


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 6 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the sixth 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?

As I declared in my timeline and proposal, I was out of internet and
electricity during the last week. So I wasn't able to do anything connected
with GSoC.

What do you plan on doing next week?

I will still be out of internet and electricity (due to my work at summer
camp) until the fifteenth of July. So I still won't be able to do anything
connected with GSoC.

Are you blocked on anything?

* On the absence of internet and electricity


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 5 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the fifth 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?

v.in.sos
* using vectors in pyGRASS instead of v.in.sos
* support multiple offerings
* layers are for offerings and observed properties, rows are for one feature
* handle data input with no observations for
* handle too big input with warnings and errors

t.vect.in.sos
 * first version (just draft with some bugs, they are saved as issues and
will be solved after my return)

What do you plan on doing next week?

As I declared in my timeline and proposal, I would like to apologize that
from tomorrow morning to the fifteenth of July, I will be out of internet
and electricity (due to my work at summer camp). So I won't be able to do
anything connected with GSoC.

Are you blocked on anything?

* Will be blocked on the absence of internet and electricity


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 4 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the fourth 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?

v.in.sos
* flags for printing timestamps of begin and end of observation
* working with event_time (interval of observation is used in query)
* v.in.sos returns one map with many layers (layers count = observed
properties count)
xml2geojson
* working with separated blocks of values, not just with single values

What do you plan on doing next week?

* spatio-temporal element of observations
* raster representation of SOS output

Are you blocked on anything?

* Nope


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 3 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the third 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?

This week was dedicated to the module v.in.sos:
* Makefile and first html
* UI
* Prints informations about sensor offerings
* Imports the observation into GRASS GIS
* This version is returning just the last observation, next step is to
return all of them

I have also started some conversations with guys behind istSOS and OWSLib
about some extensions or problems, we will see the result.

What do you plan on doing next week?

* Continue in writing v.in.sos module (return all observations and return
observations depending on time of observation start)

* I think it will need also some improvements of xml2geojson converter

Are you blocked on anything?

* Nope


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
___
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 2 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi Maris, Luca,

On 12 June 2017 at 08:11, Maris Nartiss  wrote:
> >
> > I have no idea how much of XML parsing is needed, but implementing an
> > own XML parser never sounds a good idea unless it is a quick hack.
> > Working with XML in a correct way is PITA, unless your parser is
> > really good.
> > Just my 0.02, as I haven't seen teh codez.
> >
>
>
As it's specific xml for SOS and not OSM xml, the converter is needed to
convert the SOS output into something readable for GRASS GIS (to import
data as a layer). And as Luca says, the conversion between this xml () and
GeoJSON was just about 50 lines of code.


2017-06-12 9:51 GMT+02:00 Luca Delucchi :

> they are not much lines of code, however I think this code should be
> added to OWSLib, Ondrej do you think is it possible?
>
>
Good idea. I will ask Tom Kradilis and guys from OWSLib about that.

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

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 2 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the first 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?

* I had a problem with xml parser in OWSLib for SOS observations, because
it works completely different way than we expected. After few conversations
I have decided to work with raw output and write parser by myself.

* Created pull request solving [2] for OWSLib.

* Created converter between text/xml;subtype="om/1.0.0" output from OWSLib
and geoJSON for points

* Imported converted output from istSOS into GRASS GIS

* Created a shuck of v.in.sos module
What do you plan on doing next week?

* Continue in improving converters (I would like to support other than
point-geometries, but I don't have any other data on server yet)

* Continue in writing v.in.sos module

* Find some raster-data SOS server

Are you blocked on anything?

* I hope not anymore


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2] https://github.com/geopython/OWSLib/issues/248
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 1 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the first 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?

* I have studied OWSLib and its interaction with SOS. Especially with
istSOS. I am also in contact with guys about OWSLib and we're discussing
things related to SOS to improve.

* Solved issue [2].

* Created converter between normal JSON output from OWSLib and geoJSON
What do you plan on doing next week?

* Solve this issue [3]

* Test OWSLib on more severs.

* I would like to create converter working with
responseFormat=text/xml;subtype="om/1.0.0" responseFormat.

Are you blocked on anything?

* I was blocked in creating converter from above mentioned format, because
the OWSLib didn't give me right response. I'm discussing it with people
around OWSLib to solve whether is it bug or something.


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2] https://github.com/geopython/OWSLib/issues/347
[3] https://github.com/geopython/OWSLib/issues/248
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2017 - SOS tools

[Ondřej Pešek]

Hello everyone,

I'm glad to hear that my project (SOS tools in GRASS GIS) was accepted! I'm
looking forward to work on this project.

I have created wikipage for this project on Trac [1], repository will be
setted in the following days.

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS

2017-03-31 0:33 GMT+02:00 Ondřej Pešek <pesej.ond...@gmail.com>:

> Hi Massimo,
>
> 2017-03-30 14:50 GMT+02:00 massimo di stefano <massimodisa...@gmail.com>:
> > Hi Ondrej,
> > what about working on your gsoc 2016 idea?
> >
> > I guess we all want the GSOC be an “instrument” to involve students in
> the
> > project they chose and “hopefully” have them continuing what they
> started …
> > IMHO this “continuation” is very important and is a clear sign of how
> much
> > the student cares about to the project itself.
> >
> > I’ve had bad experience with gsoc, I know the students are not obligated
> in
> > continuing to contribute to the project after the GSOC period .. but I
> think
> > that’s what we hope.
> > It is a very bad feeling when a mentor spent the whole summer following a
> > student which then literally disappear after the application period
> >
>
> Of course, I would like to continue in my 2016 GSoC project, but there
> is a problem with my internship at the Norwegian Institute for Nature
> Research (NINA), as mentioned in my proposal. I'm afraid that I won't
> be able to handle working on two completely different projects.
>
> But in NINA, I will be working on sensor data, especially with istSOS.
> I (and potential co-mentors) can see quite significant overlap, so I
> expect synergies and mutual benefits.
>
> But my last year project is not dead, it's just... hmmm...
> hibernating. I have done some small changes in November and I still
> have some notes with what I would like to improve. The nearest
> improvement is creating module from those scripts - I'm just playing
> with pyGrass, so I hope that I have some time before the start of this
> year project (or before my NINA internship, if not accepted).
> Another nice goal should be using this code to GRASS plugin for QGIS,
> because QGIS has PyQt based GUI, but it's the future.
>
> > for your idea i can see the following improvements:
> > - porting to qt5
> > - porting to py3 (only task.py need some twiking)
> > - complete the modules, I tried it and I found it incomplete.
> >
>
> Yes, I'm planning also py3. But I didn't contemplated about qt5, I
> have to study it first.
> Please, feel free to create an issue on the github page [1]. I welcome
> your comments and opinions.
>
> >
> > Massimo.
> >
> >
>
> [1] https://github.com/pesekon2/GRASS-Qt-based-GUI/issues
>
> Ondrej  style="border-top: 1px solid #D3D4DE;">
> 
>href="https://www.avast.com/sig-email?utm_medium=email;
> utm_source=link_campaign=sig-email_content=webmail"
> target="_blank"> src="https://ipmcdn.avast.com/images/icons/icon-envelope-
> tick-round-orange-animated-no-repeat-v1.gif"
> width="46" height="29" style="width: 46px; height: 29px;" />
> Bez virů.  href="https://www.avast.com/sig-email?utm_medium=email;
> utm_source=link_campaign=sig-email_content=webmail"
> target="_blank" style="color: #4453ea;">www.avast.com
>  
> 
> 
>  height="1">
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2017 - SOS tools

[Ondřej Pešek]

Hi Massimo,

2017-03-30 14:50 GMT+02:00 massimo di stefano :
> Hi Ondrej,
> what about working on your gsoc 2016 idea?
>
> I guess we all want the GSOC be an “instrument” to involve students in the
> project they chose and “hopefully” have them continuing what they started …
> IMHO this “continuation” is very important and is a clear sign of how much
> the student cares about to the project itself.
>
> I’ve had bad experience with gsoc, I know the students are not obligated in
> continuing to contribute to the project after the GSOC period .. but I think
> that’s what we hope.
> It is a very bad feeling when a mentor spent the whole summer following a
> student which then literally disappear after the application period
>

Of course, I would like to continue in my 2016 GSoC project, but there
is a problem with my internship at the Norwegian Institute for Nature
Research (NINA), as mentioned in my proposal. I'm afraid that I won't
be able to handle working on two completely different projects.

But in NINA, I will be working on sensor data, especially with istSOS.
I (and potential co-mentors) can see quite significant overlap, so I
expect synergies and mutual benefits.

But my last year project is not dead, it's just... hmmm...
hibernating. I have done some small changes in November and I still
have some notes with what I would like to improve. The nearest
improvement is creating module from those scripts - I'm just playing
with pyGrass, so I hope that I have some time before the start of this
year project (or before my NINA internship, if not accepted).
Another nice goal should be using this code to GRASS plugin for QGIS,
because QGIS has PyQt based GUI, but it's the future.

> for your idea i can see the following improvements:
> - porting to qt5
> - porting to py3 (only task.py need some twiking)
> - complete the modules, I tried it and I found it incomplete.
>

Yes, I'm planning also py3. But I didn't contemplated about qt5, I
have to study it first.
Please, feel free to create an issue on the github page [1]. I welcome
your comments and opinions.

>
> Massimo.
>
>

[1] https://github.com/pesekon2/GRASS-Qt-based-GUI/issues

Ondrej 

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
width="46" height="29" style="width: 46px; height: 29px;" />
Bez virů. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com   



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

[GRASS-dev] GSoC 2017 - SOS tools

[Ondřej Pešek]

Hello everyone,

I am Ondrej Pesek, a student at CTU in Prague (studying master studies in
geomatics) and I would like to participate in GSoC 2017.

I am most interested in the SOS topic [1]. I will work during summer in
NINA where I should work with istSOS, So I'm thinking about istSOS also in
this topic.

I prefer something in python as I made my bachelor thesis in python (aerial
data shift on a trajectory - plugin for QGIS) and I participated in last
GSoC (PyQt based GUI for GRASS), but I have also basic knowledge of C++ and
now I'm trying to get little bit familiar with Java.
I have no experiences with SOS but I'm open to learn new skills.

Looking forward to your reply.

Have a nice day,
Ondrej


[1] https://trac.osgeo.org/grass/wiki/GSoC/2017#SOStools
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 12

[Ondřej Pešek]

Hi all,

here is my last week report.

Wiki page: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

A link to my commits: https://github.com/pesekon2/GRASS-Qt-based-GUI/commits

The goal of the project was to create new GUI for modules based on PyQt.
The old one is based on wxPython. The reason is that there are some bugs in
wxPython and PyQt is now much more powerfull. The second reason is that the
code of old GUI is written bad way. It's almost impossible to read what
something do and work with that. So the second goal was try to write
higher-quality code.

My project is now usable.
It's interface is mostly based on the old one to avoid the need for
studying new approach (the code isn't), but some widgets were changed due
to my and my mentor's opinion. For example we use spinbox for int widgets
or there is completely new widget for choosing quiet/normal/verbose module
output.

What have been done is visible in github repository. Screenshots of widgets
and other stuff is at wikipage.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 10

[Ondřej Pešek]

Hi all!

Here is the tenth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff see its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* New widgets: Mapsets, locations and dbtable (created dependencies between
those), special widget for quiet/normal/verbose module output

* Created definitive (I hope) size policy. ialog width and height still
depends on content volume, but now just till some limit. After that, the
tab gets sliders to scroll.

* Fixes and updates: Widgets Columns and Layers now work with map in widget
'map' when 'input' does not exist; fix widget Colors for default value in
'r:g:b' style

* Main window and dialogs now have grass logo and icon

* Required widget is highlighted by red star

* Tab 'required' isn't visible when it's empty

* Was created documentation for .py files and for individual class,
methods...

* key_desc used instead of type (when showing widget name)

* Big refactoring using default pep8


What do you plan on doing next week?

* I'm sorry but I will be now for two weeks (as I said at the beginning)
off. Off the internet, off the computer. I hope that I can can turn for one
day to civilization and work. I have unfinished one widget (icons choosing
in d.vect) and I hope that I will be able to work little bit next week and
finish it...


Have a nice week,
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 9

[Ondřej Pešek]

Hi all!

Here is the ninth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff see its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* New widget: dbtable

* I had finally ordered tabs. Required tab is the first one and Optional
tab the last one. And if widget has defined guisection, it is now prior to
Required.

* I had fixed problems with spinboxes. They now allow you to input number
greater than 100 and also negative numbers.

* Was created first version of sizepolicy. Dialog width and height still
depends on content volume, but now just till some limit. After that, the
tab gets sliders to scroll.
What do you plan on doing next week?

* Finish things with sizepolicy, clear little bit the code, there are still
some widgets which I plan to design better way

Are you blocked on anything?

* I was really blocked on the sizepolicy for a while. I'm talking 'bout it
with my mentor and it seems that it will be okay in a while.

Have a nice weekend,
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 8

[Ondřej Pešek]

Hi all!

Here is the eigth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff see its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* New widgets: layer, columns, multiple values with values_desc, separator,
group, colors

* helpButton and closeButton work

* Help/tooltip also for flags

* Fix: Float or int equals 0 -> delete from cmd, more flags than one will
not call overwrite, set minimum size to browsebutton

* Refactoring (using methods as callbacks)
What do you plan on doing next week?

* DB widgets with dependencies

Are you blocked on anything?

* Nope


Thank you and have a real cool time!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 7

[Ondřej Pešek]

Hi all!

Here is the seventh report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff see its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* New widgets: cats, multiple values, raster_3d

* Little changes in other widgets: Mapset is not selectable in treewidget,
flags and default widget were moved into its own classes

* If widgets have both label and description, description is used as
help/tooltip

* Massive refactoring of code for command (running, changing dictionary,
changing cmd string that user see)

What do you plan on doing next week?

* I want to start coding the widges with dependencies (column, layer); I
will also check my code with pep8

Are you blocked on anything?

* I was blocked for some while on the refactoring, but it's OK now


Have a sunny weekend!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 6

[Ondřej Pešek]

Hi all!

Here is the sixth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff se its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* The Run button works now also with flags. Also the user can see flags in
string below.(it works with both long and short flags)

* For prompt=file I implemented lineedit with Browse button to choose file.
What do you plan on doing next week?

* The main thing will be refactoring some code - especially for
CodeChanger. I'm now discussing about it with my mentor.

* I think that I can implement some more types of widgets. I also want to
start study (and code) the dependencies between widgets.

Are you blocked on anything?

* Nope


Thank you and have a real cool time!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 5

[Ondřej Pešek]

Hi all!

Here is thefifth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff se its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?
* As I said, due to my exams, I didn't do anything. Sorry. But by next
week, I'm again ready to work.

What do you plan on doing next week?
* I want to implement also flags into the string user see and into Run
button. Also I want to start working on choosing files with browse button.
I hope that it everything will be smooth and I will also finish this browse
widget.

Are you blocked on anything?
* Not now


Thank you and have a real cool time!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 4

[Ondřej Pešek]

Hi all!

Here is the third report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff se its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?
* The Run button really runs (but still not with flags). It's still the
only button with any function. Also the code-string on the bottom of GUI
was recreated. Now it's just one (only readable) textedit. When the string
is too long, you will get the scrollbar.

* Completely retyped code in parameters.py. Now it works like Factory.
Factory is dynamically creating the list of methods classes with canHandle
method and the called class depends on the values in this method. It means
that there are not so many "ifs" and the code is better readable. And those
classes return "self" instead of method get().

* Float coords is lineedit.

* When the string has values, it's editable combobox with implemented
values.

* Nearly last thing: I implemented the TreeComboBox for inouts/outputs.
Both raster and vector. It works very similarly to the one in old GUI.
Mapset is parent and then you have many children to choose. It's in
gselect.py and in parameters.py is just the class inheriting it from
gselect with added canHandle method. It's much readable for anyone than
just directing program elsewhere. Now you can also choose the mapset; this
possibility will be banned in next coding.

* For not implemented thing I use lineedit (because You can write there
anything manually). Now I highlight it with red colour and word TODO in
GUI. It's just for me and will not be in the real version.

What do you plan on doing next week?
* I'm sorry but at June the 27th, I have my final exams for bachelor at
school so I won't be able to do anything related to GSoC in next week (I
really have to learn something before exams). I have done everything in my
timeline for next week so I hope it's okay. I will of course answer to
mails and such thing, I mean I will not be able to code anything. Thanks.

Thank you and have a sunny weekend!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 3

[Ondřej Pešek]

Hi all!

Here is the third report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML

What did you get done this week?
* I have upgraded GUI - now it works also with the string and integer
types. (on the basic level)
* I also have made some changes - SqlQuery is now lineedit and when the
float isn't multiple, the GUI generates QDoubleSpinBox.
* The important thing is the first version of copyable/runable code. The
buttons don't work yet, but user can see it and it automatically reads the
code.
*And one elegant thing - all the widgets are now stretched upper.

What do you plan on doing next week?
* Main goal: Implement some other types/make more variable the current types
* Additional goals: Make the Run button working; recreate little bit the
code (not so many ifs)

Are you blocked on anything?
* Not yet

Have a nice weekend!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Ondřej Pešek]

Hi,

it sounds good, thank you for opening new possibilities. To be honest, I
didn't know about the g.parser rules.

Now I'm just looking on that. It looks nice. In some latest version, I will
try to implement it. Especially the mutually exclusive ones, it should be
nice.

Thanks

2016-06-08 9:30 GMT+02:00 Blumentrath, Stefan :

> > Side question: do the parser rules include flags ? I thought they were
> only available for options.
>
> Actually, I have no idea. I just checked the add-ons I wrote, and saw that
> I only used them for options. I was not aware of this limitation...
> Thanks for pointing that out...
>
> Cheers
> Stefan
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Ondřej Pešek]

Hi,


2016-06-04 20:47 GMT+02:00 Vaclav Petras :

>
> the screenshots looks good. For the code, it might little bit too soon to
> judge it, but just keep in mind the need for design we talked about
> earlier. For some simple help, you can use pylint tool which will demand
> some code style. Start with the file tools/pylintrc.txt in the GRASS source
> code.
>
>
yes, I want to write there also some comments etc. And I'll try the pylint.



> When I ran it for v.buffer I see you are using text edit / line edit for
> float even when it is not [multiple]. I think Qt has double spin box which
> you can use. In general, you don't have to fully follow the current look or
> behavior. If you think that something can be done in a better way, do it.
>
> For example, this would be one thing we can reconsider. The shorter
> description (label or description field) shows as the name/label for a
> field while the longer description (description field) shows as a tooltip
> of the label. One improvement could be showing it as a tooltip for the
> input field as well (or perhaps in a completely different way).
>
>

I will consider it all. While coding I was experimenting, but everytime I
considered that the original widget = the best widget. Thanks for tips, I
will try it your way. And the tooltip version sounds good. Should I put the
name and type (input=string) upper (where now is description) or on the
right side (as in current version).


Thanks for tips and have a nice time,
Ondrej



Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Ondřej Pešek]

Hi all!

Here is the second report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML

What did you get done this week?
* Now the code is reading those types - float, range, sql_query, flags
* It also writes their names or labels and types into GUI

What do you plan on doing next week?
* Other types - especially I have on my mind string and name
* I also want to make the GUI little bit more elegant. It means I want to
insert spacer on the end of every tab -> it means that widgets will be at
the top, not averagely placed.


Are you blocked on anything?
* Not yet


Here is the wiki with screenshots etc.:
https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Thanks, I'm going on that.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Bez
virů. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-05-30 9:14 GMT+02:00 Luca Delucchi <lucadel...@gmail.com>:

> On 27 May 2016 at 23:27, Ondřej Pešek <pesej.ond...@gmail.com> wrote:
> >
> > Hi,
> >
>
> Hi Ondrej,
>
> > here is report of what I have done during this week in my GRASS
> >
> > GSoC Project:
> >
> > WEEK 1
> >
> > Designed basic GUI shuck. From XML is now automatically generated GUI
> with name, keywords and basic layouts (description, tabs, buttons).
> >
> > Code now works as a script with parameter - for example r.buffer (python
> forms.py r.buffer).
> >
> > Take a look at screenshots.
> >
>
> These look really a good starting point, please could you extend the
> README file adding how to test the code, for example dependencies and
> how to compile/use
>
> >
> > Best regards,
> > Ondrej
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Hi,

thanks for your response.

2016-05-25 17:26 GMT+02:00 Pietro :

>
> Perhaps, it could be useful to have a look at pygrass `Module` class [0],
> that already parse the generated xml and instantiate `Parameter` class [1]
> that validate the input from the user in the `_check_value` function [2].
> So should be possible to dynamically generate a `Qt Widget` from a
> `Parameter` instance and then compose everything in complete final
> `QtWidget`/`QtDialog`. If you think that  in the `Module` / `Parameter`
> class definition something is missing/wrong or bad implemented, after
> discussion, we can change it. They were not developed with this use case in
> mind and perhaps some changes are needed however I do think they are a
> starting point...
>
>
Thank you, 'Module' is really nice. I was working with 'task', but 'Module'
looks much better.



> I think that we should support both: PyQt and PySide, and I think you
> should use as primary choice for development Python3, support for Python2
> it is much easier to add later if needed.
>
>
Well, I have never worked with Python3. But of course I can try it. It
might be useful to learn it and if you think it's better. I have created
basics in Python2 but it was one week - so it's not thousands of lines. I
can still retype it. Thanks for idea.


I'm studying the rest (thanks, it really helps me),
Ondrej



Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Hi everyone,

the period of GSoC starts. I just want to present myself. My name is Ondrej
Pesek and I'm from Czech Republic. I study geodesy, cartography and
geomatics at Czech technical university in Prague. My project for GSoC 2016
is reimplementation of GUI generated from xml, wxpython -> PyQt. You can
see everything at [1].

I'm open to all your requests, comments and hates. Don't hesitate to write
me, I would appreciate it.

Have a nice day,
Ondrej


[1]  https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI


Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev