Session: Difference between revisions

From Tygron Preview Support Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page is about the concept of live sessions of projects within the {{software}}. For information on organizing an impact session with stakeholders, see [[Project Session]].
A session is a means for interacting with [[Project]]s in the {{software}}. A session has several phases:


A session is a means for interacting with Projects in the {{software}}. A session has several stages:
* ''Project startup phase'', in which an existing project is initiated into computer memory.
 
* An optional ''project wizard phase'', in which geo-options can be configured and geo-data for the project area is obtained and combined to setup the initial geometric data of a project.
* Project startup phase, in which the project is initiated into computer memory.
* A ''live phase'', in which one or more users can interact with the project.
* A live phase, in which one or more users can interact with the project.
* A ''calculation phase'', in which the session calculates overlays, indicators and other results while restricting the interaction with the project.
* A save phase, in which the project data is stored from memory to hard disk.
* A ''save phase'', in which the project data is stored from memory to hard disk.
* A close phase, in which the session's processes are neatly terminated and the session's data is removed from memory.
* A ''close phase'', in which the session's processes are neatly terminated and the session's data is removed from memory.


A session can be interacted with by multiple users at the same time. A session will generally be shut down once all users have logged out of the session. However, when chosen, a session can also be kept alive for longer periods of time.  
A session can be interacted with by multiple users at the same time. A session will generally be shut down once all users have logged out of the session. However, when chosen, a session can also be kept alive for longer periods of time.  


There are several reasons to keep a session alive:
There are several reasons to keep a session alive:
* The user has to wait on a result of a long computation.
* The user has to wait on a result of a long computation and will likely have to log out of the session for a period of time.
* The project acts as a web service, such as WFS or WMS and can be updated in the mean time.
* The project acts as a web service, such as WFS or WMS and can be updated by users at the mean time.


