toc in manual implemented

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@43469 15284696-431f-4ddb-bdfa-cd5b030d7da7

display/d.graph/d.graph.html

@@ -176,14 +176,14 @@ taken directly off an image drawn by hand on graph paper.
 A dynamic example can be found in the <em>d.polar</em> shell script.
 
 
-<h4>Draw a "star" symbol at a given map coordinate</h4>
+<h3>Draw a "star" symbol at a given map coordinate</h3>
 
 <div class="code"><pre>
 echo "symbol basic/star 20 2264417 5413182 black red" | d.graph -m
 </pre></div>
 
 
-<h4>Split the screen into quadrants:</h4>
+<h3>Split the screen into quadrants:</h3>
 
 <div class="code"><pre>
 d.frame -s full_screen

display/d.his/d.his.html

@@ -112,7 +112,7 @@ program <EM><A HREF="r.his.html">r.his</A></EM>.
 
 
 <H2>EXAMPLE</H2>
-<h4>Spearfish dataset</h4>
+<h3>Spearfish dataset</h3>
 
 <div class="code"><pre>
   g.region rast=elevation.dem

general/g.message/g.message.html

@@ -44,7 +44,7 @@ you are enouraged to single-quote messages that do not require
 <tt>$VARIABLE</tt> expansion.
 <P>
 
-<h4>VERBOSITY LEVELS</h4>
+<h3>VERBOSITY LEVELS</h3>
 Controlled by the "<tt>GRASS_VERBOSE</tt>" environment variable. Typically this
 is set using the <tt>--quiet</tt> or <tt>--verbose</tt> command line options.
 <ul>
@@ -54,7 +54,7 @@ is set using the <tt>--quiet</tt> or <tt>--verbose</tt> command line options.
 <li>3 - additional verbose messages are printed
 </ul>
 
-<h4>DEBUG LEVELS</h4>
+<h3>DEBUG LEVELS</h3>
 Controlled by the "<tt>DEBUG</tt>" GRASS <i>gisenv</i> variable. (set with
 <em><a href="g.gisenv.html">g.gisenv</a></em>)
 <BR>

gui/wxpython/docs/wxGUI.Modeler.html

@@ -5,15 +5,21 @@
 <p>
 <b>Graphical modeler</b> is a <em><a href="wxGUI.html">wxGUI</a></em>
 extension which allows the user to create, edit, and manage
-models. It's available from the menu &quot;File | Graphical modeler&quot;.
+models. The modeler can be launched from the menu &quot;File |
+Graphical modeler&quot; or by clicking on
+icon <img src="icons/grass2/modeler-main.png"> in the toolbar.
 
 <p>
 The modeler currently allows to:
 
 <ul>
   <li>define actions (GRASS modules)
-  <li>define data items (raster, vector, 3D raster)
+  <li>define data items (raster, vector, 3D raster maps)
   <li>define relations between data and action items
+  <li>define loops and conditions (if-else statements)
+  <li>define model variables
+  <li>define intermediate data
+  <li>parameterize actions
   <li>validate model
   <li>run model
   <li>store model settings to the file (GRASS Model File|*.gxm)
@@ -29,7 +35,7 @@ The modeler currently allows to:
 </em>
 
 <p>
-See also <a href="http://grass.osgeo.org/wiki/WxGUI_Modeler">wiki</a> page.
+See also user <a href="http://grass.osgeo.org/wiki/WxGUI_Modeler">wiki</a> page.
 
 <h2>AUTHORS</h2>
 

ps/ps.map/ps.map.html

@@ -272,7 +272,7 @@ See also the <a href="#vlegend">vlegend</a> command for creating vector map
 legends.
 
 
-<h4>Categorical (CELL) Maps</h4>
+<h3>Categorical (CELL) Maps</h3>
 
 Adding the <B>nodata N</B> instruction will prevent the "no data" box 
 from being drawn (category based legends only). If you have manually
