Differences

This shows you the differences between two versions of the page.

--- image_virtualization [2017/07/24 00:05]
admin [Controlling Virtualization]
+++ image_virtualization [2026/07/22 04:12] (current)
hermann ↷ Page moved from reference_book:image_virtualization to image_virtualization
@@ Line 1: / Line 1: @@
 ====== Image Virtualization ======
-Image virtualization, map virtualization, or even raster virtualization is the name given by Dinamica EGO 4 to the ability of manipulating images with different extents, resolutions or number of lines and columns.
+Image virtualization, map virtualization, raster virtualization, or even multi-resolution are the different names given to the ability to manipulate images with different extents, resolutions, or numbers of lines and columns.
-Previous versions of Dinamica required all maps used as inputs of a model to have the same number of lines and columns (and by consequence the same extents). Dinamica EGO 4 changed this behavior by enforcing the proper use of map projections (all maps used as part of a model must share the same projection) and registration coordinates.
+Older versions of Dinamica required all maps used as inputs of a model to have the same number of lines and columns (and, as a consequence, the same extents). This was changed by enforcing the proper use of map projections (all maps used as part of a model must share the same projection) and registration coordinates.
-===== Requirements =====
+Using only input maps with the same extents and resolution always disables virtualization, producing exactly the same result as in older versions of Dinamica EGO, before virtualization was introduced.
-Map computations in Dinamica since version 4 uses image virtualization to extent and modify at runtime the image dimensions making sure that all images presented to any operator have the same number of lines and columns. This allows images used by any computation to have different dimensions while retaining the ability to run the calculation in parallel at high speed.
-Typically, the only requirement when using virtualization is that all images must share the same projection, although different models can use different projections. It is also possible to use maps with different projections as part of a same model, as long as images with different projections are not given as inputs to the same functors at the same time.
-To facilitate the re-projection of maps ensuring that the projections are the same, a convenient wrapper around the [[http://gdal.org/gdalwarp.html|gdal_warp]] and [[http://gdal.org/gdal_translate.html|gdal_translate]] called [[:Transform Map]] is provided. This functor simply runs those GDAL utilities distributed with Dinamica EGO 4.
-All analysis concerning projections and what they represent are performing internally using [[http://gdal.org/|GDAL]]. However, the map virtualization itself is performing independently by Dinamica.
-====== Image Virtualization ======
-Image virtualization, map virtualization, raster virtualization or even multi-resolution are the names given by Dinamica EGO 4 to the ability of manipulating images with different extents, resolutions or number of lines and columns.
-Previous versions of Dinamica required all maps used as inputs of a model to have the same number of lines and columns (and by consequence the same extents). Dinamica EGO 4 changed this behavior by enforcing the proper use of map projections (all maps used as part of a model must share the same projection) and registration coordinates.
-Using only input maps with the same extents and resolution always disables virtualization and the result produced by models with such input are exactly the same when they are executed by Dinamica EGO version 3 or 4.
 ===== Requirements =====
-Map computations in Dinamica since version 4 uses image virtualization to extent and modify at runtime the image dimensions making sure that all images presented to any operator have the same number of lines and columns. This allows images used by any computation to have different dimensions while retaining the ability to run the calculation in parallel at high speed.
+Map computations in Dinamica use image virtualization to extend and adjust, at runtime, the image dimensions, making sure that all images presented to any operator have the same number of lines and columns. This allows images used by any computation to have different dimensions while retaining the ability to run the calculation in parallel at high speed.
-Typically, the only requirement when using virtualization is that all images must share the same projection and same rotation, although different models can use different projections and rotations((Rotation is related to the where the image north points to. The rotation is non-zero if the image north points toward a direction other than the image top.)). It is also possible to use maps with different projections as part of a same model, as long as images with different projections are not given as inputs to the same functors at the same time.
+Typically, the only requirement when using virtualization is that all images share the same projection and rotation (rotation refers to the direction the image's north points toward, and is non-zero if the image's north points in a direction other than the image's top), although different models can use different projections and rotations. It is also possible to use maps with different projections as part of the same model, as long as images with different projections are not given as inputs to the same functors at the same time.
-{{ reference_book:imagevirtualization3.png?direct&600 |}}
+{{reference_book:imagevirtualization3.png?direct&800|}}
-To facilitate the re-projection of maps ensuring that the projections are the same, a convenient wrapper around the [[http://gdal.org/gdalwarp.html|gdal_warp]] and [[http://gdal.org/gdal_translate.html|gdal_translate]] called [[:Transform Map]] is provided. This functor simply runs those GDAL utilities distributed with Dinamica EGO 4.
+To facilitate the re-projection of maps, ensuring that the projections are the same, a convenient wrapper around [[http://gdal.org/gdalwarp.html|gdal_warp]] and [[http://gdal.org/gdal_translate.html|gdal_translate]] called [[:Transform Map]] is provided. This functor simply runs those GDAL utilities distributed with Dinamica EGO.
-All analysis concerning projections and what they represent are performing internally using [[http://gdal.org/|GDAL]]. However, the map virtualization itself is performing independently by Dinamica.
+All analysis concerning projections and what they represent is performed internally using [[http://gdal.org/|GDAL]]. However, the map virtualization itself is performed independently by Dinamica.
 ===== Virtualization Explained =====
-Versions of Dinamica prior to version 4 could only manipulate maps with the same number of lines and columns. Additional information such as registrations coordinates, resolution etc were not treated uniformly by all functors with many of them simply ignoring this information in the input maps.
+Older versions of Dinamica could only manipulate maps with the same number of lines and columns. Additional information such as registration coordinates, resolution, etc., was not treated uniformly by all functors, and many of them simply ignored this information in the input maps.
-Version 4 handles map extents and resolution in a very uniform way. Basically, when a set of maps is given to a functor, they are first analysed to determine what is the minimum extents and resolution that an input map should have to cover all necessary cells the best possible way. Then, each input map is wrapped around a virtual version of itself with this new resolution and extents. The functor receives those virtual versions and use them to perform the computation. By using this virtualization process, version 4 ensures that all maps given to a functor have the same number of lines and columns, resolution, and extents. It is also worth noting that a same map might have different virtual representation depending on the original set of maps given to a particular functor.
+Dinamica handles map extents and resolution in a very uniform way. Basically, when a set of maps is given to a functor, they are first analyzed to determine the minimum extent and resolution an input map should have to best cover all necessary cells. Then, each input map is wrapped in a virtual version of itself with this new resolution and extent. The functor receives those virtual versions and uses them to perform the computation. By using this virtualization process, Dinamica ensures that all maps given to a functor have the same number of lines and columns, resolution, and extents. It is also worth noting that the same map might have different virtual representations depending on the original set of maps given to a particular functor.
-{{ reference_book:imagevirtualization4.png?direct&600 |}}
+{{reference_book:imagevirtualization4.png?direct&800|}}
-The virtual resolution of the resulting virtual maps is always the smallest resolution from all maps involved in the visualization process. This minimizes the number of cells that have to be analyzed when deciding to what original cell a virtual cell from the virtual map corresponds.
+The virtual resolution of the resulting virtual maps is always the smallest resolution among all maps involved in the virtualization process. This minimizes the number of cells that need to be analyzed when determining which original cell a given virtual cell corresponds to.
-{{ reference_book:imagevirtualization6.png?direct&600 |}}
+{{reference_book:imagevirtualization6.png?direct&800|}}
 ===== Controlling Virtualization =====
-The virtualization process is mostly automatic and happens by simply passing maps with different extents and resolutions to any functor. However, the user can limit the virtualzation process by checking the options available on "Tools -> Options | Advanced | Virtualization". Basically, the user can choose one of the following options.
+The virtualization process is mostly automatic and happens by simply passing maps with different extents and resolutions to any functor. However, the user can constrain the virtualization process using the options available under //Tools// â†’ //Options// | //Advanced// | //Virtualization//. The user can choose one of the following options:
-   * **Off**: Raster map virtualization will be completely disabled. This is equivalent of running a simulation using a previous version of Dinamica EGO. If the maps used by the functors are incompatible, the execution might or might nor work, depending on how the functor behaves internally.
+  * **Not Allowed**: If the simulation needs raster map virtualization to run, an error will be reported. Otherwise, the simulation will run as if using a previous version of Dinamica EGO. It does not have any effect on operations using region managers.
-   * **Not Allowed**: If the simulation needs raster map virtualization to run, an error will be reported. Otherwise, the simulation will run as if using a previous version of Dinamica EGO.
+  * **Unrestricted**: If necessary, raster map virtualization will be used to run the simulations, even if its use results in very large maps compared to the dimensions of the input maps.
-   * **Unrestricted**: If necessary, raster map virtualization will be used to run the simulations, even if its use results in very large maps compared to the dimensions of the input maps.
+  * **Limited**: Raster map virtualization will be used, but only if its use does not result in very large maps compared to the dimensions of the input maps. Otherwise, an error will be reported. It does not have any effect on operations using region managers.
-   * **Limited**: Raster map virtualization will be used, but only if its use does not result in very large maps compared to the dimensions of the input maps. Otherwise, an error will be reported.
-{{ reference_book:imagevirtualization16.png?direct&600 |}}
+{{reference_book:imagevirtualization16.png?direct&800|}}
-The selected corresponding option is also presented in the status bar. Double clicking the corresponding label in the status bar brings the relevant tab from the "Options" dialog, where the "Raster map virtualization" option can be edited.
+The selected option is also presented in the status bar. Double-clicking the corresponding label in the status bar brings up the relevant tab of the //Options// dialog, where the //Raster map virtualization// option can be edited.
 ===== Example =====
@@ Line 64: / Line 47: @@
 The following example shows how virtualization works in practice:
-{{ reference_book:imagevirtualization12.png?direct&600 |}}
+{{reference_book:imagevirtualization12.png?direct&800|}}
 ===== Limitations =====
-Functors [[:Calc Cost Allocation Map]] and [[:Calc Pathway Map]] will always report an error if virtualization is required to make their input maps compatible. The reason behind this behavior is simple: virtualization often replicates a cell turning it into many cells with the same value when the resolution of a map increases, but these functors need the input cost map not to have local minimums. Thus,  replicating a cell would create local minimum and that would prevent these functors from working properly.
+Functors [[:Calc Cost Allocation Map]] and [[:Calc Pathway Map]] will always report an error if virtualization is required to make their input maps compatible. The reason behind this behavior is simple: virtualization often replicates a cell, turning it into many cells with the same value when the resolution of a map increases, but these functors need the input cost map to have no local minimums. Replicating a cell would create a local minimum, which would prevent these functors from working properly.
+Some other functors, such as [[:Extract Map Attributes]] and [[:Extract Categorical Map Attributes]], can produce a result that is different from the result that would be obtained using the original versions of the map. Typically, this is not a problem if the information produced by these functors is used with care. For example, it is safe to extract the number of non-null cells and multiply it by the cell resolution, provided that the values come from the //same// call to [[:Extract Map Attributes]] or [[:Extract Categorical Map Attributes]]. This works because map virtualization changes the cell resolution and the number of non-null cells of a map simultaneously, making the multiplication result consistent with the one that would be obtained using the original version of the map. The same is true for all other attributes.
+It is also worth noting that certain maps should not be mixed with other maps of different extents/resolutions, such as maps representing line features, especially roads. Some algorithms might assume that a road is always exactly one cell wide, and the virtualization process might produce a map where this assumption does not hold.
+{{reference_book:imagevirtualization13.png?direct&800|}}
+{{reference_book:imagevirtualization14.png?direct&800|}}
-Some other functor such as [[:Extract Map Attributes]] and [[:Extract Categorical Map Attributes]] can produce result that is different from the result that would be obtained using the original versions of the map. Typically, this is not a problem if the information produced by these functors is used with care. For example, it is safe to extract the number of non-null cells and multiply by the cell resolution provided that the values are coming from the *same* [[:Extract Map Attributes]] or the *same* [[:Extract Categorical Map Attributes]]. This is possible because map virtualization changes the cell resolution of a map and the number of non-null cells of the map simultaneously, keeping the multiplication result consistent with the one that would be obtained by using the original version of the map. The same is true for all other attributes.
+----
-It is also worth noting that certain maps should not be mixed with other maps with different extents/resolutions such as maps representing line features specially roads. Some algorithms might assume that a road is always only one cell wide and the virtualization process might produce a map where this assumption does not hold.
+===== See Also =====
-{{ reference_book:imagevirtualization13.png?direct&600 |}}
+  * [[:gui_tips#virtualization|Useful Tips for Using the Graphical Interface - Virtualization]]
-{{ reference_book:imagevirtualization14.png?direct&600 |}}