[GRASS-dev] grass 7.2 planning

[Martin Landa]

Hi all,

personally I would like to see GRASS 7.2.0 released somewhere in July.
Do you think that it's realistic? If so I would suggest roadmap
bellow:

1) to create releasebranch 7_2 ASAP (in the beginning of May)
1) soft freeze in releasebranch_7_2 ~ 16 May
2) GRASS 7.2.0RC1 ~ 16 June
3) GRASS 7.2.0RC2 ~ 30 June
4) GRASS 7.2.0 ~ 7 July

What do you think? Martin

[Rainer M Krug]

Just to be sure - that would be the version at the moment named 7.1 ?

Rainer

Post by Martin Landa
Hi all,
personally I would like to see GRASS 7.2.0 released somewhere in July.
Do you think that it's realistic? If so I would suggest roadmap
1) to create releasebranch 7_2 ASAP (in the beginning of May)
1) soft freeze in releasebranch_7_2 ~ 16 May
2) GRASS 7.2.0RC1 ~ 16 June
3) GRASS 7.2.0RC2 ~ 30 June
4) GRASS 7.2.0 ~ 7 July
What do you think? Martin

[Martin Landa]

Post by Rainer M Krug
Just to be sure - that would be the version at the moment named 7.1 ?

yes, Martin

[Rainer M Krug]

Post by Martin Landa

Post by Rainer M Krug
Just to be sure - that would be the version at the moment named 7.1 ?

yes, Martin

Thanks.

I will than make a homebrew grass 7.2 formula as soon as the branch has
been created.

Cheers,

Rainer

[Moritz Lennert]

Post by Martin Landa
Hi all,
personally I would like to see GRASS 7.2.0 released somewhere in July.
Do you think that it's realistic? If so I would suggest roadmap
1) to create releasebranch 7_2 ASAP (in the beginning of May)

Should we maybe wait until we have released 7.0.4 ? Just to avoid too
much work and confusion ?

Post by Martin Landa
1) soft freeze in releasebranch_7_2 ~ 16 May
2) GRASS 7.2.0RC1 ~ 16 June
3) GRASS 7.2.0RC2 ~ 30 June
4) GRASS 7.2.0 ~ 7 July
What do you think? Martin

Except for the overlap with 7.0.4, I think it's a good plan.

Moritz

[Martin Landa]

Should we maybe wait until we have released 7.0.4 ? Just to avoid too much
work and confusion ?

I am not sure how are these two issues related. Anyway GRASS 7.0.4
should be released within the text week too. Martin

[Moritz Lennert]

Post by Martin Landa

Should we maybe wait until we have released 7.0.4 ? Just to avoid too much
work and confusion ?

I am not sure how are these two issues related. Anyway GRASS 7.0.4
should be released within the text week too. Martin

Just that it's generally the same people who create branches, write the
announcement, etc and so I want to avoid overload ;-)

Moritz

[Markus Neteler]

Post by Martin Landa

Should we maybe wait until we have released 7.0.4 ? Just to avoid too much
work and confusion ?

I am not sure how are these two issues related. Anyway GRASS 7.0.4
should be released within the text week too. Martin

Fully agreed with Martin - let's do that in parallel.

The 7.0.4 release is not much work (ok, several hours :p) especially
when this input comes from others:
- write a nice announcement blurb
- provide a catchy screenshot

I would be so happy to receive that!

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
Fully agreed with Martin - let's do that in parallel.

by creating a new branch I meant just creating a branch (one svn
command) and sending announcement to grass-dev ML. I can take
responsibility for that. Martin

[Moritz Lennert]

Post by Martin Landa
Hi,

Post by Markus Neteler
Fully agreed with Martin - let's do that in parallel.

by creating a new branch I meant just creating a branch (one svn
command) and sending announcement to grass-dev ML. I can take
responsibility for that.

Ok, +1 from me, then.

Moritz

[Vaclav Petras]

Post by Martin Landa
1) to create releasebranch 7_2 ASAP (in the beginning of May)
1) soft freeze in releasebranch_7_2 ~ 16 May

I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at
FOSS4G NA [1]

From things I remember, there is the prototype of Simple Python Editor
which needs a review but you (Martin) already did some, so I guess that's
fine.

[1]
https://grasswiki.osgeo.org/wiki/FOSS4G_NA_2016:_GRASS_related_workshops_and_presentations

[Martin Landa]

Hi,

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at FOSS4G
NA [1]

we can wait one week or so if you wish.

Post by Vaclav Petras
From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that's fine.

Yes, I used the editor in lessons. Nice tool! I had only one problem,
sometimes run button was not working (I discovered why after lesson
[1] :-)

Ma

[1] https://trac.osgeo.org/grass/ticket/2997

[Vaclav Petras]

Post by Martin Landa

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at FOSS4G
NA [1]

we can wait one week or so if you wish.

Thanks. This would give at least some chance to get things straight.

Post by Martin Landa

Post by Vaclav Petras
From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that's fine.

Yes, I used the editor in lessons. Nice tool!

Thanks. It took me some time to discover that this is exactly what users
want.

Post by Martin Landa
I had only one problem,
sometimes run button was not working (I discovered why after lesson)

I focused on getting the basics working but the executing is just tricky.
Will try to look at it as well to see if some substantial changes are
needed.

[Martin Landa]

Hi,

Post by Martin Landa

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at FOSS4G
NA [1]

we can wait one week or so if you wish.

I just wanted to ask what is the current status? Thanks, Martin

[Vaclav Petras]

Post by Vaclav Petras

Post by Martin Landa

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from

modules to

Post by Martin Landa

Post by Vaclav Petras
the library but that might not be feasible in the given time frame

(from my

Post by Martin Landa

Post by Vaclav Petras
side). The first week of May I can't promise any commits since I'm at

FOSS4G

Post by Martin Landa

Post by Vaclav Petras
NA [1]

we can wait one week or so if you wish.

I just wanted to ask what is the current status? Thanks, Martin

I'm slowly starting to work on it now. I'll create a ticket, so it is clear
what's the plan. I'll set it as a blocker, so it shows up together with the
other blockers.

[Vaclav Petras]

I'll create a ticket, so it is clear what's the plan.