@@ -288,7 +288,7 @@ Be aware that the color table only includes categories which
 have a label. You can use the <em>r.category</em> module to add labels.
 
 
-<h4>Floating point (FCELL and DCELL) Maps</h4>
+<h3>Floating point (FCELL and DCELL) Maps</h3>
 
 The legend's <B>range</B> can be adjusted for floating point rasters, but if
 set beyond the extent of the map's range be sure that you have set up color 
@@ -1605,7 +1605,7 @@ USAGE:	<B>end</B>
 
 The following are examples of <EM>ps.map</EM> script files.
 <P>
-<h4>Simple example</h4>
+<h3>Simple example</h3>
 The file has been named <EM>spear.basic</EM>:
 
 <PRE>
@@ -1625,7 +1625,7 @@ Generate map as Postsript file:
 </PRE>
 
 
-<h4>More complicated example</h4>
+<h3>More complicated example</h3>
 The file has been named <EM>spear.soils</EM>:
 
 <PRE>

raster/r.basins.fill/r.basins.fill.html

@@ -40,7 +40,6 @@ href="http://grass.osgeo.org/gdp/raster/r.watershed.ps">Tutorial:
 r.watershed</a> for further details on the combined use of
 <em>r.basins.fill</em> and <em><a href="r.watershed.html">r.watershed</a></em>.
 
-<p>
 <em>
   <a href="r.watershed.html">r.watershed</a>,
   <a href="wxGUI.Vector_Digitizing_Tool.html">wxGUI vector digitizer</a>

raster/r.cost/r.cost.html

@@ -121,7 +121,7 @@ resolution can be found using <em><a href="g.region.html">g.region</a></em>.
 This problem doesn't arise with floating point maps.
 
 
-<h4>Algorithm notes</h4>
+<h3>Algorithm notes</h3>
 
 The fundamental approach to calculating minimum travel cost is as
 follows:<p> The user generates a raster map indicating the cost of
@@ -202,7 +202,7 @@ only one) starting location(s). Cells surrounded by asterisks are
 those that are different between operations using and not using the
 Knight's move (<b>-k</b>) option.
 
-<h4>Output analysis</h4>
+<h3>Output analysis</h3>
 
 The output map can be viewed, for example, as an elevation model in which
 the starting location(s) is/are the lowest point(s). Outputs from  <em>r.cost</em>
@@ -212,7 +212,7 @@ model between any given cell and the <em>r.cost</em> starting location(s). The
 two programs, when used together, generate least-cost paths or corridors between any 
 two map locations (cells).
 
-<h4>Shortest distance surfaces</h4>
+<h3>Shortest distance surfaces</h3>
 The <em>r.cost</em> module allows for computing the shortest distance 
 of each pixel from raster lines, such as determining the shortest distances
 of households to the nearby road. For this cost surfaces with cost value 1 are

raster/r.in.xyz/r.in.xyz.html

@@ -40,7 +40,7 @@ Available statistics for populating the raster are:<br>
 
 <h2>NOTES</h2>
 
-<h4>Gridded data</h4>
+<h3>Gridded data</h3>
 
 If data is known to be on a regular grid <em>r.in.xyz</em> can reconstruct
 the map perfectly as long as some care is taken to set up the region
@@ -60,7 +60,7 @@ min, max</i>, or <i>median</i> methods. With n=1 throughout, the result
 should be identical regardless of which of those methods are used.
 
 
-<h4>Memory use</h4>
+<h3>Memory use</h3>
 
 While the <b>input</b> file can be arbitrarily large, <em>r.in.xyz</em>
 will use a large amount of system memory for large raster regions (10000x10000).
@@ -85,7 +85,7 @@ preserving data precision and limiting system resource consumption.
 If reading data from a <tt>stdin</tt> stream, the program can only run using
 a single pass.
 
-<h4>Setting region bounds and resolution</h4>
+<h3>Setting region bounds and resolution</h3>
 
 You can use the <b>-s</b> scan flag to find the extent of the input data
 (and thus point density) before performing the full import. Use
