Improve accuracy of auto-computed 'cost' values (in conjunction with option 'initial=')

[benducke]

It is possible to specify an initial links map (via 'initial=') that has no 'cost' attribute for its LCPs, and additionally a cost raster via 'costmap='.

If this combination of options is used, then v.net.models will automatically add a new 'cost' attribute to the initial links and upload the cumulative costs of all initial links/LCPs to it. This is done by rasterizing the links, creating a cost raster mask that contains only cost cells on the rasterized path and summing up the values of those cells. This is a quick way that avoids having to run r.cost (which is computationally intense for high resolution regions).

However, the result of this operation is not very accurate compared to r.cost, since the latter adds some extra cost if a cell has to be crossed diagonally. The result is that the "proper" costs computed by r.cost (i.e. a run of a complete model with a cost raster) will always be higher than the cost auto-computed by the 'initial links' mechanism!

How much higher depends on the lengths and shapes of the links (i.e. how many diagonal segments there are), as well as on the how many "expensive" cells are crossed diagonally. It is hard to think of a simple way to compensate for this. Perhaps anti-aliasing the rasterized links would help (the new AA cells should then only have n% of neighboring cost raster cells' avg. value).

The only alternative would be to think of a completely different way of auto-computing costs using r.cost.

For now, a warning will be issued, to make the user aware that there is a loss of accuracy involved (it can be significant: I have seen up to 20%; but in most cases it is much less).

Improvements have to be made in the main body of v.net.models, after: g.message -i "Computing costs of links in 'initial' links map..."

[benducke]

Note that using r.cost for auto-computing the cumulative costs of user-provided link geometries is very tricky, because there is no guarantee that these line geometries actually represent LCPs as r.cost would produce them! In fact, they might intentionally represent very different paths.

[benducke]

v.to.rast has a -d flag for creating 'densified' rasterizations. It might be as simple as subtracting a thin from a dense rasterized path and then finding the right 'weight' for the resulting ('buffering') cells. One could then use r.mapcalc to compute the intersection of these 'buffer' cells with the original cost raster and apply a constant weight to them.

[benducke]

Latest update brings the values of on-the-fly computed costs much closer to those produced by r.cost. This is achieved by adding some weighted cost cells between diagonal neighbors on the rasterized link path:

DIAG_fac="0.188"
r.mapcalc expression="${TMP_RAST_MAPCALC1}=if(!isnull(${TMP_RAST_RSTLNKS1}),${GIS_OPT_COSTMAP},${TMP_RAST_RSTLNKS2}*${GIS_OPT_COSTMAP}*${DIAG_fac})" --overwrite --quiet

[benducke]

I think this is about as far as it can be taken, without some Herculean effort or a fork/enhancement of r.cost.