Last modified: 16.9.2024

SIKURS zurückgestellte Punkte

Inhaltsverzeichnis, aktuelle Punkte, zurückgestellte Punkte, erledigte Punkte

  1. s Umsetzung Differenzierung Eckwerte nach Gebiet (h,0A,v,Z:,B:)
    Eine wahlweise Differenzierung der Eckwerte für Geburten (eckgeb), Sterbefälle (eckstrb), Zuzug (zuvol), Wegzug (wegvol) zusätzlich nach Gebiet:
    Aufspaltung Baustein "L Zielwert für die natürliche Bevölkerungsbewegung" in Baustein G (Zielwert Geburten) und S (Zielwert Sterbefälle) (Baustein "G Generische Daten" in Laufzeitparameter umwandeln) (erledigt siehe 030)
    zuvol: Baustein K erweitern (erledigt siehe 031)
    wegvol: Baustein C erweitern (erledigt siehe 031)
    Notwendig sind noch:
  2. s Division durch Null (h,0A,v,Z:,B:)
    Der Zuzug in den Zieltyp Außenzuwanderung 7, Bevölkerungsgruppe 2, Geschlechtsgruppe 1, Altersgruppe 97 ergibt sich aus zuvol, zudq und zuaq und sei ZT[7][2][1][97] = 100.
    Der Zieltyp Außenzuwanderung 7 bestehe aus 20 Gebieten u.a. Gebiet Nummer 143.
    Die Aufteilung der Zuwanderung auf eines dieser Gebiete ZG erfolgt im Verhältnis der Gebietsbevölkerung BG zur Typebevölkerung BT:
    ZG[143][7][2][1][97] = ZT[7][2][1][97] * BG[143][7][2][1][97] / BT[7][2][1][97]
    Wenn BT[7][2][1][97] Null ist muss eine Ersatzformel verwendet werden.
    Derzeit wird in diesem Fall der Zuzug ZT gleichmäßig auf alle Gebiete verteilt, im Beispiel 100/20=5.
    Dieses Verfahren ist bei grobkörnigen Prognosen vertretbar, weil leere Altergruppen kaum vorkommen und wenn dann nur prozentual wenig Köpfe zu verteilen sind.
    Da sich SIKURS inzwischen technisch für feinkörnige Prognosen eignet, werden vermutlich auch häufiger feinkörnige Prognosen gerechnet (siehe auch Handbuch zu diesem Thema).
    Bei feinkörnigen Prognosen sind leere Altergruppen der Regelfall, so dass Methodenexperten und Anwender Alternativen diskutieren sollten.
    Eine Alternative aus Programmierersicht wäre folgendes Eskalationsschema:
    Wenn BT[7][2][1][97] gleich Null ist, dann aggregiere BT[7][2][1] über die Altersgruppe.
    Wenn das Aggregat Null ist, dann aggregiere auch noch über die Geschlechtsgruppe und notfalls über die Bevölkerungsgruppe.
    Ist auch dieses Aggregat gleich Null, dann verteile ZT gleichmäßig auf die Gebiete, sonst im Verhältnis BG in der gleichen Aggregatsstufe wie BG zu BT.
  3. s Vorgehensweise für eine Mikrosimulation (h,0A,v,Z:,B:)
    Für eine Mikrosimulation mit SIKURS gibt es folgende Ansätze In diesen Fällen kann es sinnvoll sein zweistufig vorzugehen (Siehe Benutzerhandbuch "Mikrosimulation")
    1. ermittle angepasste Raten auf Basis einer SIKURS Prognose über aggregierte Daten
    2. Mikrosimulation mit den angepassten Raten
    3. Haushalteprognose als Mikrosimulation
      Statt einer Adeton-Anpassung der Haushalte an eine grobkörnige SIKURS-Prognose kann man eine feinkörnige SIKURS-Prognose mit Gebiet = Haushalt durchführen.
      Zu klären ist, wie folgende Daten aus ersterer Prognose ermittelt werden können
      • Haupt-/Nebenwohnsitzler, Faktor wohnberechtigte Bevölkerung
      • Aggregat person.csv mit Gebiet, Typ, PDO, Geschlecht, Altersgruppe, HDO, Anzahl
      • Aggregat haushalt.csv mit Gebiet, Typ, HDO, Haushaltsgröße, Anzahl
      • Aggregat hdo2.csv mit Gebiet, Typ, HDO2, Anzahl
      • Aggregat kinder.csv mit Gebiet, Typ, Anzahl Kinder, Anzahl Haushalte
      Evtl. müssen weitere Merkmale für die Haushaltsstruktur aus dstbest in die gem-Datei aufgenommen werden.
      Bei (Außen-zu/weg, Binnen)-Wanderungen braucht man eine Möglichkeit ganze Haushalte wandern zu lassen.
      Bei Binnenwanderung könnte die so aussehen:
      Eine neue Eingabedatei: 
      HHSTRM.csv - Binnenwanderungsrate Haushalte
#von;nach;Rate
...
21;34;0,03
...
      Die Verarbeitung könnte so erfolgen: 
      Über alle Einzelpersonen
sammle Haushalt
wenn nach Haushalt nach HHSTRM und Monte-Carlo umzieht
    lösche Haushalt und füge ihn als "nach" ohne laufende Nummer in Warteschlange ein
führe Einzelpersonen und Warteschlange mit neuer lfd zusammen
  4. h Überarbeitung Spzezifikation HHPROG bezüglich Null im Nenner (h,0A,v,Z:,B:)
    Bei kleinräumigen Prognosen, d.h. wenn man viele Stellen von R02 verwendet, und die Schlüssel auf viele Blöcke abbildet. sind viele Quoten nicht definiert, weil sie im Zähler und Nenner eine Null enthalten, z.B.
    Q10(g,t,a) = SPK(g,t,a)/SP(g,t,a)
    Die Spezifikation sollte auf diese Problematik eingehen, mit folgenden denkbaren Antworten
  5. h Umsetzung SIKURS konformes Alter (h,0A,v,Z:,B:)
    Eingabedaten/Berechnen/Makrodaten aus dst
    [ 1] Altersberechnungsmethode/(A01)|Z01|Z02
    Das Alter A01 wird aus Ereignisdatum, Z02 - Geburtsdatum, P01 ermittelt;
    Monat und Tag werden berücksichtigt. Für die "normalen" statistischen Auswertungen ist das so korrekt.

    In SIKURS sollte aber nur das Jahr verarbeitet werden, damit es zur Logik von SIKURS passt. Das wäre dann Z02jjjj - P01jjjj. Da es bei der Berechnung mit dem Ereignisdatum im betrachteten Verarbeitungsjahr aber Bewegungen geben kann, die längere Zeit zurückliegen, könnte dies die Raten verfälschen.
    Als Ersatzlösung hat Frau Lux-Henseler vorgeschlagen, das Verarbeitungsdatum zu nehmen, weil die Bewegung erst im Verarbeitungsjahr bestandsverändernd wirksam werden. Ihre Berechnung Z01 - P01 und zwar nur das Jahr wäre dann Ok. Aus meiner Sicht sollte Herr Dr. Tüllmann dies noch mal in Bezug auf SIKURS durchdenken.

    In Tests wollen wir jetzt herausfinden, ob sich Z01 oder Z02 - und zwar immer nur das Jahr - besser für den Altersindex eignen. Ich habe vor Jahren schon mal ähnliche Tests gemacht und die Bewegungen mal nach Verarbeitungsjahr und mal nach Ereignisjahr ermittelt. Die berechneten Raten und das Prognoseergebnis haben sich nur minimal unterschieden. Ähnlich vermute ich, wird der Vergleich Z01 / Z02 ausgehen.

    Wenn das Ergebnis der Analsyse vorliegt, kann die Umsetzung geplant werden 

    A01 226 03 I Alter der Person