@@ -115,7 +115,7 @@ resolution so fine that you only catch one data point per cell -- you might
 as well use "<tt>v.in.ascii&nbsp;-zbt</tt>" directly.
 
 
-<h4>Filtering</h4>
+<h3>Filtering</h3>
 
 Points falling outside the current region will be skipped. This includes
 points falling <em>exactly</em> on the southern region bound.
@@ -148,13 +148,13 @@ map. [In this example the user may want to include a lower bound filter in
 <em>r.neighbors</em> to smooth the stddev map before further use.]
 
 
-<h4>Reprojection</h4>
+<h3>Reprojection</h3>
 
 If the raster map is to be reprojected, it may be more appropriate to reproject
 the input points with <em>m.proj</em> or <em>cs2cs</em> before running
 <em>r.in.xyz</em>.
 
-<h4>Interpolation into a DEM</h4>
+<h3>Interpolation into a DEM</h3>
 
 The vector engine's topographic abilities introduce a finite memory overhead
 per vector point which will typically limit a vector map to approximately

raster/r.out.gdal/r.out.gdal.html

@@ -80,7 +80,7 @@ Typical boundaries of primitive integral types</a></em>
 for details.
 
 
-<h4>Ranges of GDAL data types</h4>
+<h3>Ranges of GDAL data types</h3>
 <pre>
   GDAL data type	       minimum  	maximum
 
@@ -120,7 +120,7 @@ possible values which is very large for e.g. Int32 or Float32. E.g.
 stretching the color table to actual min/max would help (sometimes under
 symbology).
 
-<h4>GeoTIFF caveats</h4>
+<h3>GeoTIFF caveats</h3>
 
 GeoTIFF exports can only be displayed by standard image viewers
 if the GDAL data type was set to Byte and the GeoTIFF contains either
@@ -137,7 +137,7 @@ efficient, but not supported by some applications.
 This issue only arises when writing out multi-band imagery groups.
 <p>
 
-<h4>Improving GeoTIFF compatibility</h4>
+<h3>Improving GeoTIFF compatibility</h3>
 
 To create a GeoTIFF that is highly compatible with various other GIS
 software packages, it is recommended to keep the GeoTIFF file as simple
@@ -175,31 +175,31 @@ overviews.
 
 <h2>EXAMPLES</h2>
 
-<h4>Export the integer raster roads map to GeoTIFF format:</h4>
+<h3>Export the integer raster roads map to GeoTIFF format:</h3>
 <div class="code"><pre>
 r.out.gdal input=roads output=roads.tif type=UInt16
 </pre></div>
 <p>
 
-<h4>Export a DCELL raster map in GeoTIFF format suitable for ESRI software:</h4>
+<h3>Export a DCELL raster map in GeoTIFF format suitable for ESRI software:</h3>
 <div class="code"><pre>
 r.out.gdal in=elevation.10m out=ned_elev10m.tif type=Float64 createopt="PROFILE=GeoTIFF,TFW=YES"
 </pre></div>
 <p>
 
-<h4>Export R,G,B imagery bands in GeoTIFF format suitable for ESRI software:</h4>
+<h3>Export R,G,B imagery bands in GeoTIFF format suitable for ESRI software:</h3>
 <div class="code"><pre>
 i.group group=nc_landsat_rgb input=lsat7_2002_30,lsat7_2002_20,lsat7_2002_10
 r.out.gdal in=nc_landsat_rgb out=nc_landsat_rgb.tif type=Byte createopt="PROFILE=GeoTIFF,INTERLEAVE=PIXEL,TFW=YES"
 </pre></div>
 <p>
 
-<h4>Export the floating point raster elevation map to ERDAS/IMG format:</h4>
+<h3>Export the floating point raster elevation map to ERDAS/IMG format:</h3>
 <div class="code"><pre>
 r.out.gdal input=elevation.10m output=elev_dem10.img format=HFA type=Float32
 </pre></div>
 
