Re: [GRASS-dev] G7: turning manual page examples into test cases

[Vaclav Petras]

Hi,

I've created a Python script which extracts code from HTML file and puts it
to a Bash script. It works well for our course websites but even with some
fixes it does not work for GRASS HTML manual pages. It might work well for
some modules, so you can try (both attached). Now, I have the following
ideas in case you want to dive into it on your own.

The script should be turned into library function and generalized to work
with different HTML-styles or even different markups (I think that
something like template method design pattern should work).

However, it is necessary to distinguish code from other things in the HTML.
We should look at HTML5 at that point to make the change right once we are
doing it. Basically we need to make the HTML more semantic. Perhaps some
additional classes or attributes will be also needed to mark code which
should not be executed.

Taking this idea further, we might have different languages at the page
such as Bash, Python and some platform-neutral command line. Pretty much
(visually) what we have here:

http://fatra.cnr.ncsu.edu/temporal-grass-workshop/

This would also help with solving the issue of running Bash/Shell on MS
Windows where just the Python and platform-neutral code would be executed
(which is better than nothing). Soeren's shell interpreter (or
shell-to-python translator, http://grasswiki.osgeo.org/wiki/Test_Suite) is
of course always an option if Bash will have to by used everywhere for lack
of other tests and examples. But even this requires keeping some rules for
writing examples, consider the following diff for example ("make bash
command copy-paste-able to command line"):

--- vector/v.net/v.net.html(revision 63739)
+++ vector/v.net/v.net.html(working copy)
@@ -170,10 +170,10 @@
 
 v.net points=geodetic_swwake_pts output=geodetic_swwake_pts_net \
   operation=arcs file=- << EOF
-> 1 28000 28005
-> 2 27945 27958
-> 3 27886 27897
-> EOF
+1 28000 28005
+2 27945 27958
+3 27886 27897
+EOF
 

Currently it seems to me that the way to go is running the tests generated
from documentation only when requested. Requested in this case means
writing a test file which would use some special API which would generate
and execute the documentation-based test. This is the way how it works for
Python doctest, too. The implementation would be on-the-fly genered bash
script executed from the Python test. Alternative is each example turned
into one test method but this wouldn't work because the order of method
execution is not preserved (by Python unittest). So, one HTML file must be
one bash script.

The approach above allows module-specific filtering of examples to test and
clear integration of this tests into module's testsuite. The obvious
disadvantaged of course is that one has to provide all the test files for
each module but the alternative would actually be large number of failing
tests due to strange (not necessarily wrong) documentation and a lot of
failing tests by default is always wrong.

The approach with manual addition of tests has actually one great feature.
Test can specify which maps should be checked against which references
which can be provided (and checked) in the same way as for all the other
scripts.

As this would not work for all modules unless explicitly requested, there
is still some place for some kind of monkey testing which would be based
just on the interface of the module. However, I would prefer not to have
these tests which might be failing by default together with the standard
hand-written tests. Anyway, there sometimes the number of errors might be
lowered by just requesting the modules to fail properly with an error
message (rather than segfaulting). Another interesting approach is to
define the interface of modules so well that the test data can be generated
in the way which in fact fulfills all the advanced requirements the module
can have (e.g. raster values in range 0-255. This of course goes far into
data provenance and software metadata topics.

Vaclav
#!/usr/bin/python

# author: Vaclav Petras
# license: GNU GPL >=2

"""

Create a new testing directory::

mkdir test_documentation
cd  test_documentation

Create a simlink to the data directory::

ln -s ../mea582/grass/data data

Generate the test script::

./doc2tests.py < .../terrain_analysis.html > test_terrain_analysis.sh
chmod u+x test_terrain_analysis.sh

In GRASS GIS session::

./test_terrain_analysis.sh

Do the cleanup using something like::

d.mon stop=cairo
rm *png
g.remove type=raster,vector patter=* -f
"""

import sys
import re
import fileinput

code_start = re.compile(r'')
code_end = re.compile(r'')
code_start = re.compile(r'')
code_end = re.compile(r'')

html_comment_start = re.compile(r'\s*')

in_code = False
in_html_comment = False
in_code = False

ignored_lines = [
re.compile(r'grass70'),
#re.compile(r'\s*d\.mon'),
#re.compile(r'\s*d\.out.file'),
]

valid_code_lines = [
re.compile(r'^[a-z][a-z0-9]?\.[a

Re: [GRASS-dev] testsuite error messages analysed: some issues remaining

[Vaclav Petras]

On Sat, Dec 20, 2014 at 12:20 PM, Markus Neteler  wrote:

> Hi devs,
>
> I spent some time today to check all failing test in the test suite:
> http://fatra.cnr.ncsu.edu/grassgistests/summary_report/index.html
>
>
>  NO IDEA problem
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/raster/r.profile/test_profile_ncspm/index.html
> --> I don't know that the issue is
>
> No idea here neither.

>
> ## JUNK REMAINED issue:
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/raster/r.in.poly/test_rinpoly/index.html
> --> ERROR: option :  exists.
>
> Some overwrite flag needed?
>
> overwrite flag should not be used with the tests.

Currently the test should try to clean up after itself using standard
means. This is advantageous in case of running in the user's current
mapset. This might be somehow changes in the future, e.g. some API
introduced, but generally we probably will not get rid of it.

In case of automatic running of all tests, each test file has it's own
mapset which is deleted afterwards, so no junk should remain.

This is might caused by two different test methods or test case classes
using the maps with the same names. This should be avoided.


> But when I run it locally here:
>
> Traceback (most recent call last):
>   File "raster/r.in.poly/testsuite/test_rinpoly.py", line 107, in
> testLabels
> msg="Labels do not match")
> AssertionError: Labels do not match
> '-8\t\n3\tlabel2\n10.01\tlabel1' != '-8\t\n3\tlabel2\n10.01'
>
> The order of test execution is not defined (in test file driven by Python
unittest) and can be different each time. Test methods should not depend on
each other.

>
> ## MISSING MAPS problems (in the piemonte location the names
> differ, so they should be locally renamed):
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_geometry/index.html
> --> "roadmajor" does not exist in the server dataset
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_vector/index.html
> --> OpenError: Map  not found.
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_doctests/index.html
> --> WARNING:  not found
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/vector/v.what/test_vwhat_ncspm/index.html
> --> ERROR: Vector map  not found
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/raster/r.profile/test_profile_ncspm/index.html
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/raster/r.slope.aspect/test_r_slope_aspect/index.html
> --> ERROR: Raster map  not found
>
>
I'm afraid, I don't want to maintain my own version of the dataset, so I
will wait for the official one or at least the official table for renaming.

## MISSING MAPS problems NC dataset:
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/vector/test_vector/index.html
> --> OpenError: Map  not found.
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/vector/test_doctests/index.html
> --> WARNING:  not found
>
> Unfortunately, same as above and the following is blocker for this:

http://lists.osgeo.org/pipermail/grass-dev/2014-December/072600.html
http://osgeo-org.1560.x6.nabble.com/Heading-towards-unified-dataset-td5165053.html
http://comments.gmane.org/gmane.comp.gis.grass.devel/60326

### DESIGN wish:
>
> Each test page contains a title like this:
> ./vector/v.what – test_vwhat_layers
>
> Could please the path to the file be added as
> Testsuite: vector/v.what/testsuite/test_vwhat_layers.py
>
> for easy copy-pasting in the local computer? Would be more joy for
> fixing tests... thanks.
>
> I'm all for joy. Done in r63795 in a messy way for now. It is part of the
table at the beginning. However, note that you are also interested in the
files in the tested directory and it would be more challenging to add
these. Another ideas are links to Trac tickets, revisions or files.

Create tickets if you have some concrete ideas and feel free to discuss the
incomplete ones. However, I cannot promise I can work on that but perhaps
somebody else could.

Vaclav

http://trac.osgeo.org/grass/changeset/63795


> All fixes I have backported as well.
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2514: G_OPT_C_BG and G_OPT_C_FG differ in support of color_none

[GRASS GIS]

#2514: G_OPT_C_BG and G_OPT_C_FG differ in support of color_none
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  color, standard options  |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:2514 annakrat]:
 > > In the attempt to standardize options for fg and bg colors, we ignored
 the gisprompt where some commands have `old,color,color` and some
 `old,color_none,color`. So this for example results in d.vect gui dialog
 not supporting transparent feature color, because G_OPT_C_FG doesn't use
 `color_none`.
 > >
 > > Beside the gisprompt, also the description must be different. Should
 we have 4 versions of color standard options? Something like G_OPT_C_BG,
 G_OPT_C_FG, G_OPT_CN_BG, G_OPT_CN_FG?
 >
 > Too many just slightly different standard options contradict the idea of
 having standard options. You can not make every possible occurrence of an
 option a standard option. Standard options can be easily modified by
 modules to meet their needs. Therefore I would opt to drop G_OPT_C_FG and
 G_OPT_C_BG, and have instead G_OPT_C for `old,color,color` and G_OPT_CN
 for `old,color_none,color`. That would also fix the wrong description for
 G_OPT_C_FG.

 That makes sense, committed in r63797.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Continuing in what I wrote in comment:17 and following ones changed
 G7:r.rgb in the way that fixed number of outputs handled by basename was
 replaced by specific options. This is not only more explicit but also fits
 more to the context when same rasters are used as input and in case of
 `r.rgb` allows to request only some outputs.

 Old `r.rgb`:

 {{{
 Usage:
  r.rgb input=name [output=basename] [--overwrite] [--help] [--verbose]
[--quiet] [--ui]

 Parameters:
input   Name of input raster map
   output   Name of output basename raster map(s)
 Default: input
 }}}

 New `r.rgb`:

 {{{
 Usage:
  r.rgb input=name red=name green=name blue=name [--overwrite]
[--help] [--verbose] [--quiet] [--ui]

 Parameters:
   input   Name of input raster map
 red   Red channel raster map name
   green   Green channel raster map name
blue   Blue channel raster map name
 }}}

 If somebody would like to learn how to write a test, this is a great
 opportunity. On might do something like:

 {{{
 r.composite r=lsat7_2002_10 g=lsat7_2002_30 b=lsat7_2002_50 o=lsat_comp
 r.rgb i=lsat_comp r=lsat7_2002_10 g=lsat7_2002_30 b=lsat7_2002_50
 }}}

 And then test difference of old and new maps. The results might not be
 identical but should be close to each other. Another tests can check if
 only one map is created when one map is requested.

 I cannot work on this more but similar change as I did for `r.rgb` could
 be done for G7:r.blend too. It also has an `output` option which is a
 "basename for red, green and blue output raster maps".

 There are some other modules I'm not completely sure about such as
 G7:i.pansharpen and G7:i.topo.corr.

 Some other seems that they don't need this change (e.g., G7:i.pca,
 G7:i.landsat.toar, G7:i.landsat.acca, and G7:i.tasscap) because the number
 of outputs is variable. However, I'm not sure how the suffixes are
 generated, sometimes it seems that they are even expected on the input.
 Standard basename separator (underscore, #2136) should be used in all
 cases otherwise it is not really standard, now many of them are probably
 using dot.

 Last issue I know about is G7:r.texture where the number of outputs
 depends on number of requested textures. G7:r.neighbors actually solves
 this issue by using output not as a basename but as multiple and
 requesting as many outputs as requested methods.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Replying to [comment:180 glynn]:
 > Replying to [comment:178 wenzeslaus]:
 >
 > > > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
 anything) and the found string isn't an exact match for the given string.
 > >
 > > Thanks that's good but wouldn't be better to do just the `strcmp`
 comparison (to be faster) and fail (with fatal error) which would show
 these things in tests (errors are clearly visible, warning must be
 searched for in the output). I think the primary use-case for
 `GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
 options and then it is just more effective to fail. The secondary use-
 case, I can think of, is making parsing faster which is only possible if
 this check is alternative, not addition. Do you have different opinion?
 (This is not necessary to decide before the release I belief because it is
 not real API considering the use-cases.)
 >
 > I just took the simplest route for now. I don't consider performance
 issues at this scale to be relevant.

 I was hitting some issues when I was calling some modules to do simple
 task many time, so I'm looking for ways how to decrease the cost of new
 processes but I don't have any benchmark for the option parsing.

 > Changing the G_warning() to G_fatal_error() would be trivial, if that's
 desired.

 Not sure about the others but it makes sense to me to switch to
 `G_fatal_error()`.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r63785 - in grass-addons/grass7: general/g.compare.md5 general/g.isis3mt general/g.proj.all raster/r.mcda.ahp raster/r.shalstab

[Vaclav Petras]

On Sat, Dec 27, 2014 at 5:49 PM,  wrote:

> -#% keywords: general, projection, transformation
> +#% keywords: general
> +#% keywords: projection
> +#% keywords: transformation
>

Shouldn't the name of the key be "keyword" rather than "keywords" since
only one is allowed? Or it is too heavy change?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Heading towards unified dataset

[Vaclav Petras]

To better coordinate creation of the new sample dataset, I created a page
on GRASS Trac wiki:

http://trac.osgeo.org/grass/wiki/SampleDataset

I invite all to join the effort.

Please see also the discussions about the sample spatio-temporal data:

http://lists.osgeo.org/pipermail/grass-dev/2014-October/071114.html
http://osgeo-org.1560.x6.nabble.com/sample-vector-temporal-data-td5166407.html
http://comments.gmane.org/gmane.comp.gis.grass.devel/60441

http://lists.osgeo.org/pipermail/grass-dev/2014-May/068601.html
http://osgeo-org.1560.x6.nabble.com/sample-dataset-for-temporal-data-td5137870.html

On Tue, Sep 30, 2014 at 2:18 PM, Vaclav Petras  wrote:

> Hi,
>
> at FOSS4G we were talking about the need of unified dataset, a GRASS
> location in our GRASS case, to enable easy writing of examples and also
> tests.
>
> The location would have maps with unified names such as "elevation" and
> these names can be used in the examples and tests so that both examples and
> tests can, to certain extent, work in different locations. For examples in
> manual pages or other educational material, this would mean that it could
> be used better across more countries or areas. For tests, this would mean
> that different projection or data can be tested with the algorithms.
>
> This has of course its limits, for example the result of statistical
> analysis would be different in different locations but the point is that
> the analysis can be done.
>
> We already have NC (full) location and NC basic location. They have these
> raster maps in common:
>
> elevation
> elevation_shade
> lakes
>
> These maps are in NC basic:
>
> basins
> geology
> landuse
> soils
>
> But in full NC they have different names:
>
> basin_50K
> geology_30m
> landuse96_28m
> soilsID
>
> Of course the longer names have their reasoning in differences with
> similar raster maps in the same location but I would say that having
> unified names is more advantageous for teaching/test datasets then absolute
> clearness of names. This should be in metadata anyway.
>
> One can also argue about the unified names themselves (e.g. elevation vs
> dtm or usage of underscore) but most of it is pretty clear since it has to
> be the most general names possible.
>
> The names must be obviously in English. If somebody would like to have
> data in different language, derived dataset must be created. Perhaps it
> would be possible to provide some batch version of g.rename (but there are
> also attribute columns and others).
>
> The last issue might be what if there is nothing in the area which can be
> part of the map or if dam or pond are lakes. But we can allow for some
> inaccuracies when creating a training dataset.
>
> The other locations which can be unified are Piemonte and Spearfish.
>
> So, what are the next steps? Decide about which maps to include and which
> names to use? Let's start from the NC basic location.
>
> Raster maps
>
> basins
> elevation
> elevation_shade
> geology
> lakes
> landuse
> soils
>
> I'm not sure if geology and soils would be available in other locations,
> so we could leave out them. However, they are available for Spearfish and
> maybe for Piemonte (my Italian is not really usable).
>
> Vector maps
>
> boundary_region
> boundary_state
> census
> elev_points
> firestations
> geology
> geonames
> hospitals
> points_of_interest
> railroads
> roadsmajor
> schools
> streams
> streets
> zipcodes
>
> We would need to have at at least one map for each type. I'm not sure what
> are the crucial ones and broadly available but it seems that training
> datasets are usually near some civilization, so roads or schools might be
> available. Buildings would be nice to have.
>
> Attribute data, time series and 3D rasters and (real) 3D vectors are of
> course whole new level. So, I would start with rasters and (mostly 2D)
> vectors.
>
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2457: DBF driver: stub functions for SQL TRANSACTION

[GRASS GIS]

#2457: DBF driver: stub functions for SQL TRANSACTION
---+
  Reporter:  neteler   |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  normal|   Milestone:  6.4.5
 Component:  Database  | Version:  svn-releasebranch64  
Resolution:  wontfix   |Keywords:  dbf, sql 
  Platform:  All   | Cpu:  Unspecified  
---+
Changes (by neteler):

  * status:  new => closed
  * resolution:  => wontfix


Comment:

 The last comment did not belong here but to the list.

 Since adding SQL TRANSACTIONs to the DBF driver appears to be too
 complicated and essentially useless, I take liberty to close my own ticket
 as wontfix. Thanks for the support, though.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2457: DBF driver: stub functions for SQL TRANSACTION

[GRASS GIS]

#2457: DBF driver: stub functions for SQL TRANSACTION
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Database | Version:  svn-releasebranch64  
 Keywords:  dbf, sql |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Instead of trying to add SQL TRANSACTIONS to the DBF driver, I have now
 simply conditionalized it in r63789. This will go into a future GRASS GIS
 6.4.5.

 Please try the updated script from here:
 
https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/scripts/v.rast.stats/v.rast.stats

 Thanks for reporting it. The ticket may be closed if the updated script
 works ok for you.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G7: v.mkhexgrid addon for hexagon creation

[Markus Neteler]

On Thu, Nov 20, 2014 at 10:31 AM, Markus Neteler  wrote:
> On Thu, Nov 20, 2014 at 9:52 AM, Markus Metz
>  wrote:
> ...
>> The points are not "cleverly spaced". Attached is a python script that
>> generates center points of hexagons. The output of v.voronoi shows now
>> hexagons.
>
> Cool! Do you have a reference for ""cleverly spaced"? Just came across
> http://en.wikipedia.org/wiki/Hexagonal_lattice
> http://en.wikipedia.org/wiki/Hexagonal_tiling
>
> Overall, this point generator might be a nice extension to v.mkgrid.

For the record: Markus Metz kindly implemented hexagons in v.mkgrid (thanks!)

http://grass.osgeo.org/grass70/manuals/v.mkgrid.html
-h Create hexagons (default: rectangles)

(an example with screenshot will be online in 1-2hs from now, the
manual is building again at time)

markusN

PS: I removed the G7 Addon since no longer needed. And v.mkgrid is WAY faster...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

[Markus Neteler]

On Sat, Dec 20, 2014 at 5:49 PM, Helmut Kudrnovsky  wrote:
> Markus Neteler wrote
>>>
>>> Works.
>>
>> Submitted to trunk in r63238. Please test (tomorrow) also on Windows
>> if possible (the name will be something like libsqlitefunctions.dll
>> which you need to provide to v.db.select).
>
> any idea where to find/to get libsqlitefunctions.dll for testing?

Some folks suggest to compile it (one-liner):
http://stackoverflow.com/a/20984485/452464

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2505: v.build.polylines options aren't working

[GRASS GIS]

#2505: v.build.polylines options aren't working
---+
 Reporter:  hellik |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  7.0.0
Component:  Vector | Version:  svn-releasebranch70  
 Keywords:  v.build.polylines  |Platform:  All  
  Cpu:  Unspecified|  
---+

Comment(by hellik):

 Replying to [comment:3 hellik]:
 > Replying to [comment:2 neteler]:
 >
 > > Is this ticket solved?
 >
 > downgrading priority; closing ticket when manual is extended.

 some notes added to manual: r63781 (trunk), r63782 (relbranch7)

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:178 wenzeslaus]:

 > > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
 anything) and the found string isn't an exact match for the given string.
 >
 > Thanks that's good but wouldn't be better to do just the `strcmp`
 comparison (to be faster) and fail (with fatal error) which would show
 these things in tests (errors are clearly visible, warning must be
 searched for in the output). I think the primary use-case for
 `GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
 options and then it is just more effective to fail. The secondary use-
 case, I can think of, is making parsing faster which is only possible if
 this check is alternative, not addition. Do you have different opinion?
 (This is not necessary to decide before the release I belief because it is
 not real API considering the use-cases.)

 I just took the simplest route for now. I don't consider performance
 issues at this scale to be relevant.

 Changing the G_warning() to G_fatal_error() would be trivial, if that's
 desired.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] reStructuredText description of a module interface

