Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 21/01/15 10:56, Markus Neteler wrote: On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 20/01/15 18:04, Markus Neteler wrote: On Fri, Jan 16, 2015 at 11:21 PM, Anna Petrášová kratocha...@gmail.com On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Well, this procedure states that : If sufficient support is present, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). [...] The announcement should also include an approximate time table for the release, including the start of hard freeze, RC1, RC2, final release and the link to the trac page. Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that) Coming back to this after a while. I think this is exactly the question: should we wait until everything is backported, or should we fix a date and if some things are not backported, they will have to be in the next point release ? In the proposed release procedure backports should be done before the hard freeze and the first RC... Just to be sure: I'm not criticizing the way the release is handled, just using this current release to illustrate the ideas of the proposed release procedure. And some of the experiences of the current release could maybe feed back into amendments of that proposal. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/01/15 10:56, Markus Neteler wrote: ... Coming back to this after a while. I think this is exactly the question: should we wait until everything is backported, or should we fix a date and if some things are not backported, they will have to be in the next point release ? The important blocker is now the welcome screen issue. In the proposed release procedure backports should be done before the hard freeze and the first RC... Sure. But we can definitely not release G7 with a startup identical to G6. Too bad that nobody cared in the past 2 years but only now. Just to be sure: I'm not criticizing the way the release is handled, just using this current release to illustrate the ideas of the proposed release procedure. And some of the experiences of the current release could maybe feed back into amendments of that proposal. Yes, agreed. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 27/01/15 10:31, Markus Neteler wrote: On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/01/15 10:56, Markus Neteler wrote: ... Coming back to this after a while. I think this is exactly the question: should we wait until everything is backported, or should we fix a date and if some things are not backported, they will have to be in the next point release ? The important blocker is now the welcome screen issue. In the proposed release procedure backports should be done before the hard freeze and the first RC... Sure. But we can definitely not release G7 with a startup identical to G6. Too bad that nobody cared in the past 2 years but only now. Well, that's the deadline effect Glynn already spoke about when discussing the last-minute rush to harmonising option keys [1]. Not much we can do about this I'm afraid, except maybe creating deadlines more often ;-) Moritz [1] http://trac.osgeo.org/grass/ticket/2409#comment:122 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
As far as I can help the startup screen issue, I'll try to make a point tomorrow on the wiki. There is no doubt a solution can be found in a couple of days, is there ? V. Le mardi 27 janvier 2015 à 10:31 +0100, Markus Neteler a écrit : On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/01/15 10:56, Markus Neteler wrote: ... Coming back to this after a while. I think this is exactly the question: should we wait until everything is backported, or should we fix a date and if some things are not backported, they will have to be in the next point release ? The important blocker is now the welcome screen issue. In the proposed release procedure backports should be done before the hard freeze and the first RC... Sure. But we can definitely not release G7 with a startup identical to G6. Too bad that nobody cared in the past 2 years but only now. Just to be sure: I'm not criticizing the way the release is handled, just using this current release to illustrate the ideas of the proposed release procedure. And some of the experiences of the current release could maybe feed back into amendments of that proposal. Yes, agreed. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 22/01/15 08:05, Markus Neteler wrote: On Thu, Jan 22, 2015 at 1:40 AM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:56 AM, Markus Neteler nete...@osgeo.org wrote: Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that): http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Excerpt: - Update Release/7.0.0RC1-News - Should it become generic RC News? - Update Splash screen - Update Welcome screen To be backported: - r64270 raster3d docs - r64239, r64216 temporal docs - r64226 XML (?) Relevant differences - to be clarified: - various modules: %s= and %s= are mutually exclusive (r?) I am not sure what this last one means, do we know which modules is it related to? This change (and related) has not been backported so far (I understand that it is a relevant patch): http://trac.osgeo.org/grass/changeset/60703 1. Consolite option/flag mutually exslusive messages. %s= and %s= are mutually exclusive %s= and %s= are mutually exclusive. %s= will be ignored. %s= and %s=/%s= are mutually exclusive %s=, %s=, %s= and %s= are mutually exclusive. %s=, %s= and %s= are mutually exclusive -%c and %s= are mutually exclusive -%c and -%c are mutually exclusive -%c, -%c, %s=, %s= and %s= are mutually exclusive -%c/-%c and %s= are mutually exclusive -%c/-%c and %s=%s are mutually exclusive -%c/-%c and -%c are mutually exclusive 2. Option(s) opt, ... = opt=, ... 3. Flag(s) -f, ... = -f, ... Shouldn't this be handled by the new exlusive / dependent / etc settings for the parser ? With a message from the parser in case of issues ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Thu, Jan 22, 2015 at 5:43 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 22/01/15 08:05, Markus Neteler wrote: On Thu, Jan 22, 2015 at 1:40 AM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:56 AM, Markus Neteler nete...@osgeo.org wrote: Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that): http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Excerpt: - Update Release/7.0.0RC1-News - Should it become generic RC News? - Update Splash screen - Update Welcome screen To be backported: - r64270 raster3d docs - r64239, r64216 temporal docs - r64226 XML (?) Relevant differences - to be clarified: - various modules: %s= and %s= are mutually exclusive (r?) I am not sure what this last one means, do we know which modules is it related to? This change (and related) has not been backported so far (I understand that it is a relevant patch): http://trac.osgeo.org/grass/changeset/60703 1. Consolite option/flag mutually exslusive messages. %s= and %s= are mutually exclusive %s= and %s= are mutually exclusive. %s= will be ignored. %s= and %s=/%s= are mutually exclusive %s=, %s=, %s= and %s= are mutually exclusive. %s=, %s= and %s= are mutually exclusive -%c and %s= are mutually exclusive -%c and -%c are mutually exclusive -%c, -%c, %s=, %s= and %s= are mutually exclusive -%c/-%c and %s= are mutually exclusive -%c/-%c and %s=%s are mutually exclusive -%c/-%c and -%c are mutually exclusive 2. Option(s) opt, ... = opt=, ... 3. Flag(s) -f, ... = -f, ... Shouldn't this be handled by the new exlusive / dependent / etc settings for the parser ? With a message from the parser in case of issues ? Yes, they should. But I wouldn't change it to the new system for the release, from my experience, you can easily make a mistake. But r60703 should be backported (just to avoid unnecessary differences between 70 and 71), I wanted to do that, but there were some conflicts, so I will look at it later. Anna Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-21 18:11 GMT+01:00 Markus Neteler nete...@osgeo.org: Done (with redirect link on old page + updated in CMS): http://trac.osgeo.org/grass/wiki/Release/7.0.0RC-News thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Wed, Jan 21, 2015 at 2:56 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-21 10:56 GMT+01:00 Markus Neteler nete...@osgeo.org: - Update Release/7.0.0RC1-News - Should it become generic RC News? yes, I would vote for generic as we did for betas. Done (with redirect link on old page + updated in CMS): http://trac.osgeo.org/grass/wiki/Release/7.0.0RC-News Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Wed, Jan 21, 2015 at 4:56 AM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 20/01/15 18:04, Markus Neteler wrote: On Fri, Jan 16, 2015 at 11:21 PM, Anna Petrášová kratocha...@gmail.com On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Well, this procedure states that : If sufficient support is present, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). [...] The announcement should also include an approximate time table for the release, including the start of hard freeze, RC1, RC2, final release and the link to the trac page. Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that): http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Excerpt: - Update Release/7.0.0RC1-News - Should it become generic RC News? - Update Splash screen - Update Welcome screen To be backported: - r64270 raster3d docs - r64239, r64216 temporal docs - r64226 XML (?) Relevant differences - to be clarified: - various modules: %s= and %s= are mutually exclusive (r?) I am not sure what this last one means, do we know which modules is it related to? Anna All this needs to be solved for RC2. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Thu, Jan 22, 2015 at 1:40 AM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:56 AM, Markus Neteler nete...@osgeo.org wrote: Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that): http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Excerpt: - Update Release/7.0.0RC1-News - Should it become generic RC News? - Update Splash screen - Update Welcome screen To be backported: - r64270 raster3d docs - r64239, r64216 temporal docs - r64226 XML (?) Relevant differences - to be clarified: - various modules: %s= and %s= are mutually exclusive (r?) I am not sure what this last one means, do we know which modules is it related to? This change (and related) has not been backported so far (I understand that it is a relevant patch): http://trac.osgeo.org/grass/changeset/60703 1. Consolite option/flag mutually exslusive messages. %s= and %s= are mutually exclusive %s= and %s= are mutually exclusive. %s= will be ignored. %s= and %s=/%s= are mutually exclusive %s=, %s=, %s= and %s= are mutually exclusive. %s=, %s= and %s= are mutually exclusive -%c and %s= are mutually exclusive -%c and -%c are mutually exclusive -%c, -%c, %s=, %s= and %s= are mutually exclusive -%c/-%c and %s= are mutually exclusive -%c/-%c and %s=%s are mutually exclusive -%c/-%c and -%c are mutually exclusive 2. Option(s) opt, ... = opt=, ... 3. Flag(s) -f, ... = -f, ... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 20/01/15 18:04, Markus Neteler wrote: On Fri, Jan 16, 2015 at 11:21 PM, Anna Petrášová kratocha...@gmail.com On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Well, this procedure states that : If sufficient support is present, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). [...] The announcement should also include an approximate time table for the release, including the start of hard freeze, RC1, RC2, final release and the link to the trac page. Well, it is very difficult to predict the final release date. See here for the undone backports which I have found (indeed, it is the task of the respective developer to take care of that): http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Excerpt: - Update Release/7.0.0RC1-News - Should it become generic RC News? - Update Splash screen - Update Welcome screen To be backported: - r64270 raster3d docs - r64239, r64216 temporal docs - r64226 XML (?) Relevant differences - to be clarified: - various modules: %s= and %s= are mutually exclusive (r?) All this needs to be solved for RC2. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 20/01/15 18:04, Markus Neteler wrote: On Fri, Jan 16, 2015 at 11:21 PM, Anna Petrášová kratocha...@gmail.com wrote: On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-01-16 16:31 GMT+01:00 Yann Chemin yche...@gmail.com: In view of Markus M explanation, +1 for RC2 today rather than tomorrow. I don't see any reason why to hurry so much. Let's wait at least some days. Martin I would like to have RC2 soon too, but let's wait until next week, we will be able to fix hopefully couple of other things until then. We should consider RC2 for later this week. What's missing for it in terms of fixes? We should have clearer idea what will be after RC2? For now I have started to add stuff to http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing How long do we plan to test before release? I know it will depend on current situation, but still we should have a plan. There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Well, this procedure states that : If sufficient support is present, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). [...] The announcement should also include an approximate time table for the release, including the start of hard freeze, RC1, RC2, final release and the link to the trac page. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-21 10:56 GMT+01:00 Markus Neteler nete...@osgeo.org: - Update Release/7.0.0RC1-News - Should it become generic RC News? yes, I would vote for generic as we did for betas. [...] Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 16, 2015 at 11:21 PM, Anna Petrášová kratocha...@gmail.com wrote: On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-01-16 16:31 GMT+01:00 Yann Chemin yche...@gmail.com: In view of Markus M explanation, +1 for RC2 today rather than tomorrow. I don't see any reason why to hurry so much. Let's wait at least some days. Martin I would like to have RC2 soon too, but let's wait until next week, we will be able to fix hopefully couple of other things until then. We should consider RC2 for later this week. What's missing for it in terms of fixes? We should have clearer idea what will be after RC2? For now I have started to add stuff to http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing How long do we plan to test before release? I know it will depend on current situation, but still we should have a plan. There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-20 18:04 GMT+01:00 Markus Neteler nete...@osgeo.org: There is a plan: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure for GRASS 7.0 I can imagine also RC3 but not more. In any case we are in hard freeze period now. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sun, Jan 18, 2015 at 11:49 PM, Markus Neteler nete...@osgeo.org wrote: I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset I disagree. The baseline dataset should be a subset of the full dataset. The names in the baseline dataset should be identical to the names in the full dataset. Otherwise, as it is now, it just creates confusion for no reason. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Jan 20, 2015 9:13 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sun, Jan 18, 2015 at 11:49 PM, Markus Neteler nete...@osgeo.org wrote: I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset I disagree. The baseline dataset should be a subset of the full dataset. The names in the baseline dataset should be identical to the names in the full dataset. Otherwise, as it is now, it just creates confusion for no reason. The point is that the new full dataset will come with simplified names. It is in preparation for the fourth GRASS GIS book edition. We should update the track page more... markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Tue, Jan 20, 2015 at 9:20 PM, Markus Neteler nete...@osgeo.org wrote: On Jan 20, 2015 9:13 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sun, Jan 18, 2015 at 11:49 PM, Markus Neteler nete...@osgeo.org wrote: I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset I disagree. The baseline dataset should be a subset of the full dataset. The names in the baseline dataset should be identical to the names in the full dataset. Otherwise, as it is now, it just creates confusion for no reason. The point is that the new full dataset will come with simplified names. It is in preparation for the fourth GRASS GIS book edition. That means we need to update a lot of examples in the man pages of 7.x including 7.0? Markus M We should update the track page more... markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. Setting environmental variable should be easy in the test suite. I'm not sure about the v.generalize modification. Topology debugging tool sound's generally useful. Perhaps it could be part of v.generalize interface or a standalone module (build with v.generalize in the same way as r.colors and r3.colors are) but for tests it really doesn't matter. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. Let me know if you miss something in testing framework which would help you to write the tests. I would like to provide a command and the test suite must check the return status. If someone else could then turn this into a testsuite script, that would be great! Any .sh or .py script you put to testsuite directory anywhere in GRASS source code will be executed as test, so in your case, it should be enough just to put the command to .sh file together with the appropriate export command for the environmental variable. I'm afraid this feature is not really documented (except for emails) because I did it in last minute and it is not the best practice. Anyway, posting command is fine if the only thing needed is to check return status. For nc_spm_08, the test commands would be (as shell script): g.region -p rast=landuse96_28m@PERMANENT r.to.vect in=landuse96_28m@PERMANENT out=landuse96_28m type=area export GRASS_VECTOR_TOPO_DEBUG=1 # check return code of v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21 if [ $? -ne 0 ] ; then exit 1 fi The vectors in the sample datasets are too good, I did not find a vector to provoke any errors, thus the r.to.vect step. Real world datasets, particularly vectors with administrative areas or land cover/land use classification, are in this respect more suitable because they contain lots of topological errors. Unfortunately, these datasets are too large to be included in the sample datasets. Markus M Vaclav Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Tue, Jan 20, 2015 at 10:16 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Tue, Jan 20, 2015 at 9:20 PM, Markus Neteler nete...@osgeo.org wrote: On Jan 20, 2015 9:13 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sun, Jan 18, 2015 at 11:49 PM, Markus Neteler nete...@osgeo.org wrote: I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset I disagree. The baseline dataset should be a subset of the full dataset. The names in the baseline dataset should be identical to the names in the full dataset. Otherwise, as it is now, it just creates confusion for no reason. The point is that the new full dataset will come with simplified names. It is in preparation for the fourth GRASS GIS book edition. That means we need to update a lot of examples in the man pages of 7.x including 7.0? In case yes. I already offer to do the job (a not-so-hard search/replace operation). Obviously we need to speed up with this. Or forget about it for 7.0.0. But mixing nc_full and nc_basic remains a bad idea. markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. Setting environmental variable should be easy in the test suite. I'm not sure about the v.generalize modification. Topology debugging tool sound's generally useful. Perhaps it could be part of v.generalize interface or a standalone module (build with v.generalize in the same way as r.colors and r3.colors are) but for tests it really doesn't matter. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. Let me know if you miss something in testing framework which would help you to write the tests. I would like to provide a command and the test suite must check the return status. If someone else could then turn this into a testsuite script, that would be great! Any .sh or .py script you put to testsuite directory anywhere in GRASS source code will be executed as test, so in your case, it should be enough just to put the command to .sh file together with the appropriate export command for the environmental variable. I'm afraid this feature is not really documented (except for emails) because I did it in last minute and it is not the best practice. Anyway, posting command is fine if the only thing needed is to check return status. For nc_spm_08, the test commands would be (as shell script): g.region -p rast=landuse96_28m@PERMANENT r.to.vect in=landuse96_28m@PERMANENT out=landuse96_28m type=area export GRASS_VECTOR_TOPO_DEBUG=1 # check return code of v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21 if [ $? -ne 0 ] ; then exit 1 fi Done in r64269 [1]. To run, start GRASS and execute [2]: cd lib/vector/ python -m grass.gunittest.main --location my_nc_spm_08_grass7_location_for_tests --location-type nc This will create a proper report from all tests in all testsuite directories inside the tree starting at lib/vector/. Find the report in testreport/index.html. Alternatively, execute just the script you want: cd lib/vector/testsuite/ sh -e -x test_topology_vgeneralize.sh Running directly would be possible but you want to set -e flag for failing on the first non-zero return status as it is done inside testing framework [3]. I was not really sure what it is testing some library things or the v.generalize debug feature itself. I though the former, so I put it to lib/vector. Please, move it somewhere else, if it tests something different. (Test suite directory should be in the directory with tested code.) As I said, shell script is not ideal because it will not work on MS Windows in GRASS GIS 7 unless you install it but it is at least something. Rewriting to Python would be better and actually not so difficult if only plain Python is used but this would still miss the advantages of the testing framework. Rewriting using gunittest is relatively simple too but I just don't have time to do that. Vaclav [1] http://trac.osgeo.org/grass/changeset/64269 [2] http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general [3] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/invoker.py?rev=62358#L148 The vectors in the sample datasets are too good, I did not find a vector to provoke any errors, thus the r.to.vect step. Real world datasets, particularly vectors with administrative areas or land cover/land use classification, are in this respect more suitable because they contain lots of topological errors. Unfortunately, these datasets are too large to be included in the sample datasets. Markus M Vaclav Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Wed, Jan 21, 2015 at 3:54 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Tue, Jan 20, 2015 at 5:08 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. Setting environmental variable should be easy in the test suite. I'm not sure about the v.generalize modification. Topology debugging tool sound's generally useful. Perhaps it could be part of v.generalize interface or a standalone module (build with v.generalize in the same way as r.colors and r3.colors are) but for tests it really doesn't matter. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. Let me know if you miss something in testing framework which would help you to write the tests. I would like to provide a command and the test suite must check the return status. If someone else could then turn this into a testsuite script, that would be great! Any .sh or .py script you put to testsuite directory anywhere in GRASS source code will be executed as test, so in your case, it should be enough just to put the command to .sh file together with the appropriate export command for the environmental variable. I'm afraid this feature is not really documented (except for emails) because I did it in last minute and it is not the best practice. Anyway, posting command is fine if the only thing needed is to check return status. For nc_spm_08, the test commands would be (as shell script): g.region -p rast=landuse96_28m@PERMANENT r.to.vect in=landuse96_28m@PERMANENT out=landuse96_28m type=area export GRASS_VECTOR_TOPO_DEBUG=1 # check return code of v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21 if [ $? -ne 0 ] ; then exit 1 fi Done in r64269 [1]. Thanks. To run, start GRASS and execute [2]: cd lib/vector/ python -m grass.gunittest.main --location my_nc_spm_08_grass7_location_for_tests --location-type nc This will create a proper report from all tests in all testsuite directories inside the tree starting at lib/vector/. Find the report in testreport/index.html. Alternatively, execute just the script you want: cd lib/vector/testsuite/ sh -e -x test_topology_vgeneralize.sh Running directly would be possible but you want to set -e flag for failing on the first non-zero return status as it is done inside testing framework [3]. I was not really sure what it is testing some library things or the v.generalize debug feature itself. I though the former, so I put it to lib/vector. Please, move it somewhere else, if it tests something different. (Test suite directory should be in the directory with tested code.) It tests some library things and just uses v.generalize to do modifications, thus putting it in lib/vector is fine. Markus M As I said, shell script is not ideal because it will not work on MS Windows in GRASS GIS 7 unless you install it but it is at least something. Rewriting to Python would be better and actually not so difficult if only plain Python is used but this would still miss the advantages of the testing framework. Rewriting using gunittest is relatively simple too but I just don't have time to do that. Vaclav [1] http://trac.osgeo.org/grass/changeset/64269 [2] http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general [3] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/invoker.py?rev=62358#L148 The vectors in the sample datasets are too good, I did not find a vector to provoke any errors, thus the r.to.vect step. Real world datasets, particularly vectors with administrative areas or land cover/land use classification, are in this respect more suitable because they contain lots of topological errors. Unfortunately, these datasets are too large to be included in the sample datasets. Markus M Vaclav Markus M
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Jan 19, 2015, at 1:13 PM, Vaclav Petras wrote: On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? There is one thing about this data set that I would like to change - the name of the location itself. Given that distribution of data by mapsets does not work well, all data sets should be distributed as locations (or external data) and then we won't need the loc part in the name. So I suggest to use the name ncspm_baseline_v1.0 or ncarolina_baseline_v1.0 instead of loc_ncspm_baseline and we should have a single place where this data set is stored (on grass website under data?) to avoid creating multiple versions of the data set. I will remove mine and replace it by a link. Then the italian version of this data set would be piemonte_baseline Naming, selection and placement into mapsets. Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Switching of mapset is not applicable in tests (tests are isolated using GRASS means, i.e. processes and mapsets) but yes, changing path is the way. Do you think we should add it to each example which needs it? For tests it would be quite easy to do something like set up the search path automatically according to existing mapsets or search path set in PERMANENT but it is desired? I don't have a strong opinion, explicit g.mapsets calls sounds as a safe way to go but putting @mapsetname everywhere would also work, am I right? I suggest to distribute all mapsets with at least the baseline data set in PERMANENT. Then you would have to deal with data in different mapsets (and in fact in different locations) only for the examples where you need to combine data from two or more different specialized mapsets - for example lidar and networks. Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. It's completely the same for me. I agree - we should retire all other small data sets and mark them as retired, although I expect that nc_spm_08 and nc_spm_08_grass7 will be still used for a while. I will post the relevant notes on my website and in our courses as well. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. Replacing the old one by a new one on my server should be quite simple because it is already there. Same if we decide to just use new NC instead of currently used full NC. Adding new location is what is very unpleasant to do now. I agree. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. If it is stable enough for trunk (i.e. it is worth to modify examples and tests) and it is clear how to access the maps in other mapsets then we just have to announce the official switch. Will this be the default dataset for 7.1 then? GRASS7.1 would be a good target. I am also working on a new external data set and on locations in other coordinate systems with some limited but hopefully meaningful map layers in them. Helena Vaclav Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? Naming, selection and placement into mapsets. Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Switching of mapset is not applicable in tests (tests are isolated using GRASS means, i.e. processes and mapsets) but yes, changing path is the way. Do you think we should add it to each example which needs it? For tests it would be quite easy to do something like set up the search path automatically according to existing mapsets or search path set in PERMANENT but it is desired? I don't have a strong opinion, explicit g.mapsets calls sounds as a safe way to go but putting @mapsetname everywhere would also work, am I right? Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. It's completely the same for me. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. Replacing the old one by a new one on my server should be quite simple because it is already there. Same if we decide to just use new NC instead of currently used full NC. Adding new location is what is very unpleasant to do now. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. If it is stable enough for trunk (i.e. it is worth to modify examples and tests) and it is clear how to access the maps in other mapsets then we just have to announce the official switch. Will this be the default dataset for 7.1 then? Vaclav Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras : On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz wrote: I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. This sounds pretty cool to have. Setting environmental variable should be easy in the test suite. I'm not sure about the v.generalize modification. Topology debugging tool sound's generally useful. Perhaps it could be part of v.generalize interface or a standalone module (build with v.generalize in the same way as r.colors and r3.colors are) but for tests it really doesn't matter. If that would be possible: perfect solution. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. Setting environmental variable should be easy in the test suite. I'm not sure about the v.generalize modification. Topology debugging tool sound's generally useful. Perhaps it could be part of v.generalize interface or a standalone module (build with v.generalize in the same way as r.colors and r3.colors are) but for tests it really doesn't matter. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. Let me know if you miss something in testing framework which would help you to write the tests. I would like to provide a command and the test suite must check the return status. If someone else could then turn this into a testsuite script, that would be great! Any .sh or .py script you put to testsuite directory anywhere in GRASS source code will be executed as test, so in your case, it should be enough just to put the command to .sh file together with the appropriate export command for the environmental variable. I'm afraid this feature is not really documented (except for emails) because I did it in last minute and it is not the best practice. Anyway, posting command is fine if the only thing needed is to check return status. Vaclav Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. I modified v.generalize in my local copy to become a topology debugging tool. The debugging tools could be activated with an environment variable which would need to be set by the test suite. If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? Let me know if you miss something in testing framework which would help you to write the tests. I would like to provide a command and the test suite must check the return status. If someone else could then turn this into a testsuite script, that would be great! Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Wed, Jan 14, 2015 at 9:57 PM, Markus Neteler nete...@osgeo.org wrote: Done! http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News Now time to announce it... Can we please get RC2 out soon? In the last days I have fixed numerous bugs in the vector library and changed/restored the basic vector IO interface, it is now more similar to G6 and it needed some code clean up. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-16 12:13 GMT+01:00 Markus Metz markus.metz.gisw...@gmail.com: Can we please get RC2 out soon? In the last days I have fixed numerous bugs in the vector library and changed/restored the basic vector IO interface, it is now more similar to G6 and it needed some code clean up. I agree, but would suggest to wait at least one/two week(s), probably more bugfixes will be collected. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 16 January 2015 at 12:15, Martin Landa landa.mar...@gmail.com wrote: Hi, Hi I agree, but would suggest to wait at least one/two week(s), probably more bugfixes will be collected. +1 Martin -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 16/01/15 12:15, Martin Landa wrote: Hi, 2015-01-16 12:13 GMT+01:00 Markus Metz markus.metz.gisw...@gmail.com: Can we please get RC2 out soon? In the last days I have fixed numerous bugs in the vector library and changed/restored the basic vector IO interface, it is now more similar to G6 and it needed some code clean up. Thanks for all this work ! Could you explain a bit more on what types of bugs this fixed ? I agree, but would suggest to wait at least one/two week(s), probably more bugfixes will be collected. As these seem to be modifications in fundamental library functions, I would plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for 1 week, not 2. That way these modifications will get a bit more testing before the final release. This is one example of why the proposed release procedure [1] contains this: Any backports during the soft freeze should be announced on the developers mailing list with 24 hours advance to allow possible discussion. Maybe this should be extended to Any backports or extensive bug fixes during... ? If these changes had been announced, we could have delayed RC1 for a few days... Moritz [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 16, 2015 at 1:27 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 16/01/15 12:15, Martin Landa wrote: Hi, 2015-01-16 12:13 GMT+01:00 Markus Metz markus.metz.gisw...@gmail.com: Can we please get RC2 out soon? In the last days I have fixed numerous bugs in the vector library and changed/restored the basic vector IO interface, it is now more similar to G6 and it needed some code clean up. Thanks for all this work ! Could you explain a bit more on what types of bugs this fixed ? The first set of bugs was related to vector topology. Bug 1 affected point-in-polygon tests, a basic geometry function. The affected functions were Vect_point_in_area(), Vect_point_in_area_outer_ring() and Vect_point_in_island() which returned sometimes the wrong result (point outside instead of inside or vice versa). This in turn affected the functions Vect_attach_centroids(), Vect_attach_isle() and Vect_attach_isles() which are needed to update topology when boundaries are added, deleted or modified. Bug 2 was in Vect_attach_centroids() andVect_attach_isles(). Centroids and isles were not properly reattached when boundaries are added, deleted or modified. These bugs still need to be fixed in G6. Bugs 1 + 2 meant that (re)attaching centroids and isles during vector modification was not working well, a fairly important feature for modifying vector topology. The modifications related to basic vector IO fixed some bugs introduced in G7. Some functions were only working with topology, even though equivalent functions not requiring topology are available. A newly introduced test prevented access to the non-topological variants. Further on, some function definitions were changed such that new arguments were introduced that were not used/not needed. I have syncronized the IO interface and updated the documentation. It is now more similar to G6 and some functions have become non-topological equivalents (interesting for large point clouds). I agree, but would suggest to wait at least one/two week(s), probably more bugfixes will be collected. As these seem to be modifications in fundamental library functions, I would plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for 1 week, not 2. That way these modifications will get a bit more testing before the final release. I would plead for 1 day rather than 1 week. This is one example of why the proposed release procedure [1] contains this: Any backports during the soft freeze should be announced on the developers mailing list with 24 hours advance to allow possible discussion. Maybe this should be extended to Any backports or extensive bug fixes during... ? If these changes had been announced, we could have delayed RC1 for a few days... I discovered the bugs only in the last days and tried to get them fixed as soon as possible, but some of the bugs were rather obscure and I had no idea how quickly I would be able to find their reason and fix them. The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Markus M Moritz [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
In view of Markus M explanation, +1 for RC2 today rather than tomorrow. On 16 January 2015 at 20:31, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Jan 16, 2015 at 1:27 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 16/01/15 12:15, Martin Landa wrote: Hi, 2015-01-16 12:13 GMT+01:00 Markus Metz markus.metz.gisw...@gmail.com: Can we please get RC2 out soon? In the last days I have fixed numerous bugs in the vector library and changed/restored the basic vector IO interface, it is now more similar to G6 and it needed some code clean up. Thanks for all this work ! Could you explain a bit more on what types of bugs this fixed ? The first set of bugs was related to vector topology. Bug 1 affected point-in-polygon tests, a basic geometry function. The affected functions were Vect_point_in_area(), Vect_point_in_area_outer_ring() and Vect_point_in_island() which returned sometimes the wrong result (point outside instead of inside or vice versa). This in turn affected the functions Vect_attach_centroids(), Vect_attach_isle() and Vect_attach_isles() which are needed to update topology when boundaries are added, deleted or modified. Bug 2 was in Vect_attach_centroids() andVect_attach_isles(). Centroids and isles were not properly reattached when boundaries are added, deleted or modified. These bugs still need to be fixed in G6. Bugs 1 + 2 meant that (re)attaching centroids and isles during vector modification was not working well, a fairly important feature for modifying vector topology. The modifications related to basic vector IO fixed some bugs introduced in G7. Some functions were only working with topology, even though equivalent functions not requiring topology are available. A newly introduced test prevented access to the non-topological variants. Further on, some function definitions were changed such that new arguments were introduced that were not used/not needed. I have syncronized the IO interface and updated the documentation. It is now more similar to G6 and some functions have become non-topological equivalents (interesting for large point clouds). I agree, but would suggest to wait at least one/two week(s), probably more bugfixes will be collected. As these seem to be modifications in fundamental library functions, I would plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for 1 week, not 2. That way these modifications will get a bit more testing before the final release. I would plead for 1 day rather than 1 week. This is one example of why the proposed release procedure [1] contains this: Any backports during the soft freeze should be announced on the developers mailing list with 24 hours advance to allow possible discussion. Maybe this should be extended to Any backports or extensive bug fixes during... ? If these changes had been announced, we could have delayed RC1 for a few days... I discovered the bugs only in the last days and tried to get them fixed as soon as possible, but some of the bugs were rather obscure and I had no idea how quickly I would be able to find their reason and fix them. The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Markus M Moritz [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-16 16:31 GMT+01:00 Yann Chemin yche...@gmail.com: In view of Markus M explanation, +1 for RC2 today rather than tomorrow. I don't see any reason why to hurry so much. Let's wait at least some days. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 16, 2015 at 12:59 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-01-16 16:31 GMT+01:00 Yann Chemin yche...@gmail.com: In view of Markus M explanation, +1 for RC2 today rather than tomorrow. I don't see any reason why to hurry so much. Let's wait at least some days. Martin I would like to have RC2 soon too, but let's wait until next week, we will be able to fix hopefully couple of other things until then. We should have clearer idea what will be after RC2? How long do we plan to test before release? I know it will depend on current situation, but still we should have a plan. Anna -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: The fixes are all thoroughly tested (I guess I have never before tested vector topology so thoroughly...). Hi Markus, will you be able to turn your tests into testsuite scripts? It is additional work but it gives us possibility to ensure that nobody will break what you did and it should save it your time in the long run. Let me know if you miss something in testing framework which would help you to write the tests. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Done! http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News Now time to announce it... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi Markus, 2015-01-14 21:10 GMT+01:00 Markus Neteler nete...@osgeo.org: ... tagging now RC1 perfect, thanks! Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
... tagging now RC1 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 2, 2015 at 10:22 PM, Markus Neteler nete...@osgeo.org wrote: Hi devs, proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing The RC1 release is due today :-) The planning list is looking good to me. And it is not the final but RC1 release. If there are no objections, I'll tag later today. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi Markus, 2015-01-14 9:29 GMT+01:00 Markus Neteler nete...@osgeo.org: The RC1 release is due today :-) The planning list is looking good to me. And it is not the final but RC1 release. If there are no objections, I'll tag later today. no objections here. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 14/01/15 09:29, Markus Neteler wrote: On Fri, Jan 2, 2015 at 10:22 PM, Markus Neteler nete...@osgeo.org wrote: Hi devs, proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing The RC1 release is due today :-) The planning list is looking good to me. And it is not the final but RC1 release. If there are no objections, I'll tag later today. Go for it ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
+1 Markus ! On 14 January 2015 at 14:19, Moritz Lennert mlenn...@club.worldonline.be wrote: On 14/01/15 09:29, Markus Neteler wrote: On Fri, Jan 2, 2015 at 10:22 PM, Markus Neteler nete...@osgeo.org wrote: Hi devs, proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing The RC1 release is due today :-) The planning list is looking good to me. And it is not the final but RC1 release. If there are no objections, I'll tag later today. Go for it ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Tue, Jan 13, 2015 at 10:20 AM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 12, 2015 at 3:20 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: ... - v.select: various differences code optimization, no bug fix Just to understand: yet not tested enough to be backported? Optimizations are not high on my priority list of backports. You tested v.select yourself: the GRASS-internal overlap operator vs. the GEOS overlaps operator of v.select, in order to select tile coverage from buffered linear features. The GRASS-internal overlap operator is more accurate, and processing is faster (after optimization). Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 12, 2015 at 3:20 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: ... - v.select: various differences code optimization, no bug fix Just to understand: yet not tested enough to be backported? markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler nete...@osgeo.org wrote: Hi devs, http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing ...the TODO list got much shorter! Relevant differences - to be clarified: [...] * checks for Vect_open_* return value to avoid potential segmentation fault: r60054 -- wasn't the idea to avoid these ugly tests in G7? The Vect_open_* return the open level when opening existing maps, not just success or failure. Some modules, most importantly v.info, try to open a map first with topology, if that fails, without topology. Therefore it is up to the modules to decide if the return code is ok or not. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 12, 2015 at 1:38 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler nete...@osgeo.org wrote: ... * checks for Vect_open_* return value to avoid potential segmentation fault: r60054 -- wasn't the idea to avoid these ugly tests in G7? The Vect_open_* return the open level when opening existing maps, not just success or failure. Some modules, most importantly v.info, try to open a map first with topology, if that fails, without topology. Therefore it is up to the modules to decide if the return code is ok or not. ok, backported in r64075. Also backported v.to.rast: (replace custom cell type with raster cell type; use size_t) and a few other things. Actual state: http://trac.osgeo.org/grass/wiki/Grass7Planning To be clarified: - v.distance: geodesic support backported in r64094,5 - v.kernel: Vect_net_shortest_path_coor2() usage The API changed in G 7.1 because of new turntable support in network analysis. - v.out.ascii: return test in vector/v.out.ascii/main.c backported in r64096 - v.select: various differences code optimization, no bug fix Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Jan 10, 2015 at 11:50 AM, Markus Neteler nete...@osgeo.org wrote: ... * checks for Vect_open_* return value to avoid potential segmentation fault: r60054 -- wasn't the idea to avoid these ugly tests in G7? The Vect_open_* return the open level when opening existing maps, not just success or failure. Some modules, most importantly v.info, try to open a map first with topology, if that fails, without topology. Therefore it is up to the modules to decide if the return code is ok or not. ok, backported in r64075. Also backported v.to.rast: (replace custom cell type with raster cell type; use size_t) and a few other things. Actual state: http://trac.osgeo.org/grass/wiki/Grass7Planning To be clarified: - v.distance: geodesic support - v.kernel: Vect_net_shortest_path_coor2() usage - v.out.ascii: return test in vector/v.out.ascii/main.c - v.select: various differences ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi devs, http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing ...the TODO list got much shorter! Relevant differences - to be clarified: * lib/db/dbmi_base/connect.c * lib/gis/strings.c G_chop() (Markus Metz) r63308 * Change handling of display frame, graphical clip window (Glynn) (r62026 + r62036) * lib/python/script/core.py (martinl) r63528 * db.connect substitute variables for database name (-cpd) (martinl) r59671 * r.spread (Vaclav) r63777 * checks for Vect_open_* return value to avoid potential segmentation fault: r60054 -- wasn't the idea to avoid these ugly tests in G7? Please check those, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sat, Jan 10, 2015 at 5:50 AM, Markus Neteler nete...@osgeo.org wrote: * r.spread (Vaclav) r63777 I backported this one before the original RC1 release date. I don't know how it got to wiki, cleaned now. Now I backported also r60922 which is probably a feature but since it is in trunk for some time and won't be probably tested better, I just backported it. Vaclav [1] http://trac.osgeo.org/grass/changeset/63777 [2] http://trac.osgeo.org/grass/changeset/63820 [3] http://trac.osgeo.org/grass/changeset/60922 [4] http://trac.osgeo.org/grass/changeset/63820 [5] http://lists.osgeo.org/pipermail/grass-dev/2015-January/072736.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi devs, I have now also completed the lib/ tree comparison, done the obvious backports and identified some differences where I cannot say if to backport or not: Kindly extracted with revision numbers...: http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Please check! (strike there what's done) The 14 Jan 2015 is getting close. thanks, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-03 9:49 GMT+01:00 Martin Landa landa.mar...@gmail.com: 2015-01-02 22:22 GMT+01:00 Markus Neteler nete...@osgeo.org: proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. I agree. Let's focus on this date. Martin time is running, I would like to kindly ask if there is any progress in open issues? I can do backport if you confirms which are OK. Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Jan 6, 2015 11:12 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-03 9:49 GMT+01:00 Martin Landa landa.mar...@gmail.com: 2015-01-02 22:22 GMT+01:00 Markus Neteler nete...@osgeo.org: proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. I agree. Let's focus on this date. Martin time is running, I would like to kindly ask if there is any progress in open issues? I can do backport if you confirms which are OK. Huidae answered yesterday to me. I have added them to the trac page with rev numbers. For the others no answer yet. Thanks Markus Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On 06/01/15 11:12, Martin Landa wrote: Hi, 2015-01-03 9:49 GMT+01:00 Martin Landa landa.mar...@gmail.com: 2015-01-02 22:22 GMT+01:00 Markus Neteler nete...@osgeo.org: proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. I agree. Let's focus on this date. Martin time is running, I would like to kindly ask if there is any progress in open issues? I can do backport if you confirms which are OK. Sorry, no progress on my side, but a new issue I stumbled upon yesterday: https://trac.osgeo.org/grass/ticket/2533. Can anyone confirm this ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
HI, 2015-01-02 22:22 GMT+01:00 Markus Neteler nete...@osgeo.org: proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. I agree. Let's focus on this date. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 2, 2015 at 6:30 AM, Martin Landa landa.mar...@gmail.com wrote: 2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - r.spread (Vaclav) I put these notes to trac [1], please mark by ~~ when solved. The wiki page is saying r63777 [1] which I backported 4 days ago in hurry [2] because I was afraid that RC1 will be actually released, so I was not reporting it. There is also r60922 which is extending interface by -i flag which enables a new feature, copying values from seed map into the output map. I could backport it, it would be actually advantageous for me to have it in 70, but it is adding a new feature and I'm afraid I'm the only one who tested that. [1] http://trac.osgeo.org/grass/changeset/63777 [2] http://trac.osgeo.org/grass/changeset/63820 [3] http://trac.osgeo.org/grass/changeset/60922 [1] http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: Furthermore, many vector/ modules show unbackported differences -- I cannot judge them. In display/ are also a series of differences but Martin is working on that. Then: misc/ + ps/ + raster/ + imagery/ + raster3d/ + scripts/ + temporal/ I have checked. There are only these relevant differences: - r.distance (Huidae) - r.proj bugfixes (Markus Metz) - r.spread (Vaclav) - new r3 modules by Anna (perhaps yet experimental) In general/ there are differences in - g.rename (Huidae) - manage/lister (Huidae) I put these notes to trac [1], please mark by ~~ when solved. Thanks, Martin [1] http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-02 11:44 GMT+01:00 Markus Neteler nete...@osgeo.org: In this light I would suggest to move v.convert to addons and remove 'old_vector' from element list. Any objections? Makes sense. If users want to upgrade from GRASS 5 directly to GRASS 7, it will be fine to install an Addon. Those bulk upgrading from GRASS 6 can use this built-in procedure: http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7 So: yes. done in trunk as r63930. If no objection I will do backport to relbr7 in few days (before RC1) and then move v.convert to addons. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 2, 2015 at 9:40 AM, Martin Landa landa.mar...@gmail.com wrote: ... In this light I would suggest to move v.convert to addons and remove 'old_vector' from element list. Any objections? Makes sense. If users want to upgrade from GRASS 5 directly to GRASS 7, it will be fine to install an Addon. Those bulk upgrading from GRASS 6 can use this built-in procedure: http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7 So: yes. my 0.02, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: Also the wxGUI differences I'll leave to the experts :-) I would not backport the new and still experimental features like data catalog. Generally speaking I would leave wxGUI as it is. After RC1 only bugfixes. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/ascii.c its [1,2] - I would leave decision to Markus Metz. Martin [1] http://trac.osgeo.org/grass/changeset/63596/grass/trunk/lib/vector/Vlib/ascii.c [2] http://trac.osgeo.org/grass/changeset/63599/grass/trunk/lib/vector/Vlib/ascii.c -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: Additionally, I found the deactivated grass70/vector/v.in.sites/ remove or move to Addons? I removed this module (it was already done in trunk in r62179). To convert sites to GRASS 7 you need to use GRASS 6. In this light I would suggest to move v.convert to addons and remove 'old_vector' from element list. Any objections? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Fri, Jan 2, 2015 at 6:25 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: Also the wxGUI differences I'll leave to the experts :-) I would not backport the new and still experimental features like data catalog. Generally speaking I would leave wxGUI as it is. After RC1 only bugfixes. Any idea about the difference in gcmd.py in trunk, it's something about Windows shell escaping? I don't know how to try it out, to understand if we want it or not. http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/gcmd.py#L163 Anna. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/snap.c new kdtree implementation by MarkusM [1,2,3]. Probably new feature for GRASS 7.1 (do not backport) ? Martin [1] http://trac.osgeo.org/grass/changeset/63601/grass/trunk/lib/vector/Vlib/snap.c [2] http://trac.osgeo.org/grass/changeset/63645/grass/trunk/lib/vector/Vlib/snap.c [3] http://trac.osgeo.org/grass/changeset/63918/grass/trunk/lib/vector/Vlib/snap.c -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: On Wed, Dec 31, 2014 at 5:33 PM, Markus Neteler nete...@osgeo.org wrote: - lib/vector/Vlib/build.c it's [1], decision should be ideally done by MarkusM. Martin [1] http://trac.osgeo.org/grass/changeset/61492/grass/trunk/lib/vector/Vlib/build.c -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/remove_areas.c it's [1], should be ideally decided by MarkusM. Martin [1] http://trac.osgeo.org/grass/changeset/61491/grass/trunk/lib/vector/Vlib/remove_areas.c -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/line.c it's [1], MarkusM. Martin [1] http://trac.osgeo.org/grass/changeset/61978/grass/trunk/lib/vector/Vlib/line.c -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/read_pg.c done in r63933. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
2015-01-01 23:55 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/map.c solved in r63932. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi devs, proposal for new RC1 release date: 14 Jan 2015. Let's please manage to keep that date if you agree. http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2014-12-31 17:33 GMT+01:00 Markus Neteler nete...@osgeo.org: - lib/vector/Vlib/net_analyze.c - lib/vector/Vlib/net_build.c I would say, do not backport. It's related to quite new support for turns in vector networks [1]. I would say new feature in GRASS 7.1/7.2. Martin [1] http://grasswiki.osgeo.org/wiki/Turns_in_the_vector_network_analysis -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, 2014-12-31 17:33 GMT+01:00 Markus Neteler nete...@osgeo.org: Not sure what's experimental and what's a forgotten bugfix backports? I would also add http://trac.osgeo.org/grass/ticket/2522 Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, due to incomplete backports (or statements that they should not be done), RC1 is slightly postponed. I see notable differences here: - lib/vector/Vlib/ascii.c - lib/vector/Vlib/build.c - lib/vector/Vlib/line.c - lib/vector/Vlib/map.c - lib/vector/Vlib/read_pg.c - lib/vector/Vlib/remove_areas.c - lib/vector/Vlib/snap.c - lib/vector/Vlib/write_nat.c # not present in relbr7: - lib/vector/Vlib/intersect2.c - lib/vector/Vlib/net_analyze.c - lib/vector/Vlib/net_build.c Not sure what's experimental and what's a forgotten bugfix backports? New, to be further updated: http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
Hi, since the 29th is approaching quickly, please consider to check relbr7 for missing backports. I'm unable to judge them myself. thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
