# Concept of the Integration of INSEL models into SimStadt

The main concept to integrate INSEL models into SimStadt is to introduce a SimStadt Workflow step *INSEL templater* that is able to  

1. read an INSEL template
2. writes an INSEL model per feature of interest based on the INSEL template
3. executes the INSEL model
4. reads the results written by the INSEL process and maps the resulting values to the SimStadt data model

In a first prototype, the INSEL template is restricted to variables only. The feature of interest are buildings. For the implementation, the Java-Library handlebars (https://github.com/jknack/handlebars.java) has been choosen. That iomplies that a variable in the INSEL template has been encapsulated by two brackets: {{name of variable}}. To avoid an additional mapping between variables in teh INSEL template and attributes in the SimStadt data model, the names of the variables in the INSEL template have to be the same as in the SimStadt data model.

Example: 

This statement in an INSEL template 

[source,java]
----
{{building.yearOfConstruction}} 
----

will be replaced by the value of the attribute _yearOfConstruction_ of the class _Building_ in the INSEL model by the INSEL templater Workflow step per building. 

If an attribute is not set in an instance of an object in SimStadt, a default value can be defined in the template:

[source,java]
----
{{getOrDefault building.yearOfConstruction 9999}}
----

In this example, yearOf Construction is set to 9999 if not available for a specific building.

The following example shows an INSEL template that write the yearOfConstruction per building. The INSEL templater read the template and generate an INSEL model per building by replacing the variables {{building.yearOfConstruction}} and {{building.gmlId}} with the attributes of each instance of the class _Building_. The variable {{step.location}} is always replaced by the same attribute of the workflow step.

[source]
----
b 1 DO
p 1
           1
          {{getOrDefault building.yearOfConstruction 9999}}
           1
b 2 WRITE  1.1
p 2
           1
           0
    '{{step.location}}/OneToN-{{building.gmlId}}.txt'
    '*'
----

The resulting INSEL model generated for a specific _Building_ be the workflow step may look like this:

[source]
----
b 1 DO
p 1
    1
    1980
    1
b 2 WRITE  1.1
p 2
    1
    0
    './OneToN-gmlid01.txt'
    '*'
----

Running this INSEL model writes a file that contains all number from 1 to the year of construction of the building. If the workflow is applied to a CityGML model with 150 _Buildings_, 150 INSEL models will be stored and executed, and the same amount of resulting files will be written.