[Vaclav Petras]

On Thu, Dec 25, 2014 at 1:17 PM, Martin Landa 
wrote:

> Hi,
>
> 2014-12-22 4:06 GMT+01:00 Vaclav Petras :
> > would suggest to change --rest-description to --rst-description. "rst"
> is a
> > suffix commonly used for reStructuredText files (used also in GRASS GIS).
> > Anybody against the change?
>
> not all, I would highly agree with this change. Martin
>
> Implemented in r63780 but just the rename. Unfortunately, I cannot replace
all occurrences of "rest" (as in reStructuredText) in the source code now.

Anyway, we should get back to this topic. There is a lot of code
related to reStructuredText
in GRASS and it might be quite useful for different things.

http://trac.osgeo.org/grass/changeset/63780


> --
> 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] [GRASS GIS] #2283: wingrass: failure when loading addons

[GRASS GIS]

#2283: wingrass: failure when loading addons
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Addons| Version:  svn-trunk
 Keywords:  wingrass, launch  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by hellik):

 Replying to [comment:5 hellik]:
 > Replying to [comment:1 wenzeslaus]:
 > > Can you please elaborate more on how the addons are handled and what
 actually went wrong? I tis not clear to me if this is something which
 happens all the time or just when there is error in the source code.
 >
 [...]
 > the error message should contain something like: "you are trying to use
 an addon built upon an another/older version of winGRASS; please update
 your addon by reinstalling".

 I've seen that in C:\Users\x\AppData\Roaming\GRASS7\addons\modules.xml
 there is following entry:

 {{{
 
 }}}

 using this information for a wxGUI-startup message which indicates to a
 needed addon update?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2283: wingrass: failure when loading addons

