#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
 > >
 > > 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>

grass-dev mailing list

Reply via email to