-<h4>Export group of image maps as multi-band file</h4>
+<h3>Export group of image maps as multi-band file</h3>
 <div class="code"><pre>
 g.list group
 i.group group=tm7 subgroup=tm7 input=tm7_10,tm7_20,tm7_30,tm7_40,tm7_50,tm7_60,tm7_70

raster/r.proj/r.proj.html

@@ -7,7 +7,7 @@ in the current location. The projection information is taken from the
 current PROJ_INFO files, as set with <i><a href="g.setproj.html">g.setproj</a>
 </i> and viewed with <i><a href="g.proj.html">g.proj</a></i>.
 
-<h4>Introduction</h4>
+<h3>Introduction</h3>
 
 <h5>Map projections</h5>
 
@@ -83,7 +83,7 @@ the PROJ_INFO and PROJ_UNITS files in the PERMANENT mapset directory for every
 GRASS location.
 <br><br>
 
-<h4>Design of r.proj</h4>
+<h3>Design of r.proj</h3>
 
 As discussed briefly above, the fundamental step in re-projecting a
 raster is resampling the source grid at locations corresponding to the
@@ -175,7 +175,7 @@ may be odd with trimming.
 
 <h2>EXAMPLES</h2>
 
-<h4>Inline method</h4>
+<h3>Inline method</h3>
 With GRASS running in the destination location use the <b>-g</b> flag to
 show the input map's bounds once projected into the current working projection,
 then use that to set the region bounds before performing the reprojection:
@@ -231,7 +231,7 @@ GRASS> r.proj input=elevation location=ll_wgs84 mapset=user1 memory=800
 </pre></div>
 
 
-<h4>v.in.region method</h4>
+<h3>v.in.region method</h3>
 <div class="code"><pre>
 
 # In the source location, use v.in.region to generate a bounding box around the

raster/r.resamp.bspline/r.resamp.bspline.html

@@ -55,7 +55,7 @@ when cross-validation is selected.
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic interpolation</h4>
+<h3>Basic interpolation</h3>
 
 <div class="code"><pre>
 r.resamp.bspline input=raster_surface output=interpolated_surface method=bicubic
@@ -64,7 +64,7 @@ r.resamp.bspline input=raster_surface output=interpolated_surface method=bicubic
 A bicubic spline interpolation will be done and a raster map with estimated
 (i.e., interpolated) values will be created. 
 
-<h4>Interpolation of NULL cells and patching</h4>
+<h3>Interpolation of NULL cells and patching</h3>
 
 <div class="code"><pre>
 # set region to area with NULL cells, align region to input map
@@ -77,7 +77,7 @@ g.region rast=input -p
 r.patch input=input_raster,interpolated_nulls output=input_raster_gapfilled
 </pre></div>
 
-<h4>Estimation of <b><i>lambda</i></b> parameter with a cross validation proccess</h4>
+<h3>Estimation of <b><i>lambda</i></b> parameter with a cross validation proccess</h3>
 
 A random sample of points should be generated first with
 <a href="r.random.html">r.random</a>, and the current region should not

raster/r.watershed/front/r.watershed.html

@@ -178,7 +178,7 @@ number (usually less than one), the GRASS output map is of type DCELL.
 
 <h2>NOTES</h2>
 
-<h4>A<sup>T</sup> least-cost search algorithm</h4>
+<h3>A<sup>T</sup> least-cost search algorithm</h3>
 <em>r.watershed</em> uses an A<sup>T</sup> least-cost search algorithm 
 (see <a href="#references">REFERENCES</a> section) designed to minimize 
 the impact of DEM data errors. Compared to <em>r.terraflow</em>, this 
@@ -203,7 +203,7 @@ The algorithm produces results similar to those obtained when running
 <em><a href="r.cost.html">r.cost</a></em> and
 <em><a href="r.drain.html">r.drain</a></em> on every cell on the map.
 