Interaction with a session can be restricted in functionality, based on the chosen startup mode.
Using a session to interact with project data has several advantages. Most importantly, it can speed up the calculation time of complicated indicators and overlays by re-using unchanged rasterization of its data. Secondly, the session can govern which actions on your project data are allowed and in which sequence they are handled and provide feedback on why they may have failed. It can also manage the automatic calculation of indicators, overlays and other results for each applied action individually.
* Editor mode allows users to adjust the initial state of a project. Additionally, test-runs can be activated within this session to test future scenarios. A restriction with the session system is that only one Editor mode session can be active for a project at the same time. Other restrictions concerning test-runs in editor mode can be found [[#Editor Test Runs|here]].
* Single and multi-user mode allows users to only adjust the future state of a project. The initial state will remain the same, and indicators and overlays can refer to this initial state to show the improvements and progress being made. These sessions can be saved, to continue with it at a later time.


Using a session to interact with project data has several advantages. Most importantly, it can speed up the calculation time of complicated indicators and overlays by re-using unchanged rasterization of its data. Secondly, the session can govern which actions on your project data are allowed and in which sequence they are handled and provide feedback on why they may have failed. It can also manage the automatic calculation of indicators, overlays and other results for each applied action individually.
==Session types==
Interaction with a session can be restricted in functionality, based on the chosen type:
* '''Editor mode''' allows users to adjust the initial state of a project. Additionally, test-runs can be activated within this session to test future scenarios. A restriction with the session system is that only one Editor mode session can be active for a project at the same time. Other restrictions concerning test-runs in editor mode can be found [[#Editor Test Runs|here]].
* '''Single and multi-user mode''' allows users to only adjust the future state of a project. The initial state will remain the same, and indicators and overlays can refer to this initial state to show the improvements and progress being made. These sessions can be saved, to continue with it at a later time.


==Editor Test Runs==
===Editor Test Runs===
Editor test runs are a special mode within editor sessions of a project.  
Editor test runs are a special mode within ''editor sessions'' of a project.  


An editor test run starts a multi-stakeholder session with the same functionality, with the exception that it is not able to save its actions and results. Stopping a editor test run with return the state of the project back to state it was when the test-run was started. Note that starting a test run does not mean the project initial state is also stored to the project data on harddisk; It is only stored within the session.
An editor test run starts a multi-stakeholder session with the same functionality, with the exception that it is not able to save its actions and results. Stopping a editor test run with return the state of the project back to state it was when the test-run was started. Note that starting a test run does not mean the project initial state is also stored to the project data on harddisk; It is only stored within the session.


Also important to note is that an editor session is either in editor or test-run mode for all users within that session. This means that when one user starts a test run, all users will be in a test run. It is therefore important to communicate with each other when editing the same project at the same time.
Also important to note is that an editor session is either in editor or test-run mode for all users within that session. This means that when one user starts a test run, all users will be in a test run. It is therefore important to communicate with each other when editing the same project at the same time.
===Planning Session===
A session is considered a planning session when it is either started as a ''single or multi-user session'', or when a Test run is activated while in an editor session.
In planning sessions, the focus lies on spatial design, to improve the situation of an area compared to the original situation. Alterations to the area are done in the '''Planned View'''. The '''Original View''' contains the area in a state as it was at the beginning of the session. Stakeholders are able to revert and redesign the area from their perspective at will. Stakeholders are free to undo their actions and change their plans.
{{article end
|seealso=
* [[Project]]
* [[SimState]]
* [[Test Run]]
}}

Latest revision as of 11:00, 21 February 2023

A session is a means for interacting with Projects in the Tygron Platform. A session has several phases:

  • Project startup phase, in which an existing project is initiated into computer memory.
  • An optional project wizard phase, in which geo-options can be configured and geo-data for the project area is obtained and combined to setup the initial geometric data of a project.
  • A live phase, in which one or more users can interact with the project.
  • A calculation phase, in which the session calculates overlays, indicators and other results while restricting the interaction with the project.
  • A save phase, in which the project data is stored from memory to hard disk.
  • A close phase, in which the session's processes are neatly terminated and the session's data is removed from memory.

A session can be interacted with by multiple users at the same time. A session will generally be shut down once all users have logged out of the session. However, when chosen, a session can also be kept alive for longer periods of time.

There are several reasons to keep a session alive:

  • The user has to wait on a result of a long computation and will likely have to log out of the session for a period of time.
  • The project acts as a web service, such as WFS or WMS and can be updated by users at the mean time.

Using a session to interact with project data has several advantages. Most importantly, it can speed up the calculation time of complicated indicators and overlays by re-using unchanged rasterization of its data. Secondly, the session can govern which actions on your project data are allowed and in which sequence they are handled and provide feedback on why they may have failed. It can also manage the automatic calculation of indicators, overlays and other results for each applied action individually.

Session types

Interaction with a session can be restricted in functionality, based on the chosen type:

  • Editor mode allows users to adjust the initial state of a project. Additionally, test-runs can be activated within this session to test future scenarios. A restriction with the session system is that only one Editor mode session can be active for a project at the same time. Other restrictions concerning test-runs in editor mode can be found here.
  • Single and multi-user mode allows users to only adjust the future state of a project. The initial state will remain the same, and indicators and overlays can refer to this initial state to show the improvements and progress being made. These sessions can be saved, to continue with it at a later time.

Editor Test Runs

Editor test runs are a special mode within editor sessions of a project.

An editor test run starts a multi-stakeholder session with the same functionality, with the exception that it is not able to save its actions and results. Stopping a editor test run with return the state of the project back to state it was when the test-run was started. Note that starting a test run does not mean the project initial state is also stored to the project data on harddisk; It is only stored within the session.

Also important to note is that an editor session is either in editor or test-run mode for all users within that session. This means that when one user starts a test run, all users will be in a test run. It is therefore important to communicate with each other when editing the same project at the same time.

Planning Session

A session is considered a planning session when it is either started as a single or multi-user session, or when a Test run is activated while in an editor session.

In planning sessions, the focus lies on spatial design, to improve the situation of an area compared to the original situation. Alterations to the area are done in the Planned View. The Original View contains the area in a state as it was at the beginning of the session. Stakeholders are able to revert and redesign the area from their perspective at will. Stakeholders are free to undo their actions and change their plans.