Created ticket #3034 for the layers in v.in.lidar, removed the vector
output from r.in.lidar in r68418.

https://trac.osgeo.org/grass/ticket/3034
https://trac.osgeo.org/grass/changeset/68418

I'll set it as a blocker, so it shows up together with the other blockers.

Here are the current blockers:

https://trac.osgeo.org/grass/query?priority=blocker&status=assigned&status=new&status=reopened&milestone=7.2.0&group=type&col=id&col=summary&col=priority&col=status&col=owner&col=component&col=version&order=priority

[Martin Landa]

Hi,

Created ticket #3034 for the layers in v.in.lidar, removed the vector output
from r.in.lidar in r68418.
https://trac.osgeo.org/grass/ticket/3034
https://trac.osgeo.org/grass/changeset/68418

it's not clear to me what is the status? Can we create a new release
branch? We have already delay... Thanks for clarification, Martin

[Vaclav Petras]

Post by Martin Landa
Hi,

Created ticket #3034 for the layers in v.in.lidar, removed the vector output
from r.in.lidar in r68418.
https://trac.osgeo.org/grass/ticket/3034
https://trac.osgeo.org/grass/changeset/68418

it's not clear to me what is the status? Can we create a new release
branch? We have already delay... Thanks for clarification, Martin

I have committed code to solve all the related lidar issues except for this
one:

https://trac.osgeo.org/grass/ticket/3038

We can do the branching from the point of view of lidar modules.

However, concerning the actual release, there is one more rendering-related
blocker:

https://trac.osgeo.org/grass/ticket/2899

[Martin Landa]

Hi,

Post by Vaclav Petras

Post by Martin Landa
it's not clear to me what is the status? Can we create a new release
branch? We have already delay... Thanks for clarification, Martin

I have committed code to solve all the related lidar issues except for this
https://trac.osgeo.org/grass/ticket/3038
We can do the branching from the point of view of lidar modules.

OK, thanks. Martin

[Moritz Lennert]

Martin,

Post by Vaclav Petras
However, concerning the actual release, there is one more
https://trac.osgeo.org/grass/ticket/2899

The problem in this ticket seems to come from your changes in r65205
[1]. Could you have a look at that ?

Moritz


[1] https://trac.osgeo.org/grass/changeset/65205

[Martin Landa]

Hi,

The problem in this ticket seems to come from your changes in r65205 [1].
Could you have a look at that ?

yes, I know, later I will take a look. Anyway it's not blocker for
branching. Martin

[Markus Neteler]

Hi devs,

at this point we are ready for creating the releasebranch_7_2 .

If there aren't any urgent objections, I'll do that later today.

Markus

[Markus Neteler]

Post by Markus Neteler
Hi devs,
at this point we are ready for creating the releasebranch_7_2 .
If there aren't any urgent objections, I'll do that later today.

Done: Changeset r68500

grass/branches/releasebranch_7_2

Cheers,
Markus

PS: if you have a SVN copy locally, no need to download again if it is
7.1.svn based.
Simply switch to the new branch, see

https://trac.osgeo.org/grass/wiki/HowToSVN#Switchtherepository

[Markus Neteler]

Post by Markus Neteler

Post by Markus Neteler
Hi devs,
at this point we are ready for creating the releasebranch_7_2 .
If there aren't any urgent objections, I'll do that later today.

Done: Changeset r68500
grass/branches/releasebranch_7_2
Cheers,
Markus
PS: if you have a SVN copy locally, no need to download again if it is
7.1.svn based.
Simply switch to the new branch, see
https://trac.osgeo.org/grass/wiki/HowToSVN#Switchtherepository

Pro tip:

If you are like me crazy about file timestamps (if you didn't realize, I am
maintaining the file timestamps of last change in the release tarballs for
10+ years while SVN does not support that) , try the following hack:

# locally clone from former trunk
cp -rp grass71 grass72_release
cd grass72_release
svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_2
# ... now all timestamps are ruined!
# gonna fix them now!

# move 7.2's .svn/ elsewhere:
mv .svn /tmp/
cd ..
rm -rf grass72_release
cp -rp grass71 grass72_release
cd grass72_release
# reinstate the real .svn/
rm -rf .svn
mv /tmp/.svn .

# revert back the files which are now ahead of relbranch72
svn status
svn status | grep '^M' | cut -d' ' -f2- | xargs svn revert
# trash garbage
svn status | grep '^?' | cut -d' ' -f2- | xargs rm -rf

# now it is clean but better double check
svn status
svn diff
svn up

# done

Cheers
Markus

[Markus Neteler]

On Wed, May 25, 2016 at 9:34 AM, Markus Neteler <***@osgeo.org> wrote:
[...]

Post by Markus Neteler
If you are like me crazy about file timestamps (if you didn't realize, I am
maintaining the file timestamps of last change in the release tarballs for
# locally clone from former trunk

[...]

In addition, to really find leftover files in the newly created
directory tree, run

# check for leftover stuff
svn status --no-ignore

... find stuff you may want to clean.

Markus

[Markus Neteler]

Post by Markus Neteler
grass/branches/releasebranch_7_2

Related updates:
- I have generated new grass72/ and grass73/ directories on the
server, with all the file timestamps maintained in the tarballs :)
- I also created a DRAFT: https://trac.osgeo.org/grass/wiki/Release/7.2.0-News
- updated most pages in the CMS for the new versions
- added: https://grass.osgeo.org/news/57/15/New-GRASS-GIS-7-2-x-stable-release-branch-created/

trac related:
- Question: I don't remember how I made the "G7:" macro in trac for
release notes: we need to add now "G72:" there
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)

Thanks.

Markus

[Markus Neteler]

Hi devs,

Post by Markus Neteler

Post by Markus Neteler
grass/branches/releasebranch_7_2

- I have generated new grass72/ and grass73/ directories on the
server, with all the file timestamps maintained in the tarballs :)

... all systems working...

Post by Markus Neteler
- I also created a DRAFT: https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

... that trac page needs some love. Please edit!
This means: add fixes and your favourite improvements to it

Our roadmap suggests that it is due in 7 days. Time to come up with
RC1 at least:
https://trac.osgeo.org/grass/roadmap

