Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
reference_book:image_virtualization [2017/07/23 22:41]
admin
reference_book:image_virtualization [2017/07/24 00:05]
admin [Controlling Virtualization]
Line 11: Line 11:
 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. 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.+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. 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.
Line 31: Line 31:
 {{ reference_book:​imagevirtualization3.png?​direct&​600 |}} {{ reference_book:​imagevirtualization3.png?​direct&​600 |}}
  
-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 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. 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.
Line 56: Line 56:
    * **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.    * **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.
  
-{{ :virtualization_settings.png?​direct&​500 |}}+{{ reference_book:imagevirtualization16.png?​direct&​600 |}} 
 + 
 +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.
  
 ===== Example ===== ===== Example =====
Line 66: Line 68:
 ===== Limitations ===== ===== 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 not to have local minimums. Thus,  replicating a cell would create local minimum and that would prevent these functors from working properly.
  
-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.+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.  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.