#2175: m.nviz.image: adding transparency_value= changes raster layer stacking
order
----------------------------------------+-----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: svn-trunk
Keywords: m.nviz.image, transparency | Platform: Linux
Cpu: x86-64 |
----------------------------------------+-----------------------------------
Comment(by hamish):
Replying to [comment:6 annakrat]:
> Could we have the transparent layers as the last ones? Perhaps
> using `GS_get_att` we can identify them?
Hi,
it's not specifically transparent surfaces, or even constant surfaces that
cut through.
for example instead of null areas (which leave jagged triangles at their
edge) to mask off below sea level areas you can have a constant opaque
white surface at 0.0 to do the same, while the real DEM surface plunges
below. with that trick you get a nice crisp edge at the water's edge.
you might also want a dynamic surface which breaks but does not exceed the
max elevation of the main DEM, transparent or not. (e.g. a raster building
[are semi-transparent 3D vector surfaces possible?])
I guess the question is if allowing a user definable layer order is the
way around all this?
I'm also having trouble with sub-integer constant elevation values, even
after changing TYPE_INTEGER to TYPE_DOUBLE in m.nviz.image/args.c for
those options which are later parsed with atof(), so theoretically should
accept floating point values. e.g. 11.0-11.4 see reasonable but 11.5 and
11.7 drop down to near 11.0 again. it's all a bit weird but probably a
matter for another ticket.
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2175#comment:7>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
