[GRASS-dev] [GRASS GIS] #3210: r.texture: bug when non continuous series of values
GRASS GIS
trac at osgeo.org
Thu Dec 1 13:30:15 PST 2016
#3210: r.texture: bug when non continuous series of values
--------------------------+-------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.2.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.texture
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by mmetz):
Replying to [comment:32 mlennert]:
> Replying to [comment:31 mmetz]:
> > Replying to [comment:28 mlennert]:
> > > Replying to [comment:27 mmetz]:
> > > >
> > > > We could remove cropping at margins, the results would not be
perfect, but better than nothing.
> > >
> > > That's debatable. In my colleagues tests we saw that PCI Geomatica
"solves" this problem by just replicating the margin row/col as many times
as necessary depending on window size. This leads to weird textures at the
margins.
> >
> > Inventing values is a bad idea.
> > >
> > > Another (IMHO preferrable) option would be to calculate the texture
with just the available pixels, but this would mean that for a 3x3 window
you would only have one neighbor in each direction (except for the n-s or
e-w). Don't know if this is an issue ?
> >
> > I would use just the available pixels, the question is then more
general, how to handle NULL cells, also inside the current region. If NULL
cells are allowed, there is no reason to crop at the margins. If NULL
cells are not allowed, any moving window that contains NULL cells would be
skipped, also very large moving windows with only a single NULL cell.
Therefore I would prefer to allow NULL cells.
>
> +1
I have added a flag to allow NULL cells which also avoids cropping along
edges of the computational region in trunk r69965.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3210#comment:33>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list