r.stats.zonal with -r option

[frankie]

When using a -r option to produce a reclassified output raster as result, the r.reclass call at the end of the program could be *extremely* inefficient. I tried with large maps many thousands of cats (derived by r.clump) and I got very long running times.

Creating the rules files instead is very fast, even in those conditions. In many cases, it would be sufficient giving it as an (optional) output file and the r.reclass step could be avoided/postponed. BTW, undestanding why the r.reclass module could take ages would be nice, too.

Cheers,

Frankie

[mmetz]

Replying to frankie:

When using a -r option to produce a reclassified output raster as result, the r.reclass call at the end of the program could be *extremely* inefficient. I tried with large maps many thousands of cats (derived by r.clump) and I got very long running times.

That's why the default is not to create reclass maps.

Creating the rules files instead is very fast, even in those conditions. In many cases, it would be sufficient giving it as an (optional) output file and the r.reclass step could be avoided/postponed. BTW, undestanding why the r.reclass module could take ages would be nice, too.

The reason is that the underlying library function to assign category labels Rast_set_cat() becomes terribly slow with an increasing number of categories. The relevant parts of the raster lib would need to be rewritten using a dynamic binary balanced search tree for a speed-up of raster category handling.

[frankie]

I managed to work around as suggested, i.e. adding a rules= parameter to save the reclassing rules file, then mimic r.category with simple egrep clauses on the resulting rules set. At least it allows to have results in decent time. I also noticed that while a lot of rules associate -nan they are probably even processed in the r.reclass run. I agree that the right fix would be modifying the library function, but in the meantime this silly trick saved my butt :-)