Difference between revisions of "PlanWise Tutorial"

From Heureka Wiki
Jump to navigation Jump to search
Line 50: Line 50:
  
 
===Skapa domäner och skötselgrupper===
 
===Skapa domäner och skötselgrupper===
Toppnivån i ett projekt är analysområdet ("Analysis Area") som innehåller alla behandlingsenheter ("Treatment Units") som ska analyseras. Nästa nivå utgörs av skogsdomänerna ("Forest Domains"). En skogsdomän är en grupp av behandlingsenheter (bestånd) som uppfyller ett eller flera villkor. Villkoren ställs utifrån enheternas ingående tillstånd. Användaren anger villkoren själv och skapar därmed sina egna skogsdomäner. Man kan spara definitionen för skogsdomäner som en mall (i form av en fil på hårddisken). Denna mall kan delas med andra användare. Domäntillhörigheten är statisk genom föreliggande analys (eller kan ett bestånd "växa in" i en ny domän?).
+
Toppnivån i ett projekt är analysområdet ("Analysis Area") som innehåller alla behandlingsenheter ("Treatment Units") som ska analyseras. Nästa nivå utgörs av skogsdomänerna ("Forest Domains"). En skogsdomän är en grupp av behandlingsenheter (bestånd) som uppfyller ett eller flera villkor. Villkoren ställs utifrån enheternas ingående tillstånd. Användaren anger villkoren själv och skapar därmed sina egna skogsdomäner. Man kan spara definitionen för skogsdomäner som en mall (i form av en fil på hårddisken). Denna mall kan delas med andra användare. Domäntillhörigheten är statisk genom föreliggande analys (eller kan ett bestånd "växa in" i en annan domän?).
  
 
I början av en analys tilldelas varje behandlingsenhet en (och endast en) skogsdomän. Domänerna ställs upp i prioritetsordning och utvärderas därefter, så att den domän som står överst utvärderas först. Man kan enkelt ändra i ordningen. Om enheten inte tillhör den första domänen kontrolleras nästa domän, osv. Det finns alltså inga problem med att domäner faktiskt kan överlappa varandra. Den sista domänen är en "restdomän". Denna har inga villkor utan inkluderar alla enheter som inte hamnat i annan domän. Det finns alltså heller inga problem med att ställda villkor "glappar".  
 
I början av en analys tilldelas varje behandlingsenhet en (och endast en) skogsdomän. Domänerna ställs upp i prioritetsordning och utvärderas därefter, så att den domän som står överst utvärderas först. Man kan enkelt ändra i ordningen. Om enheten inte tillhör den första domänen kontrolleras nästa domän, osv. Det finns alltså inga problem med att domäner faktiskt kan överlappa varandra. Den sista domänen är en "restdomän". Denna har inga villkor utan inkluderar alla enheter som inte hamnat i annan domän. Det finns alltså heller inga problem med att ställda villkor "glappar".  
  
Kontrollkategori
+
För varje skogsdomän kan man koppla särskilda skötseldirektiv genom att redigera och skapa nya kontrollkategorier ("Control Categories"). Vi kallar dessa ibland skötselkategorier. En kontrollkategori utgörs av att antal kontrolltabeller. Genom dessa styr man, bland annat, vilka åtgärder som ska simuleras och hur de ska utföras. Genom att skapa en eller flera kontrollkategorier för varje skogsdomän, kan man differentiera skötseln över de olika skogsdomänerna. ''Genom en kontrolltabell av typen "Treatment Program Generator" styr man vilka åtgärder som ska simuleras och till viss del tidpunkter för dessa. Genom en kontrolltabell av typen "Treatment Model" styr man hur åtgärderna ska simuleras (utföras).''
För varje skogsdomän kan man koppla särskilda skötseldirektiv genom att redigera och skapa nya kontrollkategorier. Vi kallar dessa ibland skötselkategorier. En kontrollkategori utgörs av att antal kontrolltabeller. Genom dessa styr man bland annat vilka åtgärder som ska simuleras och hur de ska utföras. Genom att skapa en eller flera kontrollkategorier för varje skogsdomän, kan man differentiera skötseln över olika skogsdomäner.
 
  
  

Revision as of 10:40, 31 March 2009