[GRASS-dev] i.segment: Invalid region id -1

[Nikos Alexandris]

Markus M:
> >> > >> > But it does not make sense to use a pan band as seeds when
> >> > >> > segmenting the other bands. Seeds are typically the result of a
> >> > >> > previous run of i.segment or the result of a previous
> >> > >> > classification of the same data.

Nikos A:
> >> > >> Then I have inserted a small mistake in my tests/workflow. Wanted to
> >> > >> drive "finer objects" (from Pan) in bigger ones (based on MS).
> >> > >> Will adjust.

MM:
> >> > The seeds map does the opposite. You probably want to do pansharpening
> >> > first.

NA:
> > Just for completeness, ehm... I was too fast. So, I did use sharpenned
> > images only in 2 trials, however, as I can actually see in the history. 
> > The exact same process in two different Mapsets (same Location),
> > QuickBird2 data:

> > --%<--
> > i.segment msx_hpf out=segments_msx_hpf_seeded_t0.02 threshold=0.02
> > minsize=4 seed=segments_pan_t0.01 memory=3000 iterations=1000
> > -->%--

> > It worked in one case (repeated to be sure) and it failed in another!

> Different computational regions?

Absolutely.  Two different, independent trials. Same Location, different 
Mapsets, different regions ("physically", if I may say so, and 
computationally).

> > In the failing case, before the ERROR message, there are multiple WARNINGS
> > issued:
> > 
> > ..
> > WARNING: Region consists of only one cell, nothing to update
> 
> This should not happen, a bug in the region growing algorithm.
> 
> > Now, I have re-ran the "failed" one and I get this strange:
> > 
> > ..
> > 0..5..10..15..20..25..30..35..40..ERROR: Invalid region id -1489
> 
> Essentially the same like "ERROR: Invalid region id -1". Again, this
> should not happen.
> 
> > ..
> > 
> > I went after looking all of the details of the involved maps.  The only
> > "strange" thing I can see (which I caused) is that the region is 0.6, the
> > seed (segments_pan_t0.01) is also 0.6 while the group of Pan-Sharpened
> > images are (each) of 0.60017817 (ns) x 0.60016801 (we) resolution.  Is
> > this my mistake? The resolution(s) should be identical, right?
> 
> Yes. I guess in the process of pansharpening, the region was set to
> 0.6, then the resolution was adjusted to the extents (for g.region,
> extents have precedence over resolution). The correct way of adjusting
> the region would be to either set the region to the pan band or align
> the region to the band band (g.region align=pan). Note that g.region
> res=0.6 -a can introduce a pixel shift.
> 
> Can you reproduce that with sample data?

I'll try.

> Or give me chance to reproduce that?

If I can't make it with "common" data from the Spearish Location, I can try 
with some publicly available High-Res images.

Nonetheless, I am convinced, for now, that the evil root was my bad choice of 
setting the region using the "-a" flag.  Usually, I try to keep the cell 
resolutions intact, as imported. With many high resolution images I have 
worked recently (IKONOS, QuickBird2, WorldView-1, WorldView-2), this is the 
case. They are not exactly 0.6, 1 or 2.4 or whatever.

However, trying to make the computational region as minimal as possible, I use 
very often something like "g.region zoom=Raster".  This, however, has no 
effect in the region's resolution. It affects only the extent.  And then, I 
easily fall in the trap to reset the resolution, e.g. it was set to match the 
MSes and I need the Pan's, so I do "g.region res=0.6 -a".

What do you think, a short warning in the manual that "the resolution of the 
computational region should be identical between subsequent segmentations that 
make use of a seed map"?

Nikos