[GRASS-dev] [GRASS GIS] #2009: thumbnails.py failure

GRASS GIS GRASS GIS developer
1

#2009: thumbnails.py failure
-------------------------------+--------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors v.colors | Platform: All
      Cpu: Unspecified |
-------------------------------+--------------------------------------------
thumbnails.py has two problems:

{{{
make thumbnails
make[1]: Entering directory `/home/neteler/grass70/vector/v.colors'
GISRC=/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/demolocation/.grassrc70 GISBASE=/home/neteler/grass70/dist.x86_64
-unknown-linux-gnu PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/bin:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:$PATH"
PYTHONPATH="/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/etc/python:/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/bin:/home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/lib:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib:" LC_ALL=C
./thumbnails.py
Traceback (most recent call last):
   File "./thumbnails.py", line 188, in <module>
     main()
   File "./thumbnails.py", line 179, in main
     grad = make_gradient(path)
   File "./thumbnails.py", line 121, in make_gradient
     maxval = float(records[-1][0])
ValueError: could not convert string to float: default
make[1]: [thumbnails] Error 1 (ignored)
make[1]: Leaving directory `/home/neteler/grass70/vector/v.colors'
VERSION_NUMBER=7.0.svn VERSION_DATE=2013 \
         python /home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/tools/mkhtml.py v.colors > /home/neteler/grass70/dist.x86_64-unknown-
linux-gnu/docs/html/v.colors.html
VERSION_NUMBER=7.0.svn /home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/tools/g.html2man.py /home/neteler/grass70/dist.x86_64-unknown-linux-
gnu/docs/html/v.colors.html /home/neteler/grass70/dist.x86_64-unknown-
linux-gnu/docs/man/man1/v.colors.1
rm v.colors.tmp.html
[neteler@oboe v.colors]$
}}}

The problem is the (valid) "default" here:

{{{
grep default lib/gis/colors/*
lib/gis/colors/srtm_plus:default 255:255:255
}}}

which needs to be blacklisted (or whatever, since "nv" is accepted)
in these Python scripts:

{{{
raster/r.colors/thumbnails.py
vector/v.colors/thumbnails.py
}}}

----

Second issue: even if deleting the offending line locally,
nothing is really produced. How should it work? I expected
to see an enriched HTML manual.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2009&gt;
GRASS GIS <http://grass.osgeo.org>

2

#2009: thumbnails.py failure
-------------------------------+--------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors v.colors | Platform: All
      Cpu: Unspecified |
-------------------------------+--------------------------------------------

Comment(by hamish):

untested patch for problem #1:

{{{
Index: raster/r.colors/thumbnails.py

--- raster/r.colors/thumbnails.py (revision 56728)
+++ raster/r.colors/thumbnails.py (working copy)
@@ -102,7 +102,7 @@
              # skip comments
              continue
          records.append(line.split())
- records = [record for record in records if record[0] != 'nv']
+ records = [record for record in records if record[0] != 'nv' and
record[0] != 'default']
      relative = False
      absolute = False
      for record in records:
}}}

H

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#2009: thumbnails.py failure
-------------------------------+--------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors v.colors | Platform: All
      Cpu: Unspecified |
-------------------------------+--------------------------------------------

Comment(by neteler):

Replying to [comment:1 hamish]:
> untested patch for problem #1:

Works. It appears to solved problem 2 as well. Please submit.

Markus

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#2009: thumbnails.py failure
-------------------------------+--------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors v.colors | Platform: All
      Cpu: Unspecified |
-------------------------------+--------------------------------------------

Comment(by neteler):

Replying to [comment:2 neteler]:
> It appears to solved problem 2 as well.

To be precise: the png files are generating, yet lacking the
integration in the HTML file.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#2009: thumbnails.py failure
--------------------------------+-------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors, v.colors | Platform: All
      Cpu: Unspecified |
--------------------------------+-------------------------------------------
Changes (by hamish):

  * keywords: r.colors v.colors => r.colors, v.colors

Comment:

Anna - the new r.colors module GUI dropdown list looks brilliant. thanks!
The information is right where/when you need it.

Thumbnails in the help page fixed in trunk with r56787.

some observations of further buglettes:

I note in trunk there is some rendering error in the top-left corners of
all the image boxes, manifested as a missing pixel. (in GRASS 6 there
was/is a similar bug in d.barscale + Xdriver)

Another rendering issue to be fixed: the absolute-value limited/libgis
color tables (grey.eq, grey.log, and random) are too big by a few pixels
on the right and bottom sides.

We should do something better with the population palettes, maybe put them
on a log-scale. Maybe the same with the precipitation palette. See the
special rule for population in the old shell script version of the
thumbnail generation script:
   http://grasswiki.osgeo.org/wiki/Talk:Color_tables

Finally, this is a clear case where the Xdriver does a better job than the
Cairo driver, compare the thumbnails in trunk with the crispness of the
devbr6 versions:
   source:grass/branches/develbranch_6/raster/r.colors/thumbnails
... sometimes you want 1px lines to be exactly 1px wide, and no anti-
aliasing.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

#2009: thumbnails.py failure
--------------------------------+-------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors, v.colors | Platform: All
      Cpu: Unspecified |
--------------------------------+-------------------------------------------

Comment(by glynn):

Replying to [comment:4 hamish]:

> I note in trunk there is some rendering error in the top-left corners of
all the image boxes, manifested as a missing pixel. (in GRASS 6 there
was/is a similar bug in d.barscale + Xdriver)

> Finally, this is a clear case where the Xdriver does a better job than
the Cairo driver, compare the thumbnails in trunk with the crispness of
the devbr6 versions:
> source:grass/branches/develbranch_6/raster/r.colors/thumbnails
> ... sometimes you want 1px lines to be exactly 1px wide, and no anti-
aliasing.

Both of these are a result of the d.* modules having been "minimally
ported" from the 6.x display API.

Closed paths should be closed with D_close() rather than by
D_cont_{abs,rel} back to the starting point. The latter will result in the
path being treated as open and thus having end caps.

Single-pixel lines should be drawn along the centre-line of a pixel row or
column, not along the boundary between rows/columns. IOW, the vertices
should have coordinates which are offset from an integer value by 0.5,
rather than being integers.

The display API can't realistically do this automatically because it can't
easily and reliably determine when it needs to "fix" the coordinates and
when it should use them verbatim. E.g. d.vect shouldn't fix boundaries
which happen to be axis-aligned rectangles because they'll be misaligned
with the rest of the data.

OTOH, if you have a 200-dpi display, single-pixel lines may as well just
not be drawn, because you probably won't be able to see them. For a quick
fix, setting the line width to 2 pixels is probably simpler than changing
the coordinates.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

7

#2009: thumbnails.py failure
--------------------------------+-------------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors, v.colors | Platform: All
      Cpu: Unspecified |
--------------------------------+-------------------------------------------

Comment(by hamish):

Replying to [comment:5 glynn]:
> Single-pixel lines should be drawn along the centre-line of a pixel
> row or column, not along the boundary between rows/columns.

it is enough for me to know that single-pixel lines are still possible,
the rest, as they say, is just details & can tuned up along the way.

fwiw I'm mostly concerned about things like d.legend and d.barscale which
like to be crisp rectangles and not anti-aliased.

thanks,
Hamish

ps- curved lines in symbol rendering are a lot less wiggly now, see
r56778. but it's still not perfect: I believe that add_coor()'s x,y in
stroke.c can go all-floating point now.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2009#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>