P01 109 08 I Geburtsdatum (JJJJMMTT)
Z01 148 08 I Verarbeitungsdatum (JJJJMMTT)   
Z02 156 08 I Ereignisdatum (JJJJMMTT)
  6. i Graphikformate (h,0A,v,Z:,B:)
    die Situation bei Graphikformaten ist unübersichtlich Mögliche Entscheidungen
    1. Erstellung aller Graphiken mit gnuplot und Nutzung weniger gnuplot Formate (wxt, gif, png, svg)
    2. Einsatz von HTML5-Techniken svg und canvas
    3. Verzicht auf die dynamische Anpassung von Graphiken (Dendrogramm, Pyramide, Stromkreise) auf die Größe des Browserfensters und Ausgabe aller Graphiken als (animated) gif.
    4. Prüfung Plotly als Alternative
  7. t Datenbank für Ein-/Ausgabe-/Versions-Dateien (h,0A,v,Z:,B:)
    Die in SIKURS verwendeten csv-Dateien sind fehleranfällig, weil beim editieren mit Excel oder einem Texteditor Unsinn passieren kann. Die natürliche Speicherform für SIKURS ist eine Datenbank. Das Jahr ist immer in Spalte 1, d.h. es entfällt die Konstruktion, dass das Jahr manchmal in Spalte 1, manchmal im Dateinamen, bei GEM in Spalte 1 und Dateinamen steht. Für GEM bedeutet dies, dass sowohl das Jahr, das als Eingabe für die Prognose dient, als auch alle prognostozierten Jahre in der gleichen Tabelle GEM befinden.
    Damit sind die Eingabedateien:
    ATTR Jahr, GKZ, Wert
    BGWQG Jahr, TYg, BGm, BGk, Wert
    BGWR Jahr, TYw, BGv, BGn, GG, AG, Wert
    DSGA/R Jahr, GKZ, BG, GG, AG
    ECKGEB Jahr, Wert
    ECKGEM Jahr, Index, Gebietsnummer, Wert
    ECKREG Jahr, BG, GG, AG, Wert
    ECKSTRB Jahr, Wert
    ECKSTRBG Jahr, GKZ, Wert
    ECKTYP Jahr, Index, TYb, Wert
    FRUC Jahr, TYf, BG, AG, Wert
    GEM Jahr, GKZ, BG, GG, AG, Wert
    NEBQ Jahr, TYq, BG, GG, AG
    NEBB Jahr, GKZ, Wert
    NEBGQT Jahr, TYn, TYb, Wert
    NEBQQA Jahr, TYn, TYa, Wert
    REAB Jahr, GKZ, Wert
    REAQ Jahr, TYr, BG, GG, AG
    REAQZA Jahr, TYr, TYa, Wert
    REAQZT Jahr, TYr, TYb, Wert
    REAR Jahr, GKZ, Wert
    SADVOL Jahr, TYs, BG, GG, AG, Wert
    STRB Jahr, TYs, BG, GG, AG, Wert
    STRM Jahr, TYxv, TYxn, BG, GG, AG, Wert
    WEGVOL Jahr, TYA, BG, GG, Wert
    WEGT Jahr, TYa, BG, GG, AG, Wert
    WEGV Jahr, TYa, BG, GG, AG, Wert
    WEGZ Jahr, TYx, TYa, BG, GG, Wert
    ZUAQ Jahr, TYa, TYx, BG, GG, AG, Wert
    ZUDQ Jahr, TYa, BG, GG, AG, Wert
    ZUVOL Jahr, TYa, BG, GG, Wert
    ZUVG Jahr, TYa, GKZ, BG, GG, AG, Wert
    ZUVL Jahr, TYa, TYz, BG, GG, AG, Wert
    GKZ sollte durch eine aufsteigende lückenlose GNR (Gebietsnummer) ersetzt werden, dann sind alle Daten mehrdimensionale Matrizen, die von den unterschiedlichsten Tools einheitlich verarbeitet werden können. Für Ausgaben kann GKZ über ein SQL-join jederzeit eingefügt werden.
    Die Eingabedateien GEMREF, TYPREF und AGGREF sind unter 74 beschrieben, die ini-Datei wird ersetzt durch eine Tabelle mit vielen Spalten (Startjahr, Endjahr, EPS, ...).

    Die csv-Ausgabedateien:

    AGG - entfällt, wird bei Bedarf aus GEM gebildet
    B Jahr, GKZ, Art, BG, GG, AG, Wert -- differenzierte Bewegungen
    BEWAGG - erfällt, wird bei Bedarf aus B gebildet
    BEWGEM - erfällt, wird bei Bedarf aus B gebildet
    GEMYYYY - Daten sind in GEM
    PYRAMID - entfällt, wird ad hoc gebildet
    STROM Jahr, TYx, TYx, BG, GG, AG, Wert
    WEGZUG - erfällt, wird bei Bedarf aus B gebildet

    Vorzusehen sind Dienstprogramme zum Import und Export in die Formate csv und xls. Beim Import werden die Daten auf Konsistenz geprüft. In der Datenbank sind die Daten immer expandiert, die Rolle der Generic-Daten wird von einem generic-Importprogramm übernommen.

    Das Konzept enthält noch nicht die Verwaltung mehrerer Prognosevarianten mit den gleichen Daten. Dazu sind folgende Erweiterungen nötig

    Die zu verwendende Datenbank muss Schnittstellen zu C++ und Perl besitzen. Mögliche Datenbanken sind (Duva ist mehr als eine Datenbank und kann schon jetzt zur Verwaltung der SIKURS Daten verwendet werden), snowflake, Exasol, Oracle, DB2, Access, FoxPro, SQL-Server, MariaDB, MySQL, Postgres, Apache Derby, BerkeleyDB, dBase, Filemaker, Firebird, Interbase, MaxDB, Paradox, SQLite, DuckDB, HDF5.

    SQLite
    wurde getestet uns scheint sich zu eignen.
    Es gibt einen Prototyp für die Bausteinkombinationen I0-1, K0-4
    Man wählt eine vorhandene ini-Datei und das Programm sqlite.pl lädt alle Eingabdateien und Laufparameter in die Datenbank sqlite.db3.
    Der Prototyp sikern.exe rechnet die Prognose auf der Datenbank.
    SQLite ist eine open source Datenbank, sie wird beispielsweise von FireFox (ab Version 3?), Google-Gears und Adobe AIR verwendet.
    Mit dem FireFox-Plugin SQLite Manager kann man eine SQLite Datenbank bearbeiten (ähnlich Access oder Open Office Datenbankmanager).
    Bei Perl (und PHP) ist sie im Standard-Lieferumfang. Die C/C++-Schnittstelle ist in den frei verfügbaren Quellen enthalten. Zu klären ist, ob es Versionsprobleme zwischen Perl und C++ gibt. Eine Datenbank mit vielen Tabellen entspricht einer Datei.
    Die Organisation der vielen Protokolldateien ist noch festzulegen
    Beispiel: Alle Daten einer Prognose liegen im Verzeichnis NBG mit der Datei PROGNOSE.DB3, INDEX.HTML und dem Unterverzeichnis P
    DuckDB
    ist eine in-process OLAP SQL Datenbank mit Python/R/C++-Schnittstelle und Import/Export von csv und parquet-Dateien
    parquet - Dateien sind eine effiziente Alternative für csv-Dateien.
    Zum Test kann mat mit dem cli-Interface von DuckDB eine csv-Datei aggregieren 
    SELECT BG, GG, sum(Anzahl) FROM read_csv_auto('gem1991.csv', decimal_separator=',') GROUP BY BG, GG;
┌───────┬───────┬────────────────────┐
│  BG   │  GG   │   sum("Anzahl")    │
│ int64 │ int64 │       double       │
├───────┼───────┼────────────────────┤
│     1 │     1 │        42867.39071 │
│     1 │     2 │ 47199.813660000014 │
│     2 │     1 │         7034.68125 │
│     2 │     2 │  5508.755260000002 │
└───────┴───────┴────────────────────┘
    eine csv-Datei in eine parquet-Datei umwandeln: 
    COPY (SELECT * from read_csv_auto('gem1991.csv')) TO 'gem1991.parquet' (FORMAT 'parquet');
    HDF5
    HDF5 verwaltet ein hierarchische Sammlung mehrdimensionaler Matrizen, HDF5 ist eine Instanz des im Penta-Projekt geforderten Penta-Quaders.
    Eine HDF5 Datei könnte die Daten aller Eingabedateien eines SIKURS-Datenverzeichnisses (REFTYP, GEM, FRUC, STRB, ...) sowie aller Ausgabdateien aller Versionsuntervezeichnisse (GEM, BEW, ...) enthalten.
    Die Daten werden selbsbeschreibend, plattformübergreifend, binär, kompakt mit schnellem Zugriff gespeichert.
    Möglicherweise ist die Perl-Schnittstelle PDL::IO::HDF nicht brauchbar.
    Soll der Statistikdatensatz in eine Datenbank aufgenommen werden ?
    Der Autor ist skeptisch, falls doch, muss die Spaltenstruktur diskutiert werden. Naheliegend ist es den Statistikdatensatz mit einem C++-Programm zu lesen und die Makrodaten in die Datenbank einzufügen.
  8. t Karte mit Beulen (h,0A,v,Z:,B:)
    siehe Spiegel

    Sehr geehrter Herr Braunschober,

    folgende Beschreibung stammt von meinem Kollegen Chris Kurt, der sich mit der technischen Seite unserer Visualisierung beschäftigt hat:

    There are two maps with 96 regions of Germany build from free Shapefiles (http://de.wikipedia.org/wiki/Shapefile) and converted with Python (https://www.python.org/) into TopoJson-files (http://en.wikipedia.org/wiki/TopoJSON). The distortion of the map is done with a Javascript Cartogram (http://en.wikipedia.org/wiki/Cartogram Solution based on this http://prag.ma/code/d3-cartogram/#births/2011.

    Furthermore the Application uses RequireJS, Jquery and D3.
    requirejs.org
    jquery.com
    d3js.org

    Ich hoffe, Ihnen damit weitergeholfen zu haben.

    Mit besten Grüßen
    Christina Elmer (christina_elmer@spiegel.de)

    wib: testweise Umwandlung shapefile in TopoJSON: 

    nodejs.org
python.org 2.7.7
npm install topojson rw d3 optimist shapefile queue-async d3-geo-projection
node bin\topojson -o test.json test.shp
test.json:
{
    "type":"Topology",
    "objects":{
        "test":{
            "type":"GeometryCollection",
            "bbox":[0,0,180,170],
            "geometries":[
            {
                "type":"MultiPolygon",
                "arcs":[[[-1]],[[1]]]
            },
            {
                "type":"Polygon",
                "arcs":[[2]]
            },
            {
                "type":"Polygon",
                "arcs":[[2]]
            }
            ]
        }
    },
    "arcs":[[[1111,1176],[0,589],[556,0],[-556,-589]],[[0,0],[5555,0],[0,5882],[-5555,0],[0,-5882]],[[8333,8823],[555,0],[1111,1176],[-1666,-1176]]],
    "transform":
    {
        "scale":[0.018001800180018002,0.017001700170017002],
        "translate":[0,0]
    }
}
    Probleme: Visualisierung einer Prognose in einer Karte mit Beulen könnte eine Aufgabe für Praktikanten sein.
  9. s Modernisierung C++ Verwendung (h,0A,v,Z:,B:)
  10. t Reporting erweitern (h,0A,v,Z:,B:)
  11. t MSI-Installationsdatei (23h,0A,v,Z:,B:)
    Der aktuellen Installation von SIKURS fehlt die Möglichkeit SIKURS durch "Systemsteuerung/Programme deinstallieren" zu löschen.
    Dies könnte druch den Einsatz von "Advanced Installer" für MSI Dateien verbessert werden (siehe sikurs/source/ai).
    Dies würde allerdings die Option SIKURS ohne Admin-Rechte in ein Verzeichnis der Wahl (z.B. C:\SIKURs_10_1) zu installieren und evtl. mehrere SIKURS-Vesionen paralell zu betreiben einschränken.
  12. s Einbeziehung Flüchtlinge (h,A,v,Z:m,B:)
    Einbeziehung Flüchtlinge
  13. t Innenwanderung-Binnenwanderung: Entfernungen berücksichtigen (h,A,v,Z:m,B:)
    wib: Wenn man den Gebieten Schwerpunktkoordinaten (eigene Datei center.csv oder zusätzliche Spalte in reftyp.csv) zuordnen kann, oder eine Distanzmatrix der Entfernungen vorgibt, dann könnte man die Entfernungen zwischen Gebieten zur Berechnung von Attrativitäten zur Gewichtung des "freien Wohnangebotes" bei der Aufteilung des Binneneinzugs pro Quellgebiet verwenden.
    (siehe Baustein V)

    wurde auf Lenkungsausschuss 2018 kontrovers diskutiert

  14. s Automat. Vergleich der Ergebnisse von ex-post-Prognosen und Daten der Statistik (h,A,v,Z:m,B:)
  15. s Zwischengeschlecht divers (h,A,v,Z:m,B:)
    siehe Zwischengeschlecht
    Hat das Bundesverfassungsgerichts-Urteil vom 8.11.2017 zur Intersexualität Auswirkungen auf SIKURS ?
    Im Dokument KOSIS-DST_Bestand_2021-02.pdf ist P02 nach wie vor binär (1) männlich, (2) weiblich, genaueres siehe 
    Weitere Merkmale
P02MR 330 01 Geschlecht (DSMeld 0701) 
(m) männlich
(w) weiblich
(d) divers (62:nach § 22 Abs. 3 Personenstandsgesetz sowie § 45b Personenstandsgesetz)
(x) ohne Angabe
    Mit einer kleinen Erweiterung von SIKURS könnte man die Modellierung des Geschlechts dem Nutzer überlassen: Mit diesem Schema kann man rechnen.
    Bei der Visualisierung als Pyramide könnte man je die Hälfte von "divers" und "ohne Angabe" auf männlich und weiblich aufteilen und wie die Bevölkerungsgruppe farblich abgrenzen.
    Auswirkungen auf Berechnung von Indikatoren müssen diskutiert werden.
  16. s bestandsmindernde Raten größer 1 (h,A,v,Z:m,B:)
    das Problem taucht (ausser in Stuttgart bei Baustenkombination B1D1I1K1M1P4R1W1Y1) häufiger auf.

    s,w: Ein Teil des Problems können wegen hoher Differenzierung sehr dünn besetzte Eingangsdateien wie wegz und strm sein.
    Dadurch haben einzelen Bevölkerungsgruppen (z.B. 96-jährige) sehr hohe Wegzugsraten, die zu negativer Bevölkerung dieser Altergruppen führen.
    Da Nachbargruppen viel zu niedrige Wegzugraten haben, läßt sich dies durch Glätten oder besser durch Bildung von wenigen Altersklassen bei der Berechnung dieser Dateien aus den Makrodateien verbessern.
    Weiterhin könnte man prüfen, ob es Sinn macht zu große Wegzugsraten zu reduzieren, statt später im Programm entstehende negative gem-Werte wegen
    a) negative Wanderungsbilanz > Bestand
    b) Sonderbevölkerung > Bestand
    auf 0 zu setzten
    und dadurch die Ziewerte zu verfehlen.
    siehe auch 043_2 (dynamische Bevölkerungsbewegung - verkürztes Prognoseintervall)

    m,u: Wegzugsraten > 1 entstehen beim Bezug von Stromgrößen (Wegzugsvolumen) auf Bestandsgrößen an einem Tag X (Einwohnerzahl). Wenn also die durchschnittlichen Wohndauern in bestimmten Altersjahrgängen niedrig sind (unter 1 Jahr), ist der Bezug auf ein (zu langes) Zeitintervall (von einem Jahr) in dieser Art der Berechnung wohl problematisch.
    Singapur hat eine Exportquote von fast 200% (200% des Inlandsprodukts wird innerhalb eines Jahres exportiert). Dies liegt daran, dass Singapur ein Umschlagsplatz ist und dass viele Waren zunächst importiert werden und dann nach einer Lagerzeit (kürzer als einem Jahr) wieder exportiert werden. Bei jahrgangsspezifischen Wegzugsraten über 1 werden die vielen Bevölkerungsim- und -exporte eines bestimmten Jahrgangs innerhalb eines Jahres und die sequentielle Abfolge der Berechnungen wohl zum Problem (Großstädte haben bei manchen Altersgruppen quasi die Funktion der Welthäfen im Handel).
    Ich sehe die Problemlösung weniger bei Glättung (ich erkenne zumindest im Verlauf der Kurve eine gewisse Systematik in den Raten), sondern einer Verkürzung des Prognoseintervalls (man könnte bei sehr hoher Mobilität der Bevölkerung das Prognoseintervall auf ein halbes Jahr herabsetzen und so die "Exportquoten" unter die 1 drücken, das Prognoseintervall muss dafür kürzer als die durchschnittliche "Lagerzeit" sein). Im Kern handelt es sich wohl um ein Taktungsproblem: ein Prognoseintervall, dass den Wohndauern in einzelnen Altersjahrgängen (und Typen) nicht angemessen ist. Wenn SIKURS also negative Bevölkerungszahlen feststellt (Wegzugsraten > 1), könnte man rechnerisch vielleicht eine Lösung finden, indem man das Prognoseintervall von einem Jahr (im Hintergrund) künstlich unterteilt, sodass zumindest außenwanderungsbedingt zu keinem Zeitpunkt negative Einwohnerzahlen vorkommen können. Außenwegzugsraten > 1 sind aus meiner Sicht für den Anwender eigentlich ein Zeichen, dass sofern die Raten sorgfältig generiert wurden und er bei einer jahrgangsspezifischen Rechnung mit der gleichen Gebietstypisierung bleiben will, ein kürzeres Prognoseintervall als 1 Jahr angezeigt ist.

    m,h: Bestandsmindernde Raten < -1 und damit verbunden - wenn auch nicht zwangsläufig, aber auch nicht unvermeidbar - negative Bestandszahlen sind Hinweise auf konzeptionelle Schwächen eines Prognoseansatz, der Bewegungen eines Jahres mit Raten bestimmt, die auf den Bestand zum 1.1. des Beobachtunsgzeitraums bezogen sind. Während des Beobachtungszeitraums können nämlich mehrere Entwicklungen die Besetzung der Bevölkerungsgruppe verändern, auf die die Bewegungsdaten bezogen werden. Wie oben bereits dargestellt können bei wachsenden, bei abnehmenden Bevölkerungsbestand oder bei kurzer Verweildauer der Wandernden die auf den Bestand vom 1. Jan. bezogenen Ausprägungen der Raten die Verhaltensweisen nicht zutreffend abbilden.

    Aus diesem Grund werden die Raten der amtlichen Statistik aus den Werten der im Jahr beobachteten Bewegungen und der durchschnittlichen Jahresbevölkerung bestimmt. (Durchschnittliche Jahresbevölkerung = Mittelwert von 12 mittleren monatlichen Bevölkerungs­beständen). Die Aufteilung eines Jahres in mehrere, kurze Beobachtunsgzeiträume berücksichtigt, dass die Bewegungen in einer Bevölkerungsgruppe zeitgleich verlaufen und die Fehler, die bei der Vernachlässigung dieser Tatsache in Kauf zu nehmen sind, umso kleiner werden, je kürzer die Zeiträume innerhalb der die Bewegungen registriert und damit die zeitlichen Abstände zur Aktualisierungen der Bezugsbevölkerung werden.

    Die für die Prognoserechnungen beschriebenen negativen Konsequenzen lassen sich zwar nicht gänzlich vermeiden jedoch erheblich mindern. Mit der Unterteilung einer Prognoseperiode in mehrere Simulationsrechnungen für kürzere Zeitintervalle wird die Nichtbeachtung der Gleichzeitigkeit erheblich entschärft. Das Prognoseergebnis zum Jahresende wird so als Fortschreibung der Ergebnisse von mehreren - monatlichen/ vierteljährlichen- Simulationsrechnungen bestimmt. Voraussetzung ist, dass auch die Datenaufbereitung entsprechend modifiziert wird, indem auch die Bewegungsparameter nicht auf den Ausgangsbestand zum 1. Jan. des Beobachtungszeitraums sondern auf den mittleren Jahresbestand bezogen werden.

    Eine entsprechende Weiterentwicklung des SIKURS -Programms würde die Gültigkeit der Prognoseergebnisse verbessern und vermeidbare Unschärfen beseitigen. Diese Änderungen sind mit überschaubaren Aufwand machbar, weil - anders als bei den altersspezifischen Raten - die Bezugsbevölkerung der Sikurs-Prognoserechnungen und damit der Ratenberechnung durch das Geburtsjahr festgelegt werden; d.h. dass der Alterungsprozess der Bezugsbevölkerung im Laufe des Jahres nicht mit abgebildet werden muss.

    Um eine Basis zur Abschätzung des Arbeitsaufwands und des Nutzens der vorgeschlagenen Änderung zu haben, wäre es sinnvoll, für eine entsprechende Voruntersuchung und für die Überprüfung von Prognoseergebnissen, die mit der aktuellen SIKURS-Version und mit einer Werkstattversion der geänderten SIKURS-Version ausgeführt wurden, ein Stundenkontingent von xy vorzusehen.
    (s,b: mit synthetischem Beispiel oder in Zusammenarbeit mit einem Anwender mit Beispiel mit hohen bestandsmindernden Raten und zugehörigem Statiskdatensatz ?)

    Ehlert: Berechnung der z.B. Sterberaten aus den Makrodateien:
    Sterberate = Sterbefälle 2017 / Bestand Mitte 2017
    Für die Berechnung der Makrodatei "Bestand Mitte 2017" aus dem Statisitikdatensatz gibt es zwei mögliche Methoden:

    1. (Bestand 2107 + Bestand 2018) / 2
    2. Bestand 2017 + Anwendung aller Bewegungen 2018 bis 31.06.2018
    Thema ist zurückgestellt
  17. s Ergänzung der EXCEL-Beispiele durch Ablaufdiagramme (h,A,v,Z:m:16,B:)
    Zum besseren Verständnis der in den Laufprotokollen dokumentierten Sikurs-Berechungen und der EXCEL-Bespiele (roadmap 053) sollen die SIKURS-Berechnungen dokumentiert werden.
    Dafür gibt es folgende Alternativen:
  18. s Abbildung der Innenwanderung bei den Prognosebausteinen P(x)|x>0| (h,A,v,Z:m:60,B:)
    m,h: Beim Baustein P0 werden bei der Innenwanderung, d.h. der Wanderungen zwischen den Gebietseinheiten eines Typs, die Auszüge aus den einzelnen Gebietseinheiten als Einzüge in die einzelnen Gebietseinheiten des zugehörenden Binnen­typs bestimmt. Die Zuordnung auf die einzelnen Gebietseinheiten ist orientiert an den freien Wohn­kapazitäten der einzelnen Gebietseinheiten.

    Bei den Baustein P(x)|x>0| werden die Ströme in einer Verflechtungsmatrix den vom Anwender vorgegebenen Zielwerten angepasst. Bei der rekursiven Anpassungsrechnungen der Verflechtungsmatrix (1), in der die Ströme der Innenwanderung zwischen den Gebietseinheiten des betrachteten Binnentyps abgebildet werden, bleibt das Wanderungsvolumen konstant, angepasst werden die Einzüge in die einzelnen Gebietseinheiten. Damit bleibt auch die Anzahl Stayer je Gebietseinheit konstant, d.h. derjenigen, die nicht ihre Wohnung wechseln.

    Wir schlagen vor, das Wanderungsvolumen und damit auch die Anzahl Stayer bei den Anpassungsrechnungen zu modifizieren und zu dynamisieren.

    Die Ergebnisse der beiden Anpassungsrechnungen (1) und (2) sind am Beispiel von drei unterschiedlichen Ausgangssituationen in den pdf-Dateien im Anhang dargestellt und mit den jeweiligen Ausgangsdaten verglichen.

    1. Bewegungen_inclStayer.pdf
    2. Bewegungen_plusStayer.pdf

    Die Beispiele für die beiden alternativen Ansätze zeigen, dass

    wib:
    Fragen:

    ahk: Korrektur Aufteilung Inneneinzug in Gebiete/Typen bei Baustein P : Die Diskussion mit Dr. T. ergab, dass eine Überprüfung des Programmablaufes notwendig ist, um Weiteres zu veranlassen, deshalb wird der Punkt vorläufig zurückgestellt bis die aktuelle Verarbeitung geklärt ist.
  19. s 10 EXCEL-Beispiele für Bausteinkombination A1,B1 sowie P(1-2), M(1-2), N(1-4) (90h,A,v,Z:m:90,B:)
    m,h: Weitere 10 Excel-Beispiele mit den Bausteinen P(x) |x>0| und der Baustein-kombination (A1-B1, N(x) |x>0|) simultane Anpassung von Zu- und Wegzug. Diese Bausteinkombinationen wurden bislang ausgespart, weil für die die iterativen Berechnungen tools bereitgestellt werden müssen.

    wib:
    Eine systematische Überprüfung des Bausteins P könnte so aussehen:

    Wenn diese Prüfungen erfolgreich waren, prüft man, ob die Ergebnisse auch bei Hinzunahme weiterer Bausteine in verschiedenen Kombinationen noch stimmen Beispiele für P2 aus Verzeichnis beispiel/baustein Ablaufdiagramme siehe roadmap 084.
    Sollen die Variablennamen in den Excel-Beispielen, den Programmquellen, in datadict_de/en.csv, im Protokoll und im Datenflußgraph auf Konformität mit den Namenssystematik überprüft und bei Bedarf angepasst werden werden, z.B. 
    eva.csv:
# Anpassung Variablennamen C++ and Excel
#C++;Excel
ATTR;GG1ATTR
BG01;BG21E
DG1G;(ist im Graph aber nicht in Protokoll)
PR2G;PR3G
DG3G;DG2G
DSGA;BG40DSG
DSGR;QG40DSG
ECKGEB;DU01GE
ECKGEBG;DG11GE
ECKSTRB;DU01SE
ECKSTRBG;DG11SE
    Diese vom Methondenexperten für die Erstellung der Excel-Beispiele gepflegte Datei eva.csv kann als Vorgabe für einen Auftrag an die Sysrtemtechnik die Namenssystematik in den C++ Programmquellen zu verbessern herangezogen werden.

    hst:
    Ich habe mir die Namenssystematik angesehen:
    Wenn alles konsequent der Systematik entsprechend geändert werden soll, dann wird dies ein Mamutvorhaben: ca. 90 Namen müssten geändert werden, wenn R in T, W in O, Z in I und die Angabe der Dimensionen (ohne dabei die Jahreszahl mit einzubeziehen) konsequent angepasst würden. Es sollten daher die ersten 2 Zeichen erhalten bleiben und nur dort geändert werden, wo sie nicht der Systematik entsprechen. Bei der Angabe zur Anzahl Dimensionen gibt es widersprüchliche Aussagen. Das finde ich schlecht.
    Die allgemeine Systematik wird nicht eingehalten bei der Verwendung von Namen wie ECKSTRB, SFAK, saldvol, rueckbaub, rueckbauweg, reaq. Das sind die Namen der Inputdateien, die Namen ihrer Variablen nehmen die Bezeichnung der Datei auf. Das Prinzip ist aber nur in Ausnahmefällen beibehalten.

    wib:
    Besprechung hst - wib 26.05.2023 in München:
    Eine Unterstützung des Methodenexperten durch die Systemtechnik ist sinnvoll und notwendig zu mindestens folgenen Themen

    siehe auch roadmap 053

    Vor Beginn der Arbeiten sollte diskutiert werden, ob das Anpassungsverfahren in Excel und C++ von "classical IPF" auf "IPF factor estimation" (oder gar "ADETON") umgestellt werden soll.
    Weiterhin sollten Erkenntnisse (Fehler, Schwachstellen, Ideen für Verbesserungen) wie in roadmap 053 gegen Mehraufwand sofort umgesetzt werden.

    Beim Lenkungsausschuss am 26.07.2023 10:30 wurde besprochen

  20. s Ableitung der Sterblichkeit aus der amtl. Statistik (23h,A,v,Z:m:36,B:)
    m,h: Der Ableitung der Sterblichkeit aus der amtlichen Statistik für die Gruppen des Altersindex 0 wurde die mittlere Verweildauer dieser demografischen Gruppe im Prognosejahr zu Grunde gelegt und die amtliche Sterberate halbiert. Dabei blieb unberücksichtigt, dass etwa die Hälfte aller Neugeborenen in den ersten 8 Wochen nach der Geburt versterben. Die wöchentliche Sterberate des ersten Lebensjahres ist demnach eine dynamische Größe und nicht für alle Wochen des ersten Lebensjahres gleich. Dieser Sachverhalt wurde bei oben beschriebenen Ableitung der SIKURS Sterberaten aus den Sterbetafeln nicht berücksichtigt. Die Berechnung der Sterberaten aus den Sterbetafel sollte daher korrigiert werden.

    wib: Überarbeitung Spezifikation von
    Sterbetafel_Deutschland_2014_2016.csv

    Wenn nach der Überarbeitung ein Tool weiterhin nötig erscheint, muss dieses der neuen Spezifikation angepasst werden, ansonsten sollte die Spezifikation komplett ins Handbuch Bevölkerungsprognose verlegt werden.

    wib: Berechnung von Sterbetafeln
    Ein Vergleich 098-12621-0001.pdf (098-12621-0001.xls) SIKURS-Sterberaten mit amtlichen Sterberaten zeigt, dass sich die jeweils zugehörige Lebenserwarung von 74,66 bzw. 78,35 deutlich unterscheidet.
    Vielleicht gelingt es mit den aus der Sterbewahrscheinlichkeit q(x) abgeleiteten Werten Überlebende l(x) und Gestorbenen d(x) plausiblere Werte für die SIKURS-Sterberaten abzuleiten?

    Ein oder mehrere Parameter für die Korrektur der Altersgruppe 0 sollten in Startmaske oder einer Eingabdatei stehen, damit die Lösung allgemein (und nicht spezifisch für bestimmte Jahre und Regionen ist)
    Die Sterberate ab 30 steigt exponentiell an, d.h. im 2. Halbjahr sterben jeweils mehr Personen als im ersten Halbjahr.
    Soll dieser Effekt bei der Verschiebung der Altersgruppe um ein halbes Jahr berücksichtigt werden ?

    Stimmt die Berechnung Lebenserwartung als "Summe akkumulierte Überlebenswahrscheinlichkeit + 0,5" im Prognoseprotokoll, Indikatorentool, und Extras/Eigene scripts/lebenserwartung.pl, oder soll sie dem Verfahren destatis wie in Extras/Eigene Scripts/le_destatis.pl angepasst werden ?
    le.png
    Beispiel Lebenserwartung aus .../beispiel/regtest/strb1992.csv:

    #       lebenserwartung ; le_destatis
1;1;1;0;73,7886112044886;73,7879572814655
1;1;2;0;79,6156265704044;79,6103178857868
1;2;1;0;81,1099888938062;80,9471352956605
1;2;2;0;89,0462746980029;88,8227386033458
    Im Prognoseprotokoll wurde die Berechnung der Lebenserwartung auf die destatis-Methode umgestellt. Je nach Protokollumfang enthält diese
    1. nur die Altersgruppe 0
    2. alle Altersgruppen
    3. zusätzlich Zwischenergebnisse
    Mit !option($LE 1)
    kann auch die einfache Berechnungsmethode angesteurt werden (siehe Einwohner/Prognose/Berechnen/?/Notiz/Optionen/LE)

    Mit SIKURS-Hauptmaske/Extras/Eigene Scripts/Start/gompertz.pl
    kann man den Gompertz-Koeffizienten und die MRDT (mortality rate doubling time) berechnen und mit dem logarithmischen Gompertz-Diagramm die Plausibilität der Sterberaten insgesamt überprüfen.
    siehe roadmap 013, 068

    siehe auch GREVILLE-Methode, REED-Merell-Mehode in "Vogel, Grünwald: Kleines Lexikon der Bevölkerungs- und Sozialstatistik"

    uls: Ich habe mir das jetzt genauer angesehen, insbesondere weil ich in das Handbuch auch einen Abschnitt zur Thematik aufgenommen habe.
    Angehängt habe ich Original-Sterberaten der Perioden-Sterbetafel aus den Jahren 2014 bis 2016 (098_sterbetafel_sterberaten.csv). Laut Statistischen Bundesamt betrug damals die Lebenserwartung bei Geburt bei den Männern 78,18 Jahre und 83,06 Jahre bei den Frauen.
    Die von SIKURS mithilfe des Tools generierten interpolierten Sterberaten und mit den korrigierten Sterberaten für die Altersgruppen 0, 1 und 99 habe ich als 098_strb2016_roh.xlsx angehängt. Ich komme bei den interpolierten Daten auf Lebenserwartungen von 78,15 / 83,00 und bei den korrigierten auf 78,16 / 83,00. Die Formel in den Zellen J5 und Q5, bzw.J105 und Q105 sollten Sie sich kurz ansehen. Die Berechnung der durchschnittlich Zahl durchlebter Jahre weicht in der Altersgruppe 0 (0 bis 0,5jährige) von den Berechnungen in den anderen Altersgruppen ab.
    Ich würde bei meinen Prognosen die von SIKURS generierten Sterberaten korrigieren, weil die Sterberaten der Altersgruppe 0 durch die Interpolationen zu niedrig und der der Altersgruppe 1 zu hoch geschätzt würde. In der Altersgruppe der 99jährigen würde ich eine Rate verwenden, die dafür sorgt, dass ein natürliches Höchstalter (116 Jahre) von praktisch niemand überschritten wird. An der Lebenserwartung ändert sich dadurch kaum etwas, die Raten werden nur hinsichtlich der Säuglingssterblichkeit etwas plausibler und ein mit jedem Prognosejahr wachsender Überbau (in der Altersgruppe 99) in der Bevölkerungspyramide vermieden.
    Insgesamt kann ich den starken Rückgang der Lebenserwartung durch die Anwendung des SIKURS-Tools bei meinen Daten nicht beobachten.

  21. h hhprog Altersgruppen verfeinern (h,A,v,Z:,B:)
    Bei der Quotenberechnung legt der Anwender zwei Altersindices fest 
    [35 ] Untere Altesgrenze (jung)
[65 ] Obere Altersgrenze (alt)
    Mit diesen Werten gibt es in der Haushalteprognose bei den verschiedenen Indikatoren folgende Altersgruppen mit den Altersgrenzen:
    fein0 35 65 1000
    grob_jung0 35 1000
    grob_alt0 65 1000
    Für eine Verfeinerung dieser Altersgruppen gibt es folgende Möglichkeiten:
    1. eine neue feinere Definiton obiger Tabelle
    2. die Auswahl von 2 oder 3 Tabellen für den Anwender
    3. die Möglichkeit für den Anwender die Altersgruppen obiger Tabelle selbst beliebig zu verfeinern
    Anschließend muss man prüfen, ob dies nahtlos in das "von Klitzing Konzept" passt
  22. s Strukturpflege (h,A,v,Z:,B:)
    1. Umbenennen Eingabedateien ECK(GEB,GEBG,GEM,REG,STRB,STRBG,TYP) in Prefix ZIEL statt ECK, da Zielwert als Begriff beser passt als Eckwert.
      Ersetze bei Zielwerdateien .GEB, .GEBG, .REG, .STRB, .STRBG Zielwert durch Unter- und Obergrenze, um z.B. bei Baustein M2 für einzelne demografische Gruppen einen Zielwert (Unter- = Obergrenze), für andere ein Zielwertintervall (Unter- < Obergrenze) oder freie Entwicklung (kein Eintrag, d.h. Untergrenze = 0, Obergrenze = ∞) vorgeben zu können.
    2. Bausteinabhängige Dateinamen
      Einige Bausteine sind in ihrer Struktur/Differenzierung abhängig vom verwendeten Baustein. Wenn man einfach Eingabedateien für mehreren Bausteinausprägungen im Eingabeverzeichnis halten möchte, könnte man folgende Dateienamen anpassen 
      dsg2020_R1-2
eckreg_M1-2
saldvol_N1-4
wegvol_C1-4
zuaq2020_k1-4
zudq2020_K1-4
zuvol_K1_4
      Bisher muss man sich mit Befehlen vor/nach der Prognose behelfen: 
      shortcut qw(zuvol_K2 zuvol);
shortcut qw(zuaq2020_K2 zuaq2020);
shortcut qw(zudq2020_K2 zudw2020);
...
remove qw(zuvol zuaq2020 zudq2020);
    3. Bausteine C, M, N erweitern
      Wenn für eine vorgesehene Differenzierung kein Zielwert vorgegeben wird, dann sollte für diese Teilmenge (anlaog zu Baustein G und S) keine Anpassung vorgenommen werden.
      Alternativ könnte man für die Zielwertdateien eckgeb, eckgebg, eckreg, eckstrb, eckstrbg statt eines eventuell fehlenden Zielwertes Unter- und Obergrenzen wie bei den Dateien eckgem, ecktyp einführen.
    4. Baustein V entfernen
      Bei Baustein D und E werden immer Gewichte für die Wanderungen eingelesen.
      Wünscht man keine Gewichtung gibt man z.B. alle Gewichte 1 vor: 
      nebgqt.csv
# Neubauerstbezug mit Gewichten Quellen Binnentypen
#Jahr;tynee;tyb;Gewicht
*;*;*;1

      Wenn man den Baustein V entfernt, dann wird man immer die Datei attr2020.csv, umbenannt in bwgqg.csv einlesen. 

      bwgqg.csv
# Binnenwanderung mit Gewichtung der Quellgebiete
#Jahr;gkz;Gewicht
*;*;1
    5. Bausteinkombination E1V1 prüfen:
      Bei Bausteinkombination E1I1T1V1 muss noch geprüft werden, ob die Gewichte ATTR0000.csv und REAGZT.csv zusammenpassen (hst vermutet ja):
      DG4IBR Binneneinzug aus Rückbauendauszug wird erst mit REAGZT gewichtet und anschließend mit der mit ATTR0000 gewichteten freien Wohnkapazität auf die Gebiete verteilt - siehe Laufprotokoll: 
      attr2020.csv -> GG1ATTR -> FWKG -----------> DR4IBR
reagzt.csv   -> GR2IBR -> DR5IB -> DR3IBR -/

DR5IB = DR4IB * BR30C * GR2IBR
FWKG *= GG1ATTR
DR3IBR = DR5IB * DR4OBR_REA
DG4IBR = DR3IBR * FWKG/FWKT
    6. Baustein T entfernen
      wünscht man keinen Außenwegzug, kann man folgendes vorgeben 
      wegz2020.csv
# leer, kein Außenwegzug
      (siehe 062);
    7. 32-bit Version auslaufen lassen
      SIKURS 5.4.1035 mit gnuplot 5.2.7 32-bit als letzte 32-bit Version einfrieren
      SIKURS 5.5 nur noch als 64-bit Version (mit gnuplot 5.2.8 64-bit) erstellen.
    8. Visualisierung/Indikatoren
      Erweiterung Berechnung Lebenserwartung auf destatis Verfahren (siehe roadmap 098)
    9. Berechnen/Cluster-Analyse Reiter GEM
      Funktion Clustervektor aus GEM-Datei ableiten könnte gestrichen werden, weil man dies leicht z.B. durch Ergebnis/Zeitreihe erledigen kann
    10. Nachfolge Pflege Handbuch Haushalteprognose, z.B.:
      Siehe Hauptmaske/Haushalte/Quoten/Berechnen/HHProg-Verzeichnis/?
      Kurzfassung und Anmerkungen
    11. folgende in der Haushalteprognose verwendeten Variablen können den Wert "blank", das heißt, Feld ist nicht versorgt haben:
      HPAAR, HELT, KERNS, HVOR, HNACH, HHNR
      Derzeit wird nur KERNS geprüft und falls blank wird mit "Haushaltegenerierung noch nicht durchgeführt" abgebrochen.
      A01 - Merkmalsableitung nicht möglich
      A03, A06 - Merkmalsableitung noch nicht durchgeführt
      A07 - Merkmalsableitung noch nicht durchgefühft oder Person gehört nicht zu Bevölkerung in Haushalten
      Hier werden blank-Felder als 0 gewertet.
      Sollen die Felder auf "blank" geprüft werden, wenn ja, was ist jeweils zu tun ?
      • Abbruch mit Warnung bei ersten Auftreten
      • Warnung im Protokoll bei jedem Auftreten
      • Fälle zählen und am Ende Statistik: unversorgte Felder HAPAAR 3, HELP 0, KERNS 543, ...
    12. gnuplot ab 6.0 webp statt png, gif verwenden und Alternativen prüfen:
    13. Steuerung Ausgabe Binnenwegzugsmatrix verbessern
      Einwohner/Prognose/Berechnen/Ausgabe 
      Ausgabe
[vn] Differenzierung Binnenwegzugsmatrix
      mit folgenden sinnvollen Spaltennummern aus reftyp
      vnWirkung
      0keine Ausgabe Binnenwanderungsmatrix
      1nur Ausgabe unsortierte Rohdatei gstrom.csv
      0101von Gebiet nach Gebiet (evtl. sehr groß)
      0105von Gebiet nach TYB
      0501von TYB nach Gebiet
      0505von TYB nach TYB
      -0505von TYB nach TYB (ohne Aufbau von gstrom.csv)
      1313von räumlichen Aggregat 1 nach räumlichen Aggregat 1
      1305von räumlichen Aggregat 1 nach TYB
      -1414von räumlichen Aggregat 2 nach 2 und löscht gstrom.csv
      Die Ausgabedatei enthält die Differnzierung im Dateinamen, z.B. gstrom01_01.csv
      Bis auf 0505 wird die unsortierte Datei gstrom.csv ohne Spaltenüberschriften in Differenzierung "Jahr, Quellgebiet, Zielgebiet, BG, GG, AG, Anzahl" ausgegeben und anschießend in die gewünschte Differenzierung aggregiert. Ein negatives Vorzeichen bewirkt die anschließende Löschung von gstrom.csv. Behält man die Datei gstrom.csv, kann man daraus weitere Dateien in gewünschter Differenzierung berechnen, z.B. durch Befehle nach der Prognose: 
      # aggregiere gstrom auf räumliches Aggregat ohne demografische Differenzierung
zeitreihe 'gstrom', 'gstrom13_13', ['$i', 'reftyp 1 13', 'reftyp 1 13', 1, 1, 1], { subset => 0 };
# Ausgabe Wanderungsmatrix als "heatmap"
matrix(fn => 'gstrom13_13', shape => 4, size => 1000);
# zeige heatmap im Browser (evtl. Umstellung gif nach webp)
start('gstrom13_13.gif');
    14. Wenn man die Binnenwegzugsmatrix als float statt double speichert, könnte man mit erhöhter Anzahl Binnentypen rechnen.
      Eine Änderung der Reihenfolge 
      #TYV;TYN;BG;GG;AG;Rate in
#BG;GG:AG:TYV;TYN;Rate
      könnte Vorteile bringen.
    15. ini-Dateien im TOML (oder YAML, JSON) Format speichern mit folgenden Vorteilen:
      • Routinen für viele Programmiersprchen verfügbar
      • bessere Unterstützung mehrzeiliger Texte (z.B. Notiz)
      • Unterstützung von Arrays und Tables
  23. s Erweiterung hhprog bei Differenzierung gem (h,A,v,Z:,B:)
  24. d Update Dokumentation für SIKURS 10.5 (h,A,v,Z:,B:)
  25. s Weiterentwicklung (h,A,v,Z:,B:)
    Für die zukünftige Weitereinwicklung von SIKURS (siehe auch 021 022 025 032 106 111) müssen folgende Fragen geklärt werden:
    1. Soll SIKURS ein Programm Bevölkerungs-, Haushalte-Prognose und vielen Zusatztools bleiben, oder soll es einen Wizard, oder soll es in eine Statistik-Software integriert werden (z.B. R, Python, Mojo, Julia) ?
      Eine einfache Integration mit R existiert bereits, man kann aus R SIKURS Prognosen und diverse Tools starten und SIKURS kann R-Prozeduren starten (siehe Handbuch - externe Programme).
    2. soll SIKURS außer unter Windows (10/11/365) auf weiteren Plattformen (z.B. Linux (z.B. raspi), MacOS) lauffähig sein ?
    3. sollen weiterhin csv-Dateien verarbeitet werden, oder soll eine Datenbank oder hdf5 eingesetzt werden ?
      Die Zugriffe lesen und schreiben auf die csv-Dateien sind in C++ (Modul fn) und Perl (Modul CSV) stark gekapselt.
      Eine Umstellung auf eine Datenbank müsste mit begrenztem Aufwand möglich sein. (siehe 021)
    4. Sollen für globale Parameter sikurs.ini und Projektparameter .../bprog/v3.ini weiterhin "Windows-style-ini-Dateien" verwendet werden, oder auf Windows-Registry bzw. JSON, XML, YAML, ... umgestellt, oder in eine Datenbank integriert werden?
    5. Sollen die Protokolle als Verzeichnis mit vielen html-Dateien erhalten bleiben, oder soll auf andere Konzepte, z.B. Datenbank, markdown, ..., gewechselt werden ?
    6. Welche client server Technologien sollen unterstützt werden (z.B. Apache Web-Server, Citrix Applikations- und Terminalserver) ?
    Sollte beispielsweise die Antwort lauten:
  26. s Mitgliederversammlung 2021 (h,A,v,Z:,B:)
    folgende Probleme wurden angesprochen
    1. wenn man mit Excel SIKURS-csv-Dateien einliest, dann werden manche Felder als Datum interpretiert.
      work around: csv in txt umbenennen und in Excel importieren
      wib: bitte Beipiel
    2. Tools merken sich das Eingabeverzeichnis nicht, man muss sich jedesmal durch den Verzeichnisbaum klicken.
      Schapper: wenn man mit Einwohner/Versionsdatei/öffnen eine ini-Datei in der Nähe der gewünschten Dateien öffnet, dann funktioniert das.
      wib: bitte Beispiel für Tools mit diesem Problem, z.B. "Eingabedaten/Glätten/Glätten über das Alter" merkt sich das Verzeichnis der letzten Glättung solange die Hauptmaske aktiv.
      Mögliche Lösung:
      Man könnte die Dateiauswahlmaske so konfigurieren, dass sie immer im Verzeichnis steht in dem beim letzen Aufruf der Dateiauswahlmaske eine Datei ausgewählt wurde, d.h. das Startverzeichnis der Dateiauswahlmaske würde vom Verzeichnis der aktiven ini-Datei entkoppelt.
      Testweise wurde dieses Verhalten in Ergebnis/Bearbeiten/Datei eingebaut.
  27. s Erweiterung Statistikdatensatz (h,A,v,Z:,B:)
    KOSIS-DST_Bestand_2021-02.pdf erweitert den Statistikdatensatz Bestand von 321 auf 350 Stellen.
    Wer kann überprüfen, ob davon die Haushalteprognose oder die Ableitung Makrodateien betroffen ist ?
  28. t Vorzeitiger Abbruch Prognose (34h,A,v10.5,Z:,B:1)
    Wenn man eine lange laufende Prognose gestartet hat, will man sie manchmal vorzeitig abbrechen, z.B. weil Zwischenergebnisse unsinnig erscheinen.
    Dies gilt für die Funktionen im Tocherprozess sikern64.exe: Für die Lösung des Probles gibt es 2 Alternativen:
    1. keine Programmänderung, nutze Programm Taskmgr.exe von Windows
      1. Tastenkombination <Strg><Alt><Entf> drücken
        Task Manager
        Zeile mit sikurs64.exe mit rechter Maustaste anklicken
        Task beenden
      2. Tastenkombiantion <Strng><Shift><Esc> drücken und obiger Task Manager erscheint sofort
      3. Extras/Eigene Scripts/Start/SIKURS_stop.pl
        erstellt ein Icon
        SIKURS_stop am Desktop.
        Wenn sie dieses Icon während eine Bevölkerungs/Haushalte-Prognose anklicken, so wird diese abgebrochen. Das Icon automatisiert die obigen Windows-Funktionen.
    2. Erweiterung GUI um "Thread und Queue"
      Bei SIKURS 10.5.0.1417 konnte der Tochterprozess sikern64.exe abgebrochen werden, wenn man diese Erweiterung aktivierte:
      Rechte Maustaste SIKURS Icon/Eigenschaften
      Ziel: [....\sikurs64.exe -t1 ]
      (-t1 bedeutet: verwende eigenen Perl-Thread für sikern64.exe mit Queue zur GUI)
      Mit Hauptmaske
      • Datei/Beenden oder
      • Kreuz rechts oben
      wird geprüft, ob Tochterprozess läuft.
      Wenn ja, wird er abgebrochen und es erscheint eine Messagebox mit Erfolgsmeldung.
      Anschließend wird die Hauptmaske beendet.
      Wenn diese neue Funktion gefällt, kann die Option -t1 zur Voreinstellung gemacht werden.
  29. s Plausibilitätsprüfing Statistikdatensatz, Makrodateien (18h,A,v10.5,Z:,B:1)
    Mit global_dst.pl kann man sich einen Überblick über ein Verzeichnis mit Statistikdatensätzen verschaffen, hier anonymisierte Testdaten: 
    Start Eigene Scripts global_dst.pl
C:/trunk/sikurs/extra/Beispiel/DST/350/dst:
< dstbest2017.txt 100000 Sätze zu 350 Byte
< dstbest2018.txt 100000 Sätze zu 350 Byte
< dstbew2018.txt 100000 Sätze zu 371 Byte
< dstbew2019.txt 100000 Sätze zu 371 Byte
> C:/trunk/sikurs/extra/Beispiel/DST/350/dst/global_dst.csv
Ergebnis für Jahr 2018:
  Bestand 98175, (Binnen-weg=zu-zug 17501),
  Geburt 2488, Sterbefall 2763, Außenwegzug 18097, Außenzuzug absolut 17565,
  Geburtenziffer 25,3425, Sterbeziffer 28,1436, Außenwegzugsziffer 184,334,
  Endbestand 97368
Ergebnis für Jahr 2019:
  Bestand 98200, (Binnen-weg=zu-zug 17677),
  Geburt 2276, Sterbefall 2723, Außenwegzug 18722, Außenzuzug absolut 17144,
  Geburtenziffer 23,1772, Sterbeziffer 27,7291, Außenwegzugsziffer 190,652,
  Endbestand 96175
Variable: Min Max Mean Stddev
Bestand: 98175 98200 98187,50 17,68
Geburt: 2276 2488 2382,00 149,91
Sterbefall: 2723 2763 2743,00 28,28
Wegzug: 18097 18722 18409,50 441,94
Zuzug: 17144 17565 17354,50 297,69
1000 * Bewegung über alle Jahre / Bestand über alle Jahre
Geburtenziffer 24,2597 = 1000 * 4764 / 196375
Sterbeziffer 27,9363 = 1000 * 5486 / 196375
Wegzugsziffer 187,4933 = 1000 * 36819 / 196375
Ende  Eigene Scripts 6,793 s
    Für den Bestand (=Hauptwohnsitzler) müsste gelten 
    Bestand 2019 = Bestand 2018 + Geburten - Sterbefälle - Außenwegzug + Außenzuzug
98724 = 98175 + 2488 - 2763 - 18097 + 17565
    weil die Bilanz der Binnenwanderung 0 ist.

    Dies stimmt im obigen Testdatensatz nicht, weil dieser bei 100000 Sätzen abgeschnitten wurde.

    Wenn Sie Statisikdatensätze für mehrere (z.B. 5 oder 10) Jahre verwenden, können Sie mithilfe der Ausgabedatei global_dst.csv z.B. mit Eingabdaten/Dynamisieren/...Regression untersuchen, ob die Geburten-, Sterbe-, Wegzugs-Raten konstant (mit zufälligen Schwankungen) sind, oder eine steigende oder fallende Tendenz aufweisen und Sie können überlegen, ob Sie für die Prognose die Raten dynamisieren wollen:

    #JahrGeburtSterbefallWegzugZuzugBinen-weg=zu-zugBestandGeburtenzifferSterbezifferWegzugszifferEndbestand
    2018248827631809717565175019817525,342500636618328,1436210847976184,33409727527497368
    2019227627231872217144176779820023,177189409368627,7291242362525190,65173116089696175
    Wenn man mit Eingabedaten/Berechnen/Makrodateien aus Statistikdatensatz Makrodateien berechnet, kann man sich mit global_makro.pl einen Überblick über die Makrodateien verschaffen, diese mit dem Ergebnis von obigem global_dst.pl vergleichen und damit die Plausibilität der Ableitung der Makrodateien prüfen.

    Start Eigene Scripts global_makro.pl
C:/trunk/sikurs/extra/Beispiel/DST/350/makro
< aussenwegzug_2018.csv
< aussenwegzug_2019.csv
< aussenzuzug_2018.csv
< aussenzuzug_2019.csv
< baby_2018.csv
< baby_2019.csv
< bestand_2017.csv
< bestand_2018.csv
< sterb_2018.csv
< sterb_2019.csv
Parameter für Jahr 2018:
  Bestand: 98175
  Geburt 2488, Geburtenziffer 25,3425
  Sterbefall 2763, Sterbefallziffer 28,1436
  Außenwegzug 2763, Außenwegzugsziffer 28,1436
  Außenzuzug: 17565
Parameter für Jahr 2019:
  Bestand: 98200
  Geburt 2276, Geburtenziffer 23,1772
  Sterbefall 2723, Sterbefallziffer 27,7291
  Außenwegzug 2723, Außenwegzugsziffer 27,7291
  Außenzuzug: 17144
Ende  Eigene Scripts 64,868 s
    Mit dem Ergebnis von wahlweise global_dst.pl oder global_makro.pl kann man mit global_prognose.pl eine Globalprognose auf Basis einer gewöhnlichen Differtialgleichung von Bestand, Änderungsrate (Geburt - Sterb - Außenwegzug) und Außenzuzug absolut starten.


    mit den Bewgungsdaten in global.prognose.csv

    Nach der Umwandlung der Statisikdatensätze in Makrodateien und schließlich in SIKURS-Eingabedateien kann man eine differenzierte kleinräumige SIKURS-Prognose durchführen und aus globale Werte hochaggregieren


    Die Kurve der Differtialgleichung ist viel flacher, weil diese das Gefälle nicht erst nach einem ganzen Jahr, sondern kontinuierlich mit dem fallenden Besand reduziert.

    mit global_prognose.pl können Sie mehrere absolute Außenzuzugsvariaten vorgeben und sich die zugehörige stabile Endbevölkerung ausgeben lassen:

    Erweiterung um räumliche Gliederung (Teilmenge R02) mit zusätzlicher Berücksichtigung Binnenwanderung.

    dst_prognose dst-Verzeichnis 3 2040
global_dst_R02.pl
    Ausgabe Visualisierung/Zeitreihe/X-Y-Plot

    Dazu werden aus dem Statiskdatensatz zwei csv-Dateien 
    regional.csv:
Jahr;Gebiet;Bestand;Geburt;Sterbefall;Außenwegzug;Außenzuzug

binnenwanderung.csv:
Jahr;Quellgebiet;Zielgebiet;Binnenwanderung
    abgeleitet und damit eine Prognose grob, d.h. ohne demografische Differenzierung, dafür räumlich fein, d.h. ohne Aggregation der Gebiete in Typen (Geburten-, Sterbe-, -(Außen/Binnen)-Wegzugs-Rate) gerechnet: Damit kann man sehr schnell Varianten mit unterschiedlichem Zugug und evtl. modifizierten Raten vergleichen.
    Prognose Bestand:

    Prognose Binnenwanderung:

    Bei Bedarf könnte man eine weitere Differenzierung nach der erweiterten Bevölkerungsgruppe (roadmap 120) hinzunehmen, um die Außenwanderung differenzierter zu betrachten.

    siehe auch roadmap 043

  30. s extrem kleinräumige Prognosen auf Basis Statistikdatensatz (h,A,v,Z:m,B:)
    Die Nutzung des Statistikdatensatzes erlaubt eine große Spannweite für die Differenzierung der Eingabedaten Letztere Methode wird in letzter Zeit vermehrt eingesetzt.
    Sinnvoll wäre eine Beschreibung einer Beispielprognose durch einen Methodenexperten mit Hinweisen zu den einzelnen Schritten: Besonders interessant wäre eine Vergleichsprognose mit klassisch "ordentlichen" Gebieten mit einer sehr kleinräumigen Prognose mit Aggregation auf die gleichen Aussageeinheiten