-<h4>Multiple flow direction (MFD)</h4>
+<h3>Multiple flow direction (MFD)</h3>
 
 <em>r.watershed</em> offers two methods to calculate surface flow: 
 single flow direction (SFD, D8) and multiple flow direction (MFD). With 
@@ -218,7 +218,7 @@ factor of 5 (Holmgren, 1994). If many small sliver basins are created
 with MFD, setting the convergence factor to a higher value can reduce 
 the amount of small sliver basins.
 
-<h4>In-memory mode and disk swap mode</h4>
+<h3>In-memory mode and disk swap mode</h3>
 There are two versions of this program: <em>ram</em> and <em>seg</em>.
 <em>ram</em> is used by default, <em>seg</em> can be used by setting 
 the <em>-m</em> flag.
@@ -246,7 +246,7 @@ regions in mind and may be useful here as an alternative, although disk
 space requirements of <em>r.terraflow</em> are several times higher than
 of <em>seg</em>.
 
-<h4>Large regions with many cells</h4>
+<h3>Large regions with many cells</h3>
 In some situations, the region size (number of cells) may be too large for
 the amount of time or memory available. Running <em>r.watershed</em> may
 then require use of a coarser resolution. To make the results more closely
@@ -263,7 +263,7 @@ which <em>r.watershed</em> will be run, <em>r.watershed</em> should be run
 using the values from the <em>neighborhood</em> output map layer that
 represents the minimum elevation within the region of the coarser cell.
 
-<h4>Basin threshold</h4>
+<h3>Basin threshold</h3>
 The minimum size of drainage basins, defined by the <em>threshold</em>
 parameter, is only relevant for those watersheds with a single stream
 having at least the <em>threshold</em> of cells flowing into it.
@@ -273,7 +273,7 @@ Interior drainage basins can be of any size because the length of
 an interior stream segment is determined by the distance between the
 tributaries flowing into it.
 
-<h4>MASK and no data</h4>
+<h3>MASK and no data</h3>
 <p>
 The <em>r.watershed</em> program does not require the user to have the
 current geographic region filled with elevation values.  Areas without
@@ -292,7 +292,7 @@ e.g. with <em>r.fillnulls</em>.
 <p>
 Zero (0) and negative values will be treated as elevation data (not no_data).
 
-<h4>Further processing of output layers</h4>
+<h3>Further processing of output layers</h3>
 <p>
 Problem areas, i.e. those parts of a basin with a likely underestimate of
 flow accumulation, can be easily identified with e.g.

raster/r.what/r.what.html

@@ -28,7 +28,7 @@ the cell(s) at this geographic location.
 <h2>EXAMPLES</h2>
 
 
-<h4>Input from <tt>stdin</tt> on the command line</h4>
+<h3>Input from <tt>stdin</tt> on the command line</h3>
 
 Input coordinates may be given directly from <tt>stdin</tt>, for example:
 <br> (input data appears between the "<tt>EOF</tt>" markers)
@@ -50,7 +50,7 @@ echo "635342.21 7654321.09" | r.what input=soils,aspect
 </pre></div>
 
 
-<h4>Input from a text file containing coordinates</h4>
+<h3>Input from a text file containing coordinates</h3>
 
 The contents of an ASCII text file can be redirected to <em>r.what</em>
 as follows. If we have a file called <i>input_coord.txt</i> containing the
@@ -64,7 +64,7 @@ r.what input=soils,aspect < input_coord.txt
 </pre></div>
 
 
-<h4>Input coordinates given as a module option</h4>
+<h3>Input coordinates given as a module option</h3>
 
 The module's <b>east_north</b> parameter can be used to enter coordinate
 pairs directly. The maximum number of pairs will be limited by your system's
@@ -78,7 +78,7 @@ r.what input=soils,aspect east_north=635342.21,7654321.09,653324.88,7563412.42
 </pre></div>
 
 
-<h4>Input coordinates piped from another program</h4>
+<h3>Input coordinates piped from another program</h3>
 
 The input coordinates may be "piped" from the <tt>stdout</tt> of another program.
 For example:
@@ -100,7 +100,7 @@ spaces for <em>r.what</em>.
 v.out.ascii bugsites fs=' ' | r.what input=soils,aspect
 </pre></div>
 
-<h4>Output containing raster map category labels</h4>
+<h3>Output containing raster map category labels</h3>
 
 Here we use the <b>-f</b> label flag to enable the output of category labels
 associated with the raster cell(s), as well as values. (categorical maps only)

scripts/m.proj/m.proj.html

@@ -130,7 +130,7 @@ define either 3 or 7 term datum transform coefficients, satisfying this requirem
 If a datum is specified there is no need for the '<tt>+ellps=</tt>' or underlying
 parameters, '<tt>+a=</tt>', '<tt>+es=</tt>', etc.
 <p>
-<h4>Another custom parameter usage example:</h4>
+<h3>Another custom parameter usage example:</h3>
 
 <div class="code"><pre>
 m.proj <B>proj_in</B>="+proj=tmerc +datum=ire65 +lat_0=53.5 +lon_0=-8 +x_0=200000 \

tools/mkhtml.py

@@ -4,8 +4,9 @@
 #
 # MODULE:       mkhtml.py
 # AUTHOR(S):    Markus Neteler, Glynn Clements
+#               TOC by Martin Landa <landa.martin gmail.com>
 # PURPOSE:      create HTML manual page snippets
-# COPYRIGHT:    (C) 2007,2009 Glynn Clements and the GRASS Development Team
+# COPYRIGHT:    (C) 2007,2009-2010 Glynn Clements and the GRASS Development Team
 #
 #               This program is free software under the GNU General Public
 #               License (>=v2). Read the file COPYING that comes with GRASS
@@ -56,6 +57,62 @@ def read_file(name):
 
 src_data = read_file(src_file)
 
+def get_toc_item(line, pattern):
+    found = pattern.search(line)
+    if found:
+        return found.group(2).strip()
+    
+    return None
+
+def filter_toc_item(label):
+    return label.replace('"', '&quot;')
+
+def write_toc_level(line, src_list, pattern, pattern_level, level, idx):
+    indent = 4
+    
+    text = get_toc_item(line, pattern)
+    if not text:
+        return False, level
+    
+    if pattern_level > level:
+        for l in range(level, pattern_level):
+            sys.stdout.write('%s<ul>\n' % (' ' * l * indent))
+    elif level > pattern_level:
+        for l in range(level, pattern_level, -1):
+            sys.stdout.write('%s</ul>\n' % (' ' * (l - 1) * indent))
+    level = pattern_level
+    
+    sys.stdout.write('%s<li><a href="#%s">%s</a>\n' % (' ' * level * indent,
+                                                       filter_toc_item(text), filter_toc_item(text)))
+    src_list[idx] = '<a name="%s"></a>' % filter_toc_item(text) + line
+    
+    return True, level
+    
+def write_toc():
+    global src_data
+    level  = 1
+    idx    = 0
+    
+    sys.stdout.write('<a name="TOC"></a><h2>TABLE OF CONTENT</h2>\n\n<ul>\n')
+    src_list = src_data.splitlines()
+    for line in src_list:
+        found, level = write_toc_level(line, src_list,
+                                       re.compile(r"(<h2>)(.*)(</h2>)", re.IGNORECASE), 1,
+                                       level, idx)
+        if not found:
+            found, level = write_toc_level(line, src_list,
+                                           re.compile(r"(<h3>)(.*)(</h3>)", re.IGNORECASE), 2,
+                                           level, idx)
+        if not found:
+            found, level = write_toc_level(line, src_list,
+                                           re.compile(r"(<h4>)(.*)(</h4>)", re.IGNORECASE), 3,
+                                           level, idx)
+                
+        idx += 1
+    
+    sys.stdout.write('</ul>\n')
+    src_data = '\n'.join(src_list)
+
 if not re.search('<html>', src_data, re.IGNORECASE):
     tmp_data = read_file(tmp_file)
     if not re.search('<html>', tmp_data, re.IGNORECASE):
@@ -64,6 +121,7 @@ if not re.search('<html>', src_data, re.IGNORECASE):
 	for line in tmp_data.splitlines(True):
 	    if not re.search('</body>|</html>', line, re.IGNORECASE):
 		sys.stdout.write(line)
+    write_toc()
 
 sys.stdout.write(src_data)
 
@@ -73,22 +131,20 @@ if re.search('</html>', src_data, re.IGNORECASE):
     sys.exit()
 
 index_names = {
-    'd': 'display',
+    'd' : 'display',
     'db': 'database',
-    'g': 'general',
-    'i': 'imagery',
-    'm': 'misc',
-    'pg': 'postGRASS',
+    'g' : 'general',
+    'i' : 'imagery',
+    'm' : 'misc',
     'ps': 'postscript',
-    'p': 'paint',
-    'r': 'raster',
+    'p' : 'paint',
+    'r' : 'raster',
     'r3': 'raster3D',
-    's': 'sites',
-    'v': 'vector'
+    's' : 'sites',
+    'v' : 'vector'
     }
 
 mod_class = pgm.split('.', 1)[0]
 index_name = index_names.get(mod_class, mod_class)
 
 sys.stdout.write(footer_tmpl.substitute(INDEXNAME = index_name))
-

vector/v.lidar.correction/v.lidar.correction.html

@@ -50,12 +50,12 @@ OBJECT DOUBLE PULSE (cat = 4, layer = 2)
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic correction procedure</h4>
+<h3>Basic correction procedure</h3>
 <div class="code"><pre>
 v.lidar.correction input=growing output=correction out_terrain=only_terrain
 </pre></div>
 
-<h4>Second correction procedure</h4>
+<h3>Second correction procedure</h3>
 <div class="code"><pre>
 v.lidar.correction input=correction output=correction_bis out_terrain=only_terrain_bis
 </pre></div>

vector/v.lidar.edgedetection/v.lidar.edgedetection.html

@@ -63,7 +63,7 @@ OBJECT DOUBLE PULSE (cat = 4, layer = 2)
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic edge detection</h4>
+<h3>Basic edge detection</h3>
 <div class="code"><pre>
 v.lidar.edgedetection input=vector_last output=edge see=8 sen=8 lambda_g=0.5
 </pre></div>

vector/v.lidar.growing/v.lidar.growing.html

@@ -42,7 +42,7 @@ classification in the same categories as above.
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic region growing procedure</h4>
+<h3>Basic region growing procedure</h3>
 <div class="code"><pre>
 v.lidar.growing input=edge output=growing first=firstpulse
 </pre></div>

vector/v.outlier/v.outlier.html

@@ -14,7 +14,7 @@ considered as a category.
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic outlier removal</h4>
+<h3>Basic outlier removal</h3>
 
 <div class="code"><pre>
 v.outlier input=vector_map output=vector_output outlier=vector_outlier thres_O=25
@@ -22,7 +22,7 @@ v.outlier input=vector_map output=vector_output outlier=vector_outlier thres_O=2
 
 In this case, a basic outlier removal is done with a threshold of 25 m.
 
-<h4>Basic outlier removal</h4>
+<h3>Basic outlier removal</h3>
 
 <div class="code"><pre>
 v.outlier -q input=vector_map output=vector_output outlier=vector_outlier qgis=vector_qgis
@@ -32,7 +32,7 @@ Now, the outlier removal uses the default threshold and there is also
 an output vector available for visualizaton in QGIS
  (<a href="http://www.qgis.org">http://www.qgis.org</a>).
 
-<h4>North carolina location example</h4>
+<h3>North carolina location example</h3>
 
 <div class="code"><pre>
 v.outlier --o --v input=elev_lid792_bepts@PERMANENT output=elev_lid792_bepts_nooutliers outlier=elev_lid792_bepts_outliers soe=5 son=5 thres_o=0.1

vector/v.reclass/v.reclass.html

@@ -36,7 +36,7 @@ For dissolving common boundaries, see
 <H2>EXAMPLES</H2>
 
 
-<H4>Example 1: Reclass by rules</H4>
+<H3>Example 1: Reclass by rules</H3>
 
 <div class="code"><pre>
 v.reclass input=land output=land_u type=boundary rules=land.rcl
@@ -64,7 +64,7 @@ values selected from database by SQL select statement:
 <tt>select id from tland where use = 'E14'</tt> changed to category 2.
 
 
-<H4>Example 2: Reclass by attribute column</H4>
+<H3>Example 2: Reclass by attribute column</H3>
 
 (North Carolina sample dataset)<br>
 

vector/v.segment/v.segment.html

@@ -10,7 +10,7 @@ P <point id>   <line cat> <offset> [<side offset>]
 L <segment id> <line cat> <start offset> <end offset> [<side offset>]
 </pre></div>
 
-<h4>EXAMPLE</h4>
+<h3>EXAMPLE</h3>
 
 The user could send to <tt>stdin</tt> something like:
 <div class="code"><pre>

vector/v.surf.bspline/v.surf.bspline.html

@@ -88,7 +88,7 @@ is generated.
 
 <h2>EXAMPLES</h2>
 
-<h4>Basic interpolation</h4>
+<h3>Basic interpolation</h3>
 
 <div class="code"><pre>
 v.surf.bspline input=point_vector output=interpolate_surface method=bicubic
@@ -97,7 +97,7 @@ v.surf.bspline input=point_vector output=interpolate_surface method=bicubic
 A bicubic spline interpolation will be done and a vector points map with estimated
 (i.e., interpolated) values will be created. 
 
-<h4>Basic interpolation and raster output with a longer spline step</h4>
+<h3>Basic interpolation and raster output with a longer spline step</h3>
 
 <div class="code"><pre>
 v.surf.bspline input=point_vector raster=interpolate_surface sie=25 sin=25
@@ -106,13 +106,13 @@ v.surf.bspline input=point_vector raster=interpolate_surface sie=25 sin=25
 A bilinear spline interpolation will be done with a spline step length of 25 map
 units. An interpolated raster map will be created at the current region resolution.
 
-<h4>Estimation of <b><i>lambda_i</i></b> parameter with a cross validation proccess</h4>
+<h3>Estimation of <b><i>lambda_i</i></b> parameter with a cross validation proccess</h3>
 
 <div class="code"><pre>
 v.surf.bspline -c input=point_vector 
 </pre></div>
 
-<h4>Estimation on sparse points</h4>
+<h3>Estimation on sparse points</h3>
 
 <div class="code"><pre>
 v.surf.bspline input=point_vector sparse=sparse_points output=interpolate_surface
@@ -120,7 +120,7 @@ v.surf.bspline input=point_vector sparse=sparse_points output=interpolate_surfac
 
 An output map of vector points will be created, corresponding to the sparse vector map, with interpolated values.
 
-<h4>Using attribute values instead Z-coordinates</h4>
+<h3>Using attribute values instead Z-coordinates</h3>
 <div class="code"><pre>
 v.surf.bspline input=point_vector raster=interpolate_surface layer=1 column=attrib_column
 </pre></div>
@@ -128,7 +128,7 @@ v.surf.bspline input=point_vector raster=interpolate_surface layer=1 column=attr
 The interpolation will be done using the values in attrib_column, in the
 table associated with layer 1.
 
-<h4>North carolina location example using Z-coordinates for interpolation</h4>
+<h3>North carolina location example using Z-coordinates for interpolation</h3>
 <div class="code"><pre>
 v.surf.bspline --o --v input=elev_lid792_bepts@PERMANENT raster=elev_lid792_rast sie=5 sin=5 method=bicubic lambda_i=0.1 -z
 </pre></div>