[GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Helena Mitasova]

On Jan 19, 2015, at 1:13 PM, Vaclav Petras wrote:

> On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler <neteler at osgeo.org> wrote:
> On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> > On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler <neteler at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev