diff --git a/docs/readthedocs/conf.py b/docs/readthedocs/conf.py
index 4baa6e2ad..7e5c4d238 100644
--- a/docs/readthedocs/conf.py
+++ b/docs/readthedocs/conf.py
@@ -36,6 +36,7 @@
# ones.
extensions = [
'sphinx.ext.autosectionlabel',
+'sphinx.ext.autodoc',
'myst_parser'
]
@@ -51,7 +52,7 @@
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'venv']
-
+source_suffix = ['.rst', '.md']
source_encoding = 'utf-8-sig'
# -- Options for HTML output -------------------------------------------------
diff --git a/docs/readthedocs/io/csvfiles.md b/docs/readthedocs/io/csvfiles.md
new file mode 100644
index 000000000..4e7f38b15
--- /dev/null
+++ b/docs/readthedocs/io/csvfiles.md
@@ -0,0 +1,212 @@
+# csv files
+
+## Naming of files
+
+A naming strategy provides a mapping between model classes and the human readable names of those entities to be used
+within e.g. the data sinks, in which the serialized representation of several objects of this class can be found.
+Currently we offer two different, pre-defined naming strategies, which you might extend to fit your needs:
+
+1. **EntityPersistenceNamingStrategy**:
+ A basic naming strategy that is able to add prefix and suffix to the names of the entities. A flat folder structure
+ is considered. For more details see `Default naming strategy`_.
+2. **HierarchicFileNamingStrategy**:
+ An extended version of the EntityPersistenceNamingStrategy. Additionally, the `Default directory hierarchy`_ is taken
+ into account. Please note, that this directory hierarchy is only meant to be used in conjunction with input models.
+
+However, you can control the behaviour of serialization and de-serialization of models by injecting the desired naming
+strategy you like into `CsvDataSource` and `CsvFileSink`.
+
+## Default naming strategy
+
+There is a default mapping from model class to naming of entities in the case you would like to use csv files for
+(de-)serialization of models.
+You may extend / alter the naming with pre- or suffix by calling `new EntityPersistenceNamingStrategy("prefix","suffix")`.
+
+### Input
+
+| Model | File Name |
+|:----------------------------------|:----------------------------------------------------------------------------------------------|
+| operator | *prefix_*\ operator_input\ *_suffix* |
+| node | *prefix_*\ node_input\ *_suffix* |
+| line | *prefix_*\ line_input\ *_suffix*
*prefix_*\ line_type_input\ *_suffix* |
+| switch | *prefix_*\ switch_input\ *_suffix* |
+| two winding transformer | *prefix_*\ transformer2w_input\ *_suffix*
*prefix_*\ transformer2w_type_input\ *_suffix* |
+| three winding transformer | *prefix_*\ transformer3w_input\ *_suffix*
*prefix_*\ transformer3w_type_input\ *_suffix* |
+| measurement unit | *prefix_*\ measurement_unit_input\ *_suffix* |
+| biomass plant | *prefix_*\ bm_input\ *_suffix*
*prefix_*\ bm_type_input\ *_suffix* |
+| combined heat and power plant | *prefix_*\ chp_input\ *_suffix*
*prefix_*\ chp_type_input\ *_suffix* |
+| electric vehicle | *prefix_*\ ev_input\ *_suffix*
*prefix_*\ ev_type_input\ *_suffix* |
+| electric vehicle charging station | *prefix_*\ evcs_input\ *_suffix* |
+| fixed feed in facility | *prefix_*\ fixed_feed_in_input\ *_suffix* |
+| heat pump | *prefix_*\ hp_input\ *_suffix*
*prefix_*\ hp_type_input\ *_suffix* |
+| load | *prefix_*\ load_input\ *_suffix* |
+| photovoltaic power plant | *prefix_*\ pc_input\ *_suffix* |
+| electrical energy storage | *prefix_*\ storage_input\ *_suffix*
*prefix_*\ storage_type_input\ *_suffix* |
+| wind energy converter | *prefix_*\ wec_input\ *_suffix*
*prefix_*\ wec_type_input\ *_suffix* |
+| schematic node graphic | *prefix_*\ node_graphic_input\ *_suffix* |
+| schematic line graphic | *prefix_*\ line_graphic_input\ *_suffix* |
+
+
+### Time Series
+
+| Model | File Name |
+|:-----------------------|:--------------------------------------------|
+| individual time series | *prefix_*\ its\ *_columnScheme_UUID_suffix* |
+| load profile input | *prefix_*\ rts\ *_profileKey_UUID_suffix* |
+
+
+Let's spend a few more words on the individual time series:
+Those files are meant to carry different types of content - one might give information about wholesale market prices,
+the other is a record of power values provided by a real system.
+To be able to understand, what's inside of the file, the *columnScheme* part of the file name gives insight of it's
+content.
+The following keys are supported until now:
+
+| Key | Information and supported head line |
+|:--------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
+| c | An energy price (e.g. in €/MWh; c stands for charge).
Permissible head line: ``uuid,time,price`` |
+| p | Active power
Permissible head line: ``uuid,time,p`` |
+| pq | Active and reactive power
Permissible head line: ``uuid,time,p,q`` |
+| h | Heat power demand
Permissible head line: ``uuid,time,h`` |
+| ph | Active and heat power
Permissible head line: ``uuid,time,p,h`` |
+| pqh | Active, reactive and heat power
Permissible head line: ``uuid,time,p,q,h`` |
+| weather | Weather information
Permissible head line: ``uuid,time,coordinate,direct_irradiation,diffuse_irradiation,temperature,wind_velocity,wind_direction`` |
+
+
+As the ``uuid`` and ``time`` field are mandatory, they are not mentioned explicitly, here.
+
+### Results
+
+
+| Model | File Name |
+|:----------------------------------|:----------------------------------------------|
+| node | *prefix_*\ node_res\ *_suffix* |
+| line | *prefix_*\ line_res\ *_suffix* |
+| switch | *prefix_*\ switch_res\ *_suffix* |
+| two winding transformer | *prefix_*\ transformer2w_res\ *_suffix* |
+| three winding transformer | *prefix_*\ transformer3w_res\ *_suffix* |
+| biomass plant | *prefix_*\ bm_res\ *_suffix* |
+| combined heat and power plant | *prefix_*\ chp_res\ *_suffix* |
+| electric vehicle | *prefix_*\ ev_res\ *_suffix* |
+| electric vehicle charging station | *prefix_*\ evcs_res\ *_suffix* |
+| fixed feed in | *prefix_*\ fixed_feed_in_res\ *_suffix* |
+| heat pump | *prefix_*\ hp_res\ *_suffix* |
+| load | *prefix_*\ load_res\ *_suffix* |
+| photovoltaic power plant | *prefix_*\ pv_res\ *_suffix* |
+| storage | *prefix_*\ storage_res\ *_suffix* |
+| wind energy converter | *prefix_*\ wec_res\ *_suffix* |
+| thermal house model | *prefix_*\ thermal_house_res\ *_suffix* |
+| cylindrical thermal storage | *prefix_*\ cylindrical_storage_res\ *_suffix* |
+
+
+## Default directory hierarchy
+
+Although there is no fixed structure of files mandatory, there is something, we consider to be a good idea of
+structuring things.
+You may either ship your csv files directly in this structure or compress everything in a .tar.gz file.
+However, following this form, we are able to provide you some helpful tools in obtaining and saving your models a bit
+easier.
+
+
+Default directory hierarchy for input classes
+
+
+
+Default directory hierarchy for result classes
+
+The italic parts are optional and the others are mandatory.
+As you see, this still is a pretty flexible approach, as you only need to provide, what you really need.
+However, note that this hierarchy is only meant to be used in conjunction with input models, yet.
+
+The class `DefaultInputHierarchy` offers some helpful methods to validate and create a default input file
+hierarchy.
+
+## De-serialization (loading models)
+Having an instance of :ref:`Grid Container` is most of the time the target whenever you load your
+grid. It consists of the three main blocks:
+
+1. [Raw grid elements](/models/input/grid/gridcontainer)
+2. [System participants](/models/input/grid/gridcontainer)
+3. [Graphics](/models/input/grid/gridcontainer)
+
+Those blocks are also reflected in the structure of data source interface definitions.
+There is one source for each of the containers, respectively.
+
+
+Class diagram of data sources
+
+As a full data set has references among the models (e.g. a line model points to its' nodes it connects), there is a
+hierarchical structure, in which models have to be loaded.
+Therefore, the different sources have also references among themselves.
+An application example to load an *exampleGrid* from csv files located in `./exampleGrid` could look like this:
+
+
+
+ /* Parameterization */
+ String gridName = "exampleGrid";
+ String csvSep = ",";
+ String folderPath = "./exampleGrid";
+ EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy(); // Default naming strategy
+
+ /* Instantiating sources */
+ TypeSource typeSource = new CsvTypeSource(csvSep, folderPath, namingStrategy);
+ RawGridSource rawGridSource = new CsvRawGridSource(csvSep, folderPath, namingStrategy, typeSource);
+ ThermalSource thermalSource = new CsvThermalSource(csvSep, folderPath, namingStrategy, typeSource);
+ SystemParticipantSource systemParticipantSource = new CsvSystemParticipantSource(
+ csvSep,
+ folderPath,
+ namingStrategy,
+ typeSource,
+ thermalSource,
+ rawGridSource
+ );
+ GraphicSource graphicsSource = new CsvGraphicSource(
+ csvSep,
+ folderPath,
+ namingStrategy,
+ typeSource,
+ rawGridSource
+ );
+
+ /* Loading models */
+ RawGridElements rawGridElements = rawGridSource.getGridData().orElseThrow(
+ () -> new SourceException("Error during reading of raw grid data."));
+ SystemParticipants systemParticipants = systemParticipantSource.getSystemParticipants().orElseThrow(
+ () -> new SourceException("Error during reading of system participant data."));
+ GraphicElements graphicElements = graphicsSource.getGraphicElements().orElseThrow(
+ () -> new SourceException("Error during reading of graphic elements."));
+ JointGridContainer fullGrid = new JointGridContainer(
+ gridName,
+ rawGridElements,
+ systemParticipants,
+ graphicElements
+ );
+
+As observable from the code, it doesn't play a role, where the different parts come from.
+It is also a valid solution, to receive types from file, but participants and raw grid elements from a data base.
+Only prerequisite is an implementation of the different interfaces for the desired data source.
+
+## Serialization (writing models)
+
+Serializing models is a bit easier:
+
+ /* Parameterization */
+ String csvSep = ",";
+ String folderPath = "./exampleGrid";
+ EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy();
+ boolean initEmptyFiles = false;
+
+ /* Instantiating the sink */
+ CsvFileSink sink = new CsvFileSink(folderPath, namingStrategy, initEmptyFiles, csvSep);
+ sink.persistJointGridContainer(grid);
+
+The sink takes a collection of model suitable for serialization and handles the rest (e.g. unboxing of nested models)
+on its own.
+But caveat: As the (csv) writers are implemented in a concurrent, non-blocking way, duplicates of nested models could
+occur.
+
+## Compression and extraction of files
+
+We consider either regular directories or compressed tarball archives
+(`*.tar.gz`) as source of input files.
+The class `TarballUtils` offers some helpful functions to compress or extract input data files for easier shipping.
\ No newline at end of file
diff --git a/docs/readthedocs/io/csvfiles.rst b/docs/readthedocs/io/csvfiles.rst
deleted file mode 100644
index 35ab4b8c8..000000000
--- a/docs/readthedocs/io/csvfiles.rst
+++ /dev/null
@@ -1,292 +0,0 @@
-*********
-csv files
-*********
-
-Naming of files
-===============
-A naming strategy provides a mapping between model classes and the human readable names of those entities to be used
-within e.g. the data sinks, in which the serialized representation of several objects of this class can be found.
-Currently we offer two different, pre-defined naming strategies, which you might extend to fit your needs:
-
-1. **EntityPersistenceNamingStrategy**:
- A basic naming strategy that is able to add prefix and suffix to the names of the entities. A flat folder structure
- is considered. For more details see `Default naming strategy`_.
-2. **HierarchicFileNamingStrategy**:
- An extended version of the EntityPersistenceNamingStrategy. Additionally, the `Default directory hierarchy`_ is taken
- into account. Please note, that this directory hierarchy is only meant to be used in conjunction with input models.
-
-However, you can control the behaviour of serialization and de-serialization of models by injecting the desired naming
-strategy you like into :code:`CsvDataSource` and :code:`CsvFileSink`.
-
-Default naming strategy
-=======================
-There is a default mapping from model class to naming of entities in the case you would like to use csv files for
-(de-)serialization of models.
-You may extend / alter the naming with pre- or suffix by calling :code:`new EntityPersistenceNamingStrategy("prefix","suffix")`.
-
-Input
------
-
-+--------------------------------------------------------+--------------------------------------------------+
-| Model | File Name |
-+========================================================+==================================================+
-| :ref:`operator` | *prefix_*\ operator_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`node` | *prefix_*\ node_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`line` | | *prefix_*\ line_input\ *_suffix* |
-| | | *prefix_*\ line_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`switch` | *prefix_*\ switch_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`two winding transformer` | | *prefix_*\ transformer2w_input\ *_suffix* |
-| | | *prefix_*\ transformer2w_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`three winding transformer` | | *prefix_*\ transformer3w_input\ *_suffix* |
-| | | *prefix_*\ transformer3w_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`measurement unit` | *prefix_*\ measurement_unit_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`biomass plant` | | *prefix_*\ bm_input\ *_suffix* |
-| | | *prefix_*\ bm_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`combined heat and power plant` | | *prefix_*\ chp_input\ *_suffix* |
-| | | *prefix_*\ chp_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electric vehicle` | | *prefix_*\ ev_input\ *_suffix* |
-| | | *prefix_*\ ev_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electric vehicle charging station` | *prefix_*\ evcs_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`fixed feed in facility` | *prefix_*\ fixed_feed_in_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`heat pump` | | *prefix_*\ hp_input\ *_suffix* |
-| | | *prefix_*\ hp_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`load` | *prefix_*\ load_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`photovoltaic power plant` | *prefix_*\ pc_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electrical energy storage` | | *prefix_*\ storage_input\ *_suffix* |
-| | | *prefix_*\ storage_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`wind energy converter` | | *prefix_*\ wec_input\ *_suffix* |
-| | | *prefix_*\ wec_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`schematic node graphic` | *prefix_*\ node_graphic_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`schematic line graphic` | *prefix_*\ line_graphic_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-
-Time Series
------------
-
-+-------------------------------------------------------+---------------------------------------------+
-| Model | File Name |
-+=======================================================+=============================================+
-| :ref:`individual time series` | *prefix_*\ its\ *_columnScheme_UUID_suffix* |
-+-------------------------------------------------------+---------------------------------------------+
-| :ref:`load profile input` | *prefix_*\ rts\ *_profileKey_UUID_suffix* |
-+-------------------------------------------------------+---------------------------------------------+
-
-Let's spend a few more words on the individual time series:
-Those files are meant to carry different types of content - one might give information about wholesale market prices,
-the other is a record of power values provided by a real system.
-To be able to understand, what's inside of the file, the *columnScheme* part of the file name gives insight of it's
-content.
-The following keys are supported until now:
-
-+---------+----------------------------------------------------------------------------------------------------------------+
-| Key | Information and supported head line |
-+=========+================================================================================================================+
-| c | | An energy price (e.g. in €/MWh; c stands for charge). |
-| | | Permissible head line: ``uuid,time,price`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| p | | Active power |
-| | | Permissible head line: ``uuid,time,p`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| pq | | Active and reactive power |
-| | | Permissible head line: ``uuid,time,p,q`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| h | | Heat power demand |
-| | | Permissible head line: ``uuid,time,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| ph | | Active and heat power |
-| | | Permissible head line: ``uuid,time,p,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| pqh | | Active, reactive and heat power |
-| | | Permissible head line: ``uuid,time,p,q,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| weather | | Weather information |
-| | | Permissible head line: |
-| | | ``uuid,time,coordinate,direct_irradiation,diffuse_irradiation,temperature,wind_velocity,wind_direction`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-
-As the ``uuid`` and ``time`` field are mandatory, they are not mentioned explicitly, here.
-
-Results
--------
-
-+---------------------------------------------------------------+-----------------------------------------------+
-| Model | File Name |
-+===============================================================+===============================================+
-| :ref:`node` | *prefix_*\ node_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`line` | *prefix_*\ line_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`switch` | *prefix_*\ switch_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`two winding transformer` | *prefix_*\ transformer2w_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`three winding transformer` | *prefix_*\ transformer3w_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`biomass plant` | *prefix_*\ bm_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`combined heat and power plant` | *prefix_*\ chp_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`electric vehicle` | *prefix_*\ ev_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`electric vehicle charging station` | *prefix_*\ evcs_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`fixed feed in` | *prefix_*\ fixed_feed_in_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`heat pump` | *prefix_*\ hp_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`load` | *prefix_*\ load_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`photovoltaic power plant` | *prefix_*\ pv_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`storage` | *prefix_*\ storage_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`wind energy converter` | *prefix_*\ wec_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`thermal house model` | *prefix_*\ thermal_house_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`cylindrical thermal storage` | *prefix_*\ cylindrical_storage_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-
-Default directory hierarchy
-===========================
-Although there is no fixed structure of files mandatory, there is something, we consider to be a good idea of
-structuring things.
-You may either ship your csv files directly in this structure or compress everything in a .tar.gz file.
-However, following this form, we are able to provide you some helpful tools in obtaining and saving your models a bit
-easier.
-
-.. figure:: ../_static/figures/uml/DefaultInputDirectoryHierarchy.png
- :align: center
- :alt: Default directory hierarchy for input classes
- :width: 650
-
- Default directory hierarchy for input classes
-
-.. figure:: ../_static/figures/uml/DefaultResultDirectoryHierarchy.png
- :align: center
- :alt: Default directory hierarchy for result classes
- :width: 650
-
- Default directory hierarchy for result classes
-
-The italic parts are optional and the others are mandatory.
-As you see, this still is a pretty flexible approach, as you only need to provide, what you really need.
-However, note that this hierarchy is only meant to be used in conjunction with input models, yet.
-
-The class :code:`DefaultInputHierarchy` offers some helpful methods to validate and create a default input file
-hierarchy.
-
-De-serialization (loading models)
-=================================
-Having an instance of :ref:`Grid Container` is most of the time the target whenever you load your
-grid. It consists of the three main blocks:
-
- 1. :ref:`Raw grid elements`
- 2. :ref:`System participants`
- 3. :ref:`Graphics`
-
-Those blocks are also reflected in the structure of data source interface definitions.
-There is one source for each of the containers, respectively.
-
-.. figure:: ../_static/figures/uml/DataSourceClassDiagram.png
- :align: center
- :alt: Class diagram of data sources
- :width: 650
-
- Class diagram of data sources
-
-As a full data set has references among the models (e.g. a line model points to its' nodes it connects), there is a
-hierarchical structure, in which models have to be loaded.
-Therefore, the different sources have also references among themselves.
-An application example to load an *exampleGrid* from csv files located in :code:`./exampleGrid` could look like this:
-
-.. code-block:: java
-
- /* Parameterization */
- String gridName = "exampleGrid";
- String csvSep = ",";
- String folderPath = "./exampleGrid";
- EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy(); // Default naming strategy
-
- /* Instantiating sources */
- TypeSource typeSource = new CsvTypeSource(csvSep, folderPath, namingStrategy);
- RawGridSource rawGridSource = new CsvRawGridSource(csvSep, folderPath, namingStrategy, typeSource);
- ThermalSource thermalSource = new CsvThermalSource(csvSep, folderPath, namingStrategy, typeSource);
- SystemParticipantSource systemParticipantSource = new CsvSystemParticipantSource(
- csvSep,
- folderPath,
- namingStrategy,
- typeSource,
- thermalSource,
- rawGridSource
- );
- GraphicSource graphicsSource = new CsvGraphicSource(
- csvSep,
- folderPath,
- namingStrategy,
- typeSource,
- rawGridSource
- );
-
- /* Loading models */
- RawGridElements rawGridElements = rawGridSource.getGridData().orElseThrow(
- () -> new SourceException("Error during reading of raw grid data."));
- SystemParticipants systemParticipants = systemParticipantSource.getSystemParticipants().orElseThrow(
- () -> new SourceException("Error during reading of system participant data."));
- GraphicElements graphicElements = graphicsSource.getGraphicElements().orElseThrow(
- () -> new SourceException("Error during reading of graphic elements."));
- JointGridContainer fullGrid = new JointGridContainer(
- gridName,
- rawGridElements,
- systemParticipants,
- graphicElements
- );
-
-As observable from the code, it doesn't play a role, where the different parts come from.
-It is also a valid solution, to receive types from file, but participants and raw grid elements from a data base.
-Only prerequisite is an implementation of the different interfaces for the desired data source.
-
-Serialization (writing models)
-==============================
-Serializing models is a bit easier:
-
-.. code-block:: java
-
- /* Parameterization */
- String csvSep = ",";
- String folderPath = "./exampleGrid";
- EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy();
- boolean initEmptyFiles = false;
-
- /* Instantiating the sink */
- CsvFileSink sink = new CsvFileSink(folderPath, namingStrategy, initEmptyFiles, csvSep);
- sink.persistJointGridContainer(grid);
-
-The sink takes a collection of model suitable for serialization and handles the rest (e.g. unboxing of nested models)
-on its own.
-But caveat: As the (csv) writers are implemented in a concurrent, non-blocking way, duplicates of nested models could
-occur.
-
-Compression and extraction of files
-===================================
-We consider either regular directories or compressed `tarball archives `_
-(:code:`*.tar.gz`) as source of input files.
-The class :code:`TarballUtils` offers some helpful functions to compress or extract input data files for easier shipping.
\ No newline at end of file
diff --git a/docs/readthedocs/io/source/idcoordinatesource.md b/docs/readthedocs/io/source/idcoordinatesource.md
index 10e532290..e0e52a5c1 100644
--- a/docs/readthedocs/io/source/idcoordinatesource.md
+++ b/docs/readthedocs/io/source/idcoordinatesource.md
@@ -5,7 +5,7 @@ methods to get coordinates, ids of coordinates or the distance between a given c
coordinates.
-### Information
+## Information
| Attribute | Remarks |
|:-------------|:-------------------------------------------------------------|
@@ -14,7 +14,7 @@ coordinates.
-### Known implementations:
+## Known implementations:
The following implementations are currently known:
- [Csv Id Coordinate Source](/io/csvfiles)
diff --git a/docs/readthedocs/io/sql.md b/docs/readthedocs/io/sql.md
index a3bb3fb32..b00cfaeee 100644
--- a/docs/readthedocs/io/sql.md
+++ b/docs/readthedocs/io/sql.md
@@ -1,7 +1,7 @@
# Sql
-### Id Coordinate Source
+## Id Coordinate Source
The sql implementation of id coordinate source uses PostgreSql with the
addon PostGis. `PostGis` is used to improve the querying of geographical data.
The `Coordinate` attribute is stored as a geometry (point).
diff --git a/docs/readthedocs/requirements.txt b/docs/readthedocs/requirements.txt
index 7560bb93d..d4e323ba6 100644
--- a/docs/readthedocs/requirements.txt
+++ b/docs/readthedocs/requirements.txt
@@ -1,6 +1,6 @@
-commonmark==0.9.1
+commonmark==0.21.0
recommonmark==0.7.1
Sphinx==5.3.0
sphinx-rtd-theme==1.2.0
-myst-parser==0.17.2
+myst-parser==0.18.1
markdown-it-py==2.1.0
\ No newline at end of file