I have upgraded r.in.xyz to allow for the following aggregate functions:
- skewness
- median
- percentile
- trimmed mean
To make this possible, I created singly linked lists for all points falling into a cell. I followed a suggestion of Glynn and used arrays instead of pointers and stored the head of each list in a raster map ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)). The linked lists are then used to calculate the corresponding statistics before binning the values.
So far we encountered no problems with this approach in our working group, but I'm not sure about some details. Maybe there should be some more checks, e.g. to prevent the index to overflow because of too many cells.
If you are interested I'd like to share the code. Maybe it would be best to send a copy to Hamish first?
I have upgraded r.in.xyz to allow for the following aggregate
functions: - skewness
- median
- percentile
- trimmed mean
To make this possible, I created singly linked lists for all points
falling into a cell. I followed a suggestion of Glynn and used arrays
instead of pointers and stored the head of each list in a raster map
([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)).
The linked lists are then used to calculate the corresponding
statistics before binning the values.
So far we encountered no problems with this approach in our working
group, but I'm not sure about some details. Maybe there should be some
more checks, e.g. to prevent the index to overflow because of too many
cells.
If you are interested I'd like to share the code. Maybe it would be
best to send a copy to Hamish first?
Hi Volker,
cheers for the upgrade, I'm sure it will be useful for many folks.
I will be travelling for the next couple of weeks and won't have a
chance to look at it before then. In the mean time can you post the
unidiff to the code patch tracker?
cheers for the upgrade, I'm sure it will be useful for many folks.
I will be travelling for the next couple of weeks and won't have a
chance to look at it before then. In the mean time can you post the
unidiff to the code patch tracker?
I have upgraded r.in.xyz to allow for the following aggregate functions:
- skewness
- median
- percentile
- trimmed mean
To make this possible, I created singly linked lists for all points
falling into a cell. I followed a suggestion of Glynn and used arrays
instead of pointers and stored the head of each list in a raster map
([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)).
The linked lists are then used to calculate the corresponding
statistics before binning the values.
So far we encountered no problems with this approach in our working
group, but I'm not sure about some details. Maybe there should be some
more checks, e.g. to prevent the index to overflow because of too many
cells.
[Gf patch #450]
After a long delay I have finally applied the patch in GRASS 6.3-CVS/HEAD.
I apologize to Volker for taking so long to deal with this, and congratulate him and his team on a job well done. It's a nice little bit of code.
The memory footprint seems to be about the same as for a stddev map.
Question for the LFS folks: if the region size is >2/4billion cells* will
the num_nodes, max_nodes, and node.next variables want to be something larger than int? nb I expect there will be other memory issues in this case anyway, and multi-pass via the percent= option should be used.
* regions bigger than 45000x45000 / 63245x63245
aside:
I am finding the r.colors "-e" flag and the 'r.colors.stddev -z' add-on script very very useful these days. ('r.colors -e' for ignoring outliers and 'r.colors.stddev -z' for a proper differences map [method=skewness])
> I have upgraded r.in.xyz to allow for the following aggregate functions:
> - skewness
> - median
> - percentile
> - trimmed mean
>
> To make this possible, I created singly linked lists for all points
> falling into a cell. I followed a suggestion of Glynn and used arrays
> instead of pointers and stored the head of each list in a raster map
> ([GRASS-dev] storing pointers in CELL_TYPE maps? (from April 2007)).
> The linked lists are then used to calculate the corresponding
> statistics before binning the values.
> So far we encountered no problems with this approach in our working
> group, but I'm not sure about some details. Maybe there should be some
> more checks, e.g. to prevent the index to overflow because of too many
> cells.
[Gf patch #450]
After a long delay I have finally applied the patch in GRASS
6.3-CVS/HEAD.
I apologize to Volker for taking so long to deal with this, and
congratulate him and his team on a job well done. It's a nice little
bit of code.
The memory footprint seems to be about the same as for a stddev map.
Question for the LFS folks: if the region size is >2/4billion cells*
will the num_nodes, max_nodes, and node.next variables want to be
something larger than int? nb I expect there will be other memory
issues in this case anyway, and multi-pass via the percent= option
should be used. * regions bigger than 45000x45000 / 63245x63245
aside:
I am finding the r.colors "-e" flag and the 'r.colors.stddev -z'
add-on script very very useful these days. ('r.colors -e' for
ignoring outliers and 'r.colors.stddev -z' for a proper differences
map [method=skewness])