On Sat, Jan 17, 2015 at 10:21 PM, Vaclav Petras <[email protected]> wrote: > > > On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz <[email protected]> > wrote: >> >> On Fri, Jan 16, 2015 at 11:25 PM, Vaclav Petras <[email protected]> >> wrote: >> > On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz >> > <[email protected]> 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 [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