Please check
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.2.0

Thanks.
Markus

[Martin Landa]

Hi,

Post by Markus Neteler
Our roadmap suggests that it is due in 7 days. Time to come up with
https://trac.osgeo.org/grass/roadmap

I am afraid that we have delay, I hope that we will have some time to
work on GRASS during ISPRS in Prague. What about:

* soft freeze: ~ 15 July
* hard freeze + RC1: ~ 15 August
* bug squashing: FOSS4G Bonn
* RC2: ~ 30 August
* final: ~ 7 September

? Martin

[Martin Landa]

Hi,

Post by Martin Landa
I am afraid that we have delay, I hope that we will have some time to

I took liberty to edit milestones of 7.2.0 (1/9) and 7.0.5 (21/8) [1].
What about 6.4.6? Martin

[1] https://trac.osgeo.org/grass/roadmap

[Markus Neteler]

Post by Martin Landa
Hi,

Post by Martin Landa
I am afraid that we have delay, I hope that we will have some time to

I took liberty to edit milestones of 7.2.0 (1/9) and 7.0.5 (21/8) [1].

ok thanks.

Post by Martin Landa
What about 6.4.6? Martin

Yes, let's do an "easy" release without too much hassle.
I'll write a separate email for that.

Markus

Post by Martin Landa
[1] https://trac.osgeo.org/grass/roadmap
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

[Martin Landa]

Dear devs,

Post by Martin Landa
I am afraid that we have delay, I hope that we will have some time to
* soft freeze: ~ 15 July
* hard freeze + RC1: ~ 15 August
* bug squashing: FOSS4G Bonn
* RC2: ~ 30 August
* final: ~ 7 September

I would like to propose slowly to move from SOFT to HARD freeze of
rel72 branch [1]. There is no ticket marked as blocker [2], please
update priority to blocker if you feel that there are tickets which
must be solved before RC1.

Thanks, Martin