[GRASS GIS]

#2283: wingrass: failure when loading addons
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Addons| Version:  svn-trunk
 Keywords:  wingrass, launch  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by hellik):

 Replying to [comment:1 wenzeslaus]:
 > Can you please elaborate more on how the addons are handled and what
 actually went wrong? I tis not clear to me if this is something which
 happens all the time or just when there is error in the source code.

 the failure comes up if you have installed a binary addon (e.g.
 r.geomorphon) built upon an another winGRASS version (e.g. winGRASS7beta1)
 and you try now to use it with another/newer version (e.g. winGRASS7beta3
 or winGRASS trunk).

 the error message should contain something like: "you are trying to use an
 addon built upon an another/older version of winGRASS; please update your
 addon by reinstalling".

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2505: v.build.polylines options aren't working

[GRASS GIS]

#2505: v.build.polylines options aren't working
---+
 Reporter:  hellik |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  7.0.0
Component:  Vector | Version:  svn-releasebranch70  
 Keywords:  v.build.polylines  |Platform:  All  
  Cpu:  Unspecified|  
---+
Changes (by hellik):

  * priority:  critical => major


Comment:

 Replying to [comment:2 neteler]:
 > Replying to [comment:1 mmetz]:
 > > Replying to [ticket:2505 hellik]:
 > >
 > > `cats=no` was indeed not working, fixed in r63321,2 (trunk, relbr70).

 confirmed cats=no is working now

 >
 > Should this go also into GRASS 6?
 >
 > > `v.build.polylines` is indeed copying all attribute tables as is from
 input to output, but the categories are processed according to the cats
 option. This means that the attribute table(s) can contain spurious
 entries that do not match any output feature. Other (not all) modules also
 copy attribute tables from input to output as is, without filtering.
 Usually, this does not harm and is not even noticeable.
 >

 above should go into the manual.

 > Is this ticket solved?

 downgrading priority; closing ticket when manual is extended.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev