[GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Markus Metz]

On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
>
> On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz <markus.metz.giswork at gmail.com>
> wrote:
>>
>> On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras <wenzeslaus at gmail.com>
>> wrote:
>> > On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz
>> > <markus.metz.giswork at 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 at PERMANENT
r.to.vect in=landuse96_28m at 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
>
>