[1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
[2] https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.2.0&group=type&order=priority

[Vincent Bain]

Martin, Markus,
evoking projection systems' related tickets, I am wondering if this one
should be considered blocker, given epsg:3857 is quite broadly used:
https://trac.osgeo.org/grass/ticket/2229

Have a nice sunday !
Vincent.

Post by Martin Landa
Dear devs,

Post by Martin Landa
I am afraid that we have delay, I hope that we will have some time to
* soft freeze: ~ 15 July
* hard freeze + RC1: ~ 15 August
* bug squashing: FOSS4G Bonn
* RC2: ~ 30 August
* final: ~ 7 September

I would like to propose slowly to move from SOFT to HARD freeze of
rel72 branch [1]. There is no ticket marked as blocker [2], please
update priority to blocker if you feel that there are tickets which
must be solved before RC1.
Thanks, Martin
[1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
[2] https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.2.0&group=type&order=priority

[Martin Landa]

Hi,

Post by Martin Landa
* soft freeze: ~ 15 July
* hard freeze + RC1: ~ 15 August
* bug squashing: FOSS4G Bonn
* RC2: ~ 30 August
* final: ~ 7 September

since 7.0.5 is still not out (should happen soon) I would suggest to
postpone also milestone for G72 - hardfreezing + RC1 ~ 25/9. Feel free
to update blockers [1] (currently no tickets marked as blockers and
critical). Thanks, Ma

[1] https://trac.osgeo.org/grass/query?priority=blocker&priority=critical&status=assigned&status=new&status=reopened&milestone=7.2.0&group=type&order=priority

[Markus Neteler]

...

Post by Martin Landa
I would suggest to
postpone also milestone for G72 - hardfreezing + RC1 ~ 25/9.

Yes, 7.2.0RC1 around 25th of Sept might be good.

Post by Martin Landa
Feel free
to update blockers [1] (currently no tickets marked as blockers and
critical). Thanks, Ma
[1] https://trac.osgeo.org/grass/query?priority=blocker&priority=critical&status=assigned&status=new&status=reopened&milestone=7.2.0&group=type&order=priority

Let's assign a few :) Open issue are here:

https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=7.2.0&group=type&order=priority

And please all update
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Markus

[Markus Neteler]

Hi,

the new db.login blocker for solved, thanks.
The question is if we need a new RC or go ahead?

Any objections to go ahead and release without new RC?

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
the new db.login blocker for solved, thanks.
The question is if we need a new RC or go ahead?
Any objections to go ahead and release without new RC?

I guess you are referring to 7.0.5 (this thread is about 7.2).
Regarding 7.0.5 I would go ahead without any new RC2. Martin

[Markus Neteler]

Sorry for the mixup.

So, we should also go on with 7.2 and target a soonish release.

Yet open issue are here, some will be postponed to 7.2.1...:

https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=7.2.0&group=type&order=priority

And please all update
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
Yes, 7.2.0RC1 around 25th of Sept might be good.

+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

[Anna Petrášová]

Post by Martin Landa
Hi,

Post by Markus Neteler
Yes, 7.2.0RC1 around 25th of Sept might be good.

+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

no objections, but let's get 7.0.5 out first

Anna

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

[Martin Landa]

Hi,

Post by Anna Petrášová
no objections, but let's get 7.0.5 out first

right, 7.0.5 has been release yesterday (2/10) [1]. Ma

[1] https://trac.osgeo.org/grass/wiki/Release/7.0.5-News

[Markus Neteler]

Post by Martin Landa
Hi,

Post by Markus Neteler
Yes, 7.2.0RC1 around 25th of Sept might be good.

+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

Are there objections to get RC1 out? Here nothing is listed:
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.2.0tobebackported

All open issue:
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&milestone=7.2.0&group=type&order=priority

To be completed:
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Markus

[Martin Landa]

Hi,

Post by Markus Neteler

Post by Martin Landa
+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

no objections, +1 for 7.2.0RC1...

Post by Markus Neteler
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Also call for nice screenshots of the functionality (I have already
added wxGUI data catalog). Martin

[Moritz Lennert]

Post by Martin Landa
Hi,

Post by Martin Landa
+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

no objections, +1 for 7.2.0RC1...

+1

Moritz

[Markus Neteler]

On Mon, Oct 24, 2016 at 8:51 AM, Moritz Lennert

Post by Martin Landa
Hi,

Post by Martin Landa
+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

no objections, +1 for 7.2.0RC1...

+1

As time permits, I'll try to package RC1 tomorrow (err, today), so on 27th Oct.

Markus

[Martin Landa]

Hi Markus,

Post by Markus Neteler
As time permits, I'll try to package RC1 tomorrow (err, today), so on 27th Oct.

Thanks! Ma

[Markus Metz]

Post by Markus Neteler
On Mon, Oct 24, 2016 at 8:51 AM, Moritz Lennert

Post by Martin Landa
Hi,

Post by Martin Landa
+1 for 7.2.0RC1 in the next days. Any objections, comments? Ma

no objections, +1 for 7.2.0RC1...

+1

As time permits, I'll try to package RC1 tomorrow (err, today), so on 27th Oct.

I have fixed a memory leak in the rasterlib trunk r69751, related to
the new null file compressing, which needs to be backported to relbr72
before final release. Since RC1 is not out yet, should I backport now?
The new null file compression and new compressors for (f)cell files
are new features in G72, by some regarded as quite important new
features, so more testing by those interested in the new compression
methods is most welcome.

There are more memory leaks in lib/raster/open.c and
lib/raster/close.c, but these are minor. However, they should be fixed
at some stage.

Markus M

Post by Markus Neteler
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

Post by Markus Metz
before final release. Since RC1 is not out yet, should I backport now?

well RC1 is already out [1]. But please backport, it will be part of RC2.

Thanks, Ma

[1] https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#ReleaseCandidate1RC1

[Markus Metz]

Post by Martin Landa
Hi,

Post by Markus Metz
before final release. Since RC1 is not out yet, should I backport now?

well RC1 is already out [1]. But please backport, it will be part of RC2.

Apparently I missed the announcement in the mailing lists and the note
on grass.osgeo.org.

Backported to relbr72 with r69753.

Markus M

Post by Martin Landa
Thanks, Ma
[1] https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#ReleaseCandidate1RC1
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

[Markus Neteler]

Post by Markus Metz

Post by Martin Landa
Hi,

Post by Markus Metz
before final release. Since RC1 is not out yet, should I backport now?

well RC1 is already out [1]. But please backport, it will be part of RC2.

Apparently I missed the announcement in the mailing lists and the note
on grass.osgeo.org.

I'll post it as soon as some binary packages are ready.

Post by Markus Metz
Backported to relbr72 with r69753.

Thanks.

markusN

Post by Markus Metz
Markus M

Post by Martin Landa
Thanks, Ma
[1]

https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#ReleaseCandidate1RC1

Post by Markus Metz

Post by Martin Landa
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

[Moritz Lennert]

Post by Markus Neteler

On Fri, Oct 28, 2016 at 11:35 PM, Martin Landa

Hi,
2016-10-28 23:10 GMT+02:00 Markus Metz

Post by Markus Metz
before final release. Since RC1 is not out yet, should I backport

now?

well RC1 is already out [1]. But please backport, it will be part

of
RC2.

Apparently I missed the announcement in the mailing lists and the

note

on grass.osgeo.org.

I'll post it as soon as some binary packages are ready.

As some of the release planning threads span over long periods of time, I understand that some developers don't follow them. Maybe we could add a step to the release procedure in the form of a separate mail a few days before releasing an RC. Something with a title like "Heads up: RC* will be released in X days" ?

Moritz

Post by Markus Neteler

Backported to relbr72 with r69753.

Thanks.
markusN

Markus M

Thanks, Ma
[1]

https://trac.osgeo.org/grass/wiki/Release/7.2.0-News#ReleaseCandidate1RC1

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

[Markus Neteler]

On Sat, Oct 29, 2016 at 10:02 AM, Moritz Lennert

Post by Moritz Lennert

Post by Markus Neteler
I'll post it as soon as some binary packages are ready.

As some of the release planning threads span over long periods of time, I understand that some developers don't follow them. Maybe we could add a step to the release procedure in the form of a separate mail a few days before releasing an RC. Something with a title like "Heads up: RC* will be released in X days" ?

In the past years I was always notifying the packagers an instance
after a RC went online.
Some packagers complained to me to please be less intensively notified
so I reduced it to the final release notifications only since many of
them would not package RCs anyway.

Perhaps we need to split the group of packagers up into
- packagers being interested in all notifications
- packagers being only interested in final release notifications.

Side issue: quite regularly some last minute issues delays the RC
(just check the past 5 years :-) ... so X days is hard to define.

My 0.02 cents
markusN

[Martin Landa]

Hi,

Post by Markus Neteler
Perhaps we need to split the group of packagers up into
- packagers being interested in all notifications
- packagers being only interested in final release notifications.

make sense to. Anyway please put in into the first group :-)

The GRASS 7.2.0RC1 wingrass packages (standalone + osgeo4w in testing
area) + ubuntugis packages in experimental PPA are available. Ma

[Sebastiaan Couwenberg]

Post by Markus Neteler

Post by Markus Metz
Apparently I missed the announcement in the mailing lists and the note
on grass.osgeo.org.

I'll post it as soon as some binary packages are ready.

At least the Debian packages are already available (in Debian
experimental & ubuntugis-experimental).

Kind Regards,

Bas

[Markus Neteler]

Post by Markus Neteler
I'll post it as soon as some binary packages are ready.

Done:
https://grass.osgeo.org/news/64/15/GRASS-GIS-7-2-0RC1-released

(screenshot donated by Vaclav)

markusN

[Markus Neteler]

...

Post by Markus Neteler
- I also created a DRAFT: https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

...

Post by Markus Neteler
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)

Please :-)

Thanks.
Markus

[Moritz Lennert]

...

Post by Markus Neteler
- I also created a DRAFT: https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

...

Post by Markus Neteler
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)

Fixes are added automatically, no ? And they should no go into the
"module changes" sections, or ?

As a side note: should we profit of these release announcements to also
list all the new addons checked into the repository since the last release ?

Moritz

[Vaclav Petras]

On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert <

Post by Markus Neteler
- important: please add fixes and your favourite improvements to the

Post by Markus Neteler
7.2.0-News page (too much for one person to check)

Fixes are added automatically, no ? And they should no go into the "module
changes" sections, or ?

If you mean the list of closed tickets, I would say that that's not enough.
It contains all sorts of stuff (and is [fortunately] very long) and the
ticket title often does not tell you enough (or in a right way) about what
was changed. So a hand-crafted note is better, I think.

Post by Markus Neteler
As a side note: should we profit of these release announcements to also
list all the new addons checked into the repository since the last release ?

I think this is a great idea. It might be just hard to say what is "since
the last release" (now we work on 6.4, 7.0 and 7.2 series).

[Markus Neteler]

Post by Vaclav Petras
On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert

Post by Moritz Lennert

Post by Markus Neteler
- important: please add fixes and your favourite improvements to the
7.2.0-News page (too much for one person to check)

Fixes are added automatically, no ?

Unfortunately not really:
- many bug report titles are hard to understand
- many fixes do not have a bug report

Post by Vaclav Petras

Post by Moritz Lennert
And they should no go into the "module changes" sections, or ?

I believe they should. Because most users will read that part, not the
"scary" #somenumber lines :-)

Post by Vaclav Petras
If you mean the list of closed tickets, I would say that that's not enough.
It contains all sorts of stuff (and is [fortunately] very long) and the
ticket title often does not tell you enough (or in a right way) about what
was changed. So a hand-crafted note is better, I think.

Yes. Also, because it is organized by topic, not by ascending numbers.

Post by Vaclav Petras

Post by Moritz Lennert
As a side note: should we profit of these release announcements to also
list all the new addons checked into the repository since the last release ?

I think this is a great idea. It might be just hard to say what is "since
the last release" (now we work on 6.4, 7.0 and 7.2 series).

Yes, sounds great.

Markus

[Moritz Lennert]

Post by Vaclav Petras
On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert
As a side note: should we profit of these release announcements to
also list all the new addons checked into the repository since the
last release ?
I think this is a great idea. It might be just hard to say what is
"since the last release" (now we work on 6.4, 7.0 and 7.2 series).

For each release news, we would put in the addons added since the last
release of that series.

So, for 7.0.5, we would add the grass6 addons which were uploaded since
7.0.4, and for 7.2 a list of all addons since 7.0. I don't think we have
to do this for grass6.

Sound ok ?

Moritz

[Vaclav Petras]

On Wed, Aug 31, 2016 at 2:52 AM, Moritz Lennert <

Post by Moritz Lennert
For each release news, we would put in the addons added since the last
release of that series.
So, for 7.0.5, we would add the grass6 addons which were uploaded since
7.0.4, and for 7.2 a list of all addons since 7.0. I don't think we have to
do this for grass6.
Sound ok ?

Yes. Log for the Makefile from each module type directory could be a
starting point:

https://trac.osgeo.org/grass/log/grass-addons/grass7/raster/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/vector/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/imagery/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/raster3d/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/misc/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/display/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/db/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/temporal/Makefile

[Moritz Lennert]

Post by Vaclav Petras
On Wed, Aug 31, 2016 at 2:52 AM, Moritz Lennert
For each release news, we would put in the addons added since the
last release of that series.
So, for 7.0.5, we would add the grass6 addons which were uploaded
since 7.0.4, and for 7.2 a list of all addons since 7.0. I don't
think we have to do this for grass6.
Sound ok ?
Yes. Log for the Makefile from each module type directory could be a
https://trac.osgeo.org/grass/log/grass-addons/grass7/raster/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/vector/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/imagery/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/raster3d/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/misc/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/display/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/db/Makefile
https://trac.osgeo.org/grass/log/grass-addons/grass7/temporal/Makefile

Good idea.

Although I have a question concerning these Makefiles. I noticed that I
never entered i.segment.uspo in

https://trac.osgeo.org/grass/log/grass-addons/grass7/imagery/Makefile

but it is being compiled on the Windows server:

https://wingrass.fsv.cvut.cz/grass73/x86_64/addons/grass-7.3.svn/

What exactly is the role of these Makefiles ? Why do we need them ?

Moritz

[Markus Neteler]

On Thu, Sep 1, 2016 at 10:57 AM, Moritz Lennert
<***@club.worldonline.be> wrote:
...

Post by Moritz Lennert
Although I have a question concerning these Makefiles. I noticed that I
never entered i.segment.uspo in
https://trac.osgeo.org/grass/log/grass-addons/grass7/imagery/Makefile

The Windows built train does not use the Makefiles (that's only
happening on Unix based system) but simply compiles everything in the
directory tree.

The Linux compile chain for the addons does use the Makefiles: hence
modules should be added there.

Markus

[Moritz Lennert]

Post by Markus Neteler
On Thu, Sep 1, 2016 at 10:57 AM, Moritz Lennert
...

Post by Moritz Lennert
Although I have a question concerning these Makefiles. I noticed that I
never entered i.segment.uspo in
https://trac.osgeo.org/grass/log/grass-addons/grass7/imagery/Makefile

The Windows built train does not use the Makefiles (that's only
happening on Unix based system) but simply compiles everything in the
directory tree.
The Linux compile chain for the addons does use the Makefiles: hence
modules should be added there.

You mean for the binary snapshot ? Users on Linux can still run
g.extension on a module even if it does not have an entry in the section
Makefile...

Here's a preliminary list of the new ones that are listed with
'g.extension -c', but I'll clean that up tomorrow the latest:

v.tin.to.rast: Converts (rasterize) a TIN map into a raster map
v.maxent.swd: Export raster values at given point locations as text file
in SWD format for input in Maxent
v.in.gbif: importing of GBIF species distribution data
v.in.redlist: importing of IUCN Red List Spatial Data
v.class.mlR: Provides supervised support vector machine classification
v.in.natura2000: importing of Natura 2000 spatial data of protected areas
v.mrmr: Perform Minimum Redundancy Maximum Relevance Feature Selection
on a GRASS Attribute Table
v.in.osm: Imports OpenStreetMap data into GRASS GIS.
v.stream.order: Compute the stream order of stream networks stored in a
vector map at specific outlet vector points
r.mcda.promethee: Multicirtieria decision analysis based on PROMETHEE method
r.stream.variables:
r.category.trim: Export categories and corresponding colors as QGIS
colour file or csv file. Non-existing categories and their colour
definitions will be removed.
r.mregression.series:
r.series.decompose: Program calculates decomposition of time series X
r.out.legend: Create and export image file with legend of a raster map
r.terrain.texture: Pit and peak density
r.tri: Terrain Ruggedness Index
r.vector.ruggedness: Vector Ruggedness Measure
r.euro.ecosystem: Sets colors and categories of European ecosystem
raster data set
r.jpdf: From two series of input raster maps, calculates the joint
probability function and outputs the probabilities of occurrence in the
specified bins.
r.neighborhoodmatrix: Calculates a neighborhood matrix for a raster map
with regions
r.change.info: Landscape change assessment
r.randomforest: Provides supervised random forest classification
i.segment.stats: Calculates statistics describing raster areas
i.ortho.corr: Correct orthophoto taking part of the near orthophotos
using the camera angle map
i.segment.uspo: Unsupervised segmentation parameter optimization
i.gcp: Manages Ground Control Points (GCPs) non-interactively.
i.landsat8.swlst: Practical split-window algorithm estimating Land
Surface Temperature from Landsat 8 OLI/TIRS imagery (Du, Chen; Ren,
Huazhong; Qin, Qiming; Meng, Jinjie; Zhao, Shaohua. 2015)
i.lswt: Compute LSWT from TOA Brightness Temperatures

New addons since 7.0.4 (since May):

v.in.pygbif:
v.strds.stats: Calculates univariate statistics from given space-time
raster datasets based on a vector map
v.sort.points: Sorts a vector point map according to a numeric column
v.what.spoly: Queries vector map with overlaping "spaghetti" polygons
(e.g. Landsat footprints) at given location. Polygons must have not
intersected boundaries.
v.explode: "Explode" polylines, splitting them to separate lines (uses
v.split + v.category)
v.clip: Extracts features of input map which overlay features of clip map.
v.surf.tps:
r.colors.matplotlib: Convert or apply a Matplotlib color table to a
GRASS raster map
r.colors.cubehelix: Create or apply a cubehelix color table to a GRASS
raster map
r.object.geometry: Calculates geometry parameters for raster objects.
r3.what: Queries 3D raster in specified 2D or 3D coordinates.
i.landsat8.qc: Reclass Landsat8 QA band according to acceptable pixel
quality as defined by the user
i.fusion.hpf:
i.image.bathymetry: Satellite Derived Bathymetry (SDB) from
multispectral images
m.printws: Opens a workspace file and creates a map sheet according to
its visible contents.

[Michael Barton]

If we could get wxPython 3.x working for the GUI, we could switch all Mac compiling to 64bit. That would make LAS libraries MUCH easier to compile and bundle with GRASS. I've posted a 64bit version of GRASS 7.1 with wxPython 3.0.2.0 for people to test and report bugs. It mostly works fine. So it may not be a big deal to fix the few remaining issues.

Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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


On Apr 30, 2016, at 5:59 AM, grass-dev-***@lists.osgeo.org<mailto:grass-dev-***@lists.osgeo.org> wrote:

From: Vaclav Petras <***@gmail.com<mailto:***@gmail.com>>
Subject: Re: [GRASS-dev] grass 7.2 planning
Date: April 30, 2016 at 5:59:27 AM MST

Post by Martin Landa

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at FOSS4G
NA [1]

we can wait one week or so if you wish.

Thanks. This would give at least some chance to get things straight.

Post by Martin Landa

Post by Vaclav Petras
From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that's fine.

Yes, I used the editor in lessons. Nice tool!

Thanks. It took me some time to discover that this is exactly what users want.

Post by Martin Landa
I had only one problem,
sometimes run button was not working (I discovered why after lesson)

I focused on getting the basics working but the executing is just tricky. Will try to look at it as well to see if some substantial changes are needed.

[Michael Barton]

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

I guess it's C++. But it's open source without some of the legal and compiling issues of LAStools.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















On Apr 30, 2016, at 9:28 AM, Michael Barton <***@asu.edu<mailto:***@asu.edu>> wrote:

If we could get wxPython 3.x working for the GUI, we could switch all Mac compiling to 64bit. That would make LAS libraries MUCH easier to compile and bundle with GRASS. I've posted a 64bit version of GRASS 7.1 with wxPython 3.0.2.0 for people to test and report bugs. It mostly works fine. So it may not be a big deal to fix the few remaining issues.

Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: [phone] (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu<http://csdc.asu.edu/>


On Apr 30, 2016, at 5:59 AM, grass-dev-***@lists.osgeo.org<mailto:grass-dev-***@lists.osgeo.org> wrote:

From: Vaclav Petras <***@gmail.com<mailto:***@gmail.com>>
Subject: Re: [GRASS-dev] grass 7.2 planning
Date: April 30, 2016 at 5:59:27 AM MST

Post by Martin Landa

Post by Vaclav Petras
I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can't promise any commits since I'm at FOSS4G
NA [1]

we can wait one week or so if you wish.

Thanks. This would give at least some chance to get things straight.

Post by Martin Landa

Post by Vaclav Petras
From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that's fine.

Yes, I used the editor in lessons. Nice tool!

Thanks. It took me some time to discover that this is exactly what users want.

Post by Martin Landa
I had only one problem,
sometimes run button was not working (I discovered why after lesson)

I focused on getting the basics working but the executing is just tricky. Will try to look at it as well to see if some substantial changes are needed.

[Vaclav Petras]

Hi Michael,

I'm currently looking at the lidar-related functionality, so here is some
info.

Post by Michael Barton
Related to this, is there a plan to replace liblas with the new Python
alternative (the name escapes me at the moment)? This would further
simplify making robust LiDAR tools available in GRASS
The LiDAR tools I was thinking of is PDAL.
http://www.pdal.io

You can try compile GRASS with PDAL right now. Just note that PDAL is not a
drop-in replacement for libLAS and so far the PDAL functionality is
available only through special module v.in.pdal. See #2732 [1] for details.

Post by Michael Barton
I guess it's C++.

Yes, it's C++ not C or Python and it currently does not have C API, so it
might be even harder to connect in general. The basic functionality newly
(since release 1.2) does not depend on Boost but the new C++ (I think
C++11) is needed. It is important to note that most of the fancy
functionality (like ground detection) is provided through another
dependency, PCL (http://pointclouds.org/), which is a large point cloud
processing library which depends on Boost (if I recall correctly).

But it's open source without some of the legal and compiling issues of

Post by Michael Barton
LAStools.

With the current GRASS source code we are able to use only libLAS (
http://www.liblas.org/), not LAStools (https://rapidlasso.com/lastools/)
[2].

Best,
Vaclav


[1] https://trac.osgeo.org/grass/ticket/2732
[2] https://lists.osgeo.org/pipermail/grass-dev/2015-September/076318.html

[Michael Barton]

Vaclav,

I agree with all of your points. There was a little discussion about recoding GRASS LiDAR tools to use PDAL instead of libLAS. I am just wondering if that has gone anywhere or not.

libLAS is missing some of the most sophisticated filtering routines found in the non-open-source LAStools. PDAL seems to have them according to the web site but I admit that I have not yet tried them. I might have time to do so in the coming weeks.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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



On Apr 30, 2016, at 10:26 AM, Vaclav Petras <***@gmail.com<mailto:***@gmail.com>> wrote:

Hi Michael,

I'm currently looking at the lidar-related functionality, so here is some info.

On Sat, Apr 30, 2016 at 12:28 PM, Michael Barton <***@asu.edu<mailto:***@asu.edu>> wrote:
Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

On Sat, Apr 30, 2016 at 12:36 PM, Michael Barton <***@asu.edu<mailto:***@asu.edu>> wrote:
The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io<http://www.pdal.io/>

You can try compile GRASS with PDAL right now. Just note that PDAL is not a drop-in replacement for libLAS and so far the PDAL functionality is available only through special module v.in.pdal. See #2732 [1] for details.


I guess it's C++.

Yes, it's C++ not C or Python and it currently does not have C API, so it might be even harder to connect in general. The basic functionality newly (since release 1.2) does not depend on Boost but the new C++ (I think C++11) is needed. It is important to note that most of the fancy functionality (like ground detection) is provided through another dependency, PCL (http://pointclouds.org/), which is a large point cloud processing library which depends on Boost (if I recall correctly).

But it's open source without some of the legal and compiling issues of LAStools.

With the current GRASS source code we are able to use only libLAS (http://www.liblas.org/), not LAStools (https://rapidlasso.com/lastools/) [2].

Best,
Vaclav


[1] https://trac.osgeo.org/grass/ticket/2732
[2] https://lists.osgeo.org/pipermail/grass-dev/2015-September/076318.html

[Markus Neteler]

Post by Michael Barton
The LiDAR tools I was thinking of is PDAL.
http://www.pdal.io
I guess it's C++. But it's open source without some of the legal and
compiling issues of LAStools.

There is already a ticket:
#2732: Read lidar data as vector points using PDAL

Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

:)

Markus

[Sebastiaan Couwenberg]

Post by Markus Neteler
Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

You only need all those dependencies if need all the PDAL plugins, core
PDAL only requires GDAL, the other dependencies are optional.

The pdal Debian package only enables the plugins for which the
dependencies are available (greyhound, icebridge, python & sqlite). The
PCL plugin pulls in the enormous and problematic VTK dependency chain
and has been disabled in the Debian package despite the dependencies
being available.

Kind Regards,

Bas

[Michael Barton]

Yes. This is a problem. I've only run it in a docker container so far. So I don't know how hard it will be to compile it--probably difficult.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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

Post by Markus Neteler

Post by Michael Barton
The LiDAR tools I was thinking of is PDAL.
http://www.pdal.io
I guess it's C++. But it's open source without some of the legal and
compiling issues of LAStools.

#2732: Read lidar data as vector points using PDAL
Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.
:)
Markus

[Michael Barton]

Unfortunately, the very important "ground" module (filtering for ground surface points) requires PCL, but perhaps not VTK which may be mainly for the "view"/visualization modules and functions. JSON is only needed for the "pipeline" module

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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


On Apr 30, 2016, at 4:05 PM, grass-dev-***@lists.osgeo.org<mailto:grass-dev-***@lists.osgeo.org> wrote:

From: Sebastiaan Couwenberg <***@xs4all.nl<mailto:***@xs4all.nl>>
Subject: Re: [GRASS-dev] grass 7.2 planning
Date: April 30, 2016 at 2:41:24 PM MST
To: <grass-***@lists.osgeo.org<mailto:grass-***@lists.osgeo.org>>


On 04/30/2016 11:22 PM, Markus Neteler wrote:
Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

You only need all those dependencies if need all the PDAL plugins, core
PDAL only requires GDAL, the other dependencies are optional.

The pdal Debian package only enables the plugins for which the
dependencies are available (greyhound, icebridge, python & sqlite). The
PCL plugin pulls in the enormous and problematic VTK dependency chain
and has been disabled in the Debian package despite the dependencies
being available.

Kind Regards,

Bas

[Markus Neteler]

Post by Martin Landa
Hi all,
personally I would like to see GRASS 7.2.0 released somewhere in July.
Do you think that it's realistic? If so I would suggest roadmap
1) to create releasebranch 7_2 ASAP (in the beginning of May)
1) soft freeze in releasebranch_7_2 ~ 16 May
2) GRASS 7.2.0RC1 ~ 16 June
3) GRASS 7.2.0RC2 ~ 30 June
4) GRASS 7.2.0 ~ 7 July

I have added a new 7.2.0 milestone in trac (also a 7.3.0 milestone
which replaces the function of the actual 7.1.0 milestone).

We may now assign tickets to the 7.2.0 milestone from "7.1.0" to get
an overview what needs to be fixed for the next major stable release.

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
I have added a new 7.2.0 milestone in trac (also a 7.3.0 milestone
which replaces the function of the actual 7.1.0 milestone).

probably we could rename dev version milestone as 7.1 / 7.3 since
these version will be never released (?) Ma

[Markus Neteler]

Post by Martin Landa
Hi,

Post by Markus Neteler
I have added a new 7.2.0 milestone in trac (also a 7.3.0 milestone
which replaces the function of the actual 7.1.0 milestone).

probably we could rename dev version milestone as 7.1 / 7.3 since
these version will be never released (?)

Good idea!

Markus

[Markus Neteler]

Post by Markus Neteler

Post by Martin Landa

Post by Markus Neteler
I have added a new 7.2.0 milestone in trac (also a 7.3.0 milestone
which replaces the function of the actual 7.1.0 milestone).

probably we could rename dev version milestone as 7.1 / 7.3 since
these version will be never released (?)

Good idea!

Done as suggested:

milestone 7.1.0 renamed to 7.2.0:
https://trac.osgeo.org/grass/milestone/7.2.0

We have a an additional 7.3.0 (will never be released) which we will
rename to 7.4.0 in future.
All tickets not to be solved for 7.2.0 can be migrated to 7.3.0 now as
well as 8.0.0.

At time we have 155 open tickets on 7.2.0 which need to be reviewed
for that (or solved).

Markus

[Vaclav Petras]

Post by Markus Neteler
We have a an additional 7.3.0 (will never be released) which we will
rename to 7.4.0 in future.

So, do we even need 7.3.0 milestone?

BTW, we need 7.0.4 version in Trac.

[Martin Landa]

Hi,

Post by Vaclav Petras
BTW, we need 7.0.4 version in Trac.

it's already there [1]? Martin

[1] https://trac.osgeo.org/grass/admin/ticket/versions/7.0.4

[Markus Neteler]

Post by Vaclav Petras

Post by Markus Neteler
We have a an additional 7.3.0 (will never be released) which we will
rename to 7.4.0 in future.

So, do we even need 7.3.0 milestone?

I agree to remove it.

Post by Vaclav Petras

Post by Markus Neteler
BTW, we need 7.0.4 version in Trac.

it's already there [1]? Martin
[1] https://trac.osgeo.org/grass/admin/ticket/versions/7.0.4

I added it 15min ago and also update the release procedure document to
increment the version in trac to not forget again.

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
I added it 15min ago and also update the release procedure document to
increment the version in trac to not forget again.

btw, I have also updated web site (main page + windows) which still
pointed to 7.0.3 version. Martin

[Markus Neteler]

Post by Martin Landa

Post by Markus Neteler
I added it 15min ago and also update the release procedure document to
increment the version in trac to not forget again.

btw, I have also updated web site (main page + windows) which still
pointed to 7.0.3 version. Martin

Thanks. We need to reduce the numbers of pages in which versions are
explicitly mentioned.

Markus

[Helena Mitasova]

Michael,

we can look at these issues during our visit at ASU later this month -
Vasek has done quite a bit of work on this and can give you an overview on
what the best approach would be - see here abstract of his talk at FOSS4G
NA

https://2016.foss4g-na.org/session/grass-gis-loves-lidar

Helena

Post by Michael Barton
Unfortunately, the very important "ground" module (filtering for ground
surface points) requires PCL, but perhaps not VTK which may be mainly for
the "view"/visualization modules and functions. JSON is only needed for the
"pipeline" module
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: [phone] (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
*Subject: **Re: [GRASS-dev] grass 7.2 planning*
*Date: *April 30, 2016 at 2:41:24 PM MST
Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.
You only need all those dependencies if need all the PDAL plugins, core
PDAL only requires GDAL, the other dependencies are optional.
The pdal Debian package only enables the plugins for which the
dependencies are available (greyhound, icebridge, python & sqlite). The
PCL plugin pulls in the enormous and problematic VTK dependency chain
and has been disabled in the Debian package despite the dependencies
being available.
Kind Regards,
Bas
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Helena Mitasova
Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/

email: ***@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax [phone]

[Michael Barton]

Nice slides. As it stands now, PDAL without PCL is probably a reasonable replacement for libLAS. However, it could also be nice to have access to the PDAL/PCL ground module. So we need to look at what it would take to compile PDAL with and without ground.

I hope we can also talk about 64 bit wxPython 3 implementations and how to get past the Mac OS X 10.11 SIP problem.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

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















On May 2, 2016, at 12:10 AM, Helena Mitasova <***@ncsu.edu<mailto:***@ncsu.edu>> wrote:

Michael,

we can look at these issues during our visit at ASU later this month - Vasek has done quite a bit of work on this and can give you an overview on what the best approach would be - see here abstract of his talk at FOSS4G NA

https://2016.foss4g-na.org/session/grass-gis-loves-lidar

Helena

On Sun, May 1, 2016 at 1:21 AM, Michael Barton <***@asu.edu<mailto:***@asu.edu>> wrote:
Unfortunately, the very important "ground" module (filtering for ground surface points) requires PCL, but perhaps not VTK which may be mainly for the "view"/visualization modules and functions. JSON is only needed for the "pipeline" module

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262<tel:[phone]> (SHESC), 480-965-8130<tel:[phone]>/727-9746 (CSDC)
fax: [phone]<tel:[phone]> (SHESC), 480-727-0709<tel:[phone]> (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu<http://csdc.asu.edu/>


On Apr 30, 2016, at 4:05 PM, grass-dev-***@lists.osgeo.org<mailto:grass-dev-***@lists.osgeo.org> wrote:

From: Sebastiaan Couwenberg <***@xs4all.nl<mailto:***@xs4all.nl>>
Subject: Re: [GRASS-dev] grass 7.2 planning
Date: April 30, 2016 at 2:41:24 PM MST
To: <grass-***@lists.osgeo.org<mailto:grass-***@lists.osgeo.org>>


On 04/30/2016 11:22 PM, Markus Neteler wrote:
Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

You only need all those dependencies if need all the PDAL plugins, core
PDAL only requires GDAL, the other dependencies are optional.

The pdal Debian package only enables the plugins for which the
dependencies are available (greyhound, icebridge, python & sqlite). The
PCL plugin pulls in the enormous and problematic VTK dependency chain
and has been disabled in the Debian package despite the dependencies
being available.

Kind Regards,

Bas


_______________________________________________
grass-dev mailing list
grass-***@lists.osgeo.org<mailto:grass-***@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev



--
Helena Mitasova
Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/

email: ***@ncsu.edu<mailto:***@ncsu.edu>
ph: 919-513-1327 (no voicemail)
fax [phone]