ICS Konfigurationshandbuch

Die Dokumentation darf nur mit Erlaubnis der infoGrips GmbH vervielfältigt werden.

07.10.2022

Zusammenfassung

Diese Dokumentation beschreibt die Konfiguration des infoGrips Conversion System (ICS).


Inhaltsverzeichnis

1. Allgemeiner Aufbau von ICS Konfigurationen
1.1. infoGrips Conversion System (ICS)
1.2. Grundstruktur von ICS Konfigurationen
1.3. Inhalt der .cfg Datei
1.4. Der RUN1 Algorithmus
2. Beispielkonfigurationen
2.1. Einleitung
2.2. Konfigurationen mit einem Inputmodul
2.3. Konfiguration mit Input- und Outputmodul
2.4. Konfiguration mit Verarbeitungsmodul
3. Konfigurieren mit ICS
3.1. Einleitung
3.2. Verwendung von Editoren
3.3. Ausführen der Konfigurationen
3.4. Hinweise und Tips
A. Input Module
1. Einleitung
2. Modul ARCGISIN - ESRI Geodatabase lesen
2.1. Allgemeines
2.2. ESRI Lizenz
2.3. Parametermap ARCGISIN_PARAM
2.4. ArcGIS SDE Connect
2.5. Objektmodell
2.6. Exportierte Prozeduren und Methoden
2.7. Skriptbeispiel
2.8. Bestehende Konfigurationen IL2GDB/IL2SDE oder GDB2IL/SDE2IL nach IL2ARCGIS/ARCGIS2IL migrieren
3. Modul DBIN - ODBC-Datenbank lesen
3.1. Allgemeines
3.2. Abhängigkeiten von anderen Modulen
3.3. Parametermap DB_PARAM
3.4. Parametermap DBIN_PARAM
3.5. Objektmodell
3.6. Datenbankmodell
3.7. Exportierte Prozeduren und Methoden
3.8. Skriptbeispiel
4. Modul DGNIN - Bentley Microstation DGN lesen
4.1. Allgemeines
4.2. Abhängigkeiten von anderen Modulen
4.3. Parametermap DGNIN_PARAM
4.4. Map für Textjustierung
4.5. Objektmodell
4.6. Exportierte Prozeduren und Methoden
4.7. Skriptbeispiel
5. Modul DXFIN - AutoCAD DXF lesen
5.1. Allgemeines
5.2. Abhängigkeiten von anderen Modulen
5.3. Parametermap DXFIN_PARAM
5.4. Objektmodell
5.5. Exportierte Prozeduren und Methoden
5.6. Skriptbeispiel
6. Modul FILEGDBIN - ESRI File-Geodatabase lesen
6.1. Allgemeines
6.2. ESRI Lizenz
6.3. Parametermap FILEGDBIN_PARAM
6.4. Objektmodell
6.5. Exportierte Prozeduren und Methoden
6.6. Skriptbeispiel
7. Modul GEOJSONIN - GeoJSON lesen
7.1. Allgemeines
7.2. Abhängigkeiten von anderen Modulen
7.3. Parametermap GEOJSONIN_PARAM
7.4. Objektmodell
7.5. Exportierte Prozeduren und Methoden
7.6. Skriptbeispiel
8. Modul GMMDBIN - Intergraph GeoMedia ACCESS Datenbank lesen
8.1. Allgemeines
8.2. Abhängigkeiten von anderen Modulen
8.3. Parametermap DB_PARAM
8.4. Parametermap DBIN_PARAM
8.5. Parametermap GMMDBIN_PARAM
8.6. Objektmodell
8.7. Exportierte Prozeduren und Methoden
8.8. Skriptbeispiel
9. Modul GMORAIN - Intergraph GeoMedia Oracle Datenbank lesen
9.1. Allgemeines
9.2. Abhängigkeiten von anderen Modulen
9.3. Parametermap DB_PARAM
9.4. Parametermap DBIN_PARAM
9.5. Parametermap ORAIN_PARAM
9.6. Parametermap GMORAIN_PARAM
9.7. Objektmodell
9.8. Spezielles
9.9. Exportierte Prozeduren und Methoden
9.10. Skriptbeispiel
10. Modul IL2IN - INTERLIS 2 lesen
10.1. Allgemeines
10.2. Abhängigkeiten von anderen Modulen
10.3. Parametermap IL2IN_PARAM
10.4. Objektmodell
10.5. Exportierte Prozeduren und Methoden
10.6. Skriptbeispiel
11. Modul ILIN - INTERLIS 1 lesen
11.1. Allgemeines
11.2. Abhängigkeiten von anderen Modulen
11.3. Parametermap ILIN_PARAM
11.4. Objektmodell
11.5. Exportierte Prozeduren und Methoden
11.6. Skriptbeispiel
12. Modul ILTOPO - INTERLIS 1 lesen mit Topologieberechnung
12.1. Allgemeines
12.2. Abhängigkeiten von anderen Modulen
12.3. Parametermap ILIN_PARAM
12.4. Parametermap ILIN_TOPO
12.5. Objektmodell
12.6. Exportierte Prozeduren und Methoden
12.7. Skriptbeispiel
13. Modul ILTXTIN - INTERLIS 1 ohne Datenmodell lesen
13.1. Allgemeines
13.2. Abhängigkeiten von anderen Modulen
13.3. Parametermap
13.4. Objektmodell
13.5. Exportierte Prozeduren und Methoden
13.6. Skriptbeispiel
14. Modul LOGIN - ICS Logdateien lesen
14.1. Allgemeines
14.2. Abhängigkeiten von anderen Modulen
14.3. Parametermap LOGIN_PARAM
14.4. Objektmodell
14.5. Exportierte Prozeduren und Methoden
14.6. Skriptbeispiel
15. Modul MYSQLIN - MySQL lesen
15.1. Allgemeines
15.2. Abhängigkeiten von anderen Modulen
15.3. Parametermap DB_PARAM
15.4. Parametermap DBIN_PARAM
15.5. Parametermap MYSQLIN_PARAM
15.6. Objektmodell
15.7. Exportierte Prozeduren und Methoden
15.8. Skriptbeispiel
16. Modul ORAIN - Oracle Datenbank lesen
16.1. Allgemeines
16.2. Abhängigkeiten von anderen Modulen
16.3. Parametermap DB_PARAM
16.4. Parametermap DBIN_PARAM
16.5. Parametermap ORAIN_PARAM
16.6. Objektmodell
16.7. Spezielles
16.8. Exportierte Prozeduren und Methoden
16.9. Skriptbeispiel
17. Modul PGRESIN - PostGreSQL/PostGIS Datenbank lesen
17.1. Allgemeines
17.2. Abhängigkeiten von anderen Modulen
17.3. Parametermap DB_PARAM
17.4. Parametermap DBIN_PARAM
17.5. Parametermap PGRESIN_PARAM
17.6. Objektmodell
17.7. Exportierte Prozeduren und Methoden
17.8. Skriptbeispiel
18. Modul SERIALIN - GeoShop Konfigurationsdateien lesen
18.1. Allgemeines
18.2. Abhängigkeiten von anderen Modulen
18.3. Parametermap SERIALIN_PARAM
18.4. Objektmodell
18.5. Exportierte Prozeduren und Methoden
18.6. Skriptbeispiel
19. Modul SHPIN - ESRI Shapefile lesen
19.1. Allgemeines
19.2. Abhängigkeiten von anderen Modulen
19.3. Parametermap SHPIN_PARAM
19.4. Objektmodell
19.5. Exportierte Prozeduren und Methoden
19.6. Skriptbeispiel
20. Modul SQLITEIN - SQLite-Datenbank lesen
20.1. Allgemeines
20.2. Parametermap SQLITEIN_PARAM
20.3. Objektmodell
20.4. Datenbankmodell
20.5. Exportierte Prozeduren und Methoden
20.6. Skriptbeispiel
21. Modul TXTIN - Textdateien lesen
21.1. Allgemeines
21.2. Abhängigkeiten von anderen Modulen
21.3. Parametermap TXTIN_PARAM
21.4. Objektmodell
21.5. Exportierte Prozeduren und Methoden
21.6. Skriptbeispiel
22. Modul XLSIN - MS EXCEL lesen
22.1. Allgemeines
22.2. Abhängigkeiten von anderen Modulen
22.3. Parametermap DB_PARAM
22.4. Parametermap DBIN_PARAM
22.5. Parametermap XLSIN_PARAM
22.6. Objektmodell
22.7. EXCEL Tabelle vorbereiten
22.8. Datenbankmodell
22.9. Exportierte Prozeduren und Methoden
22.10. Skriptbeispiel
23. Modul XMLSAX - XML lesen
23.1. Allgemeines
23.2. Abhängigkeiten von anderen Modulen
23.3. Parametermap XMLSAX_PARAM
23.4. Objektmodell
23.5. Objektmodell bei einem SAX-Ereignis
23.6. Exportierte Prozeduren und Methoden
23.7. Skriptbeispiel
B. Output Module
1. Einleitung
2. Modul ARCGISOUT - ESRI Geodatabase schreiben
2.1. Allgemeines
2.2. ESRI Lizenz
2.3. Parametermap ARCGISOUT_PARAM
2.4. ArcGIS SDE Connect
2.5. Objektmodell
2.6. Record Definitionen
2.7. Datasets
2.8. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
2.9. Topologie Flächennetze
2.10. Exportierte Prozeduren und Methoden
2.11. Skriptbeispiel
2.12. Bestehende Konfigurationen IL2GDB/IL2SDE oder GDB2IL/SDE2IL nach IL2ARCGIS/ARCGIS2IL migrieren
3. Modul DBOUT - ODBC-Datenbank schreiben
3.1. Allgemeines
3.2. Abhängigkeiten von anderen Modulen
3.3. Parametermap DB_PARAM
3.4. Parametermap DBOUT_PARAM
3.5. Objektmodell
3.6. Record Definitionen
3.7. Datasets
3.8. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
3.9. Exportierte Prozeduren und Methoden
3.10. Skriptbeispiel
4. Modul DGNOUT - Bentley Microstation DGN schreiben
4.1. Allgemeines
4.2. Abhängigkeiten von anderen Modulen
4.3. Parametermap DGNOUT_PARAM
4.4. Objektmodell
4.5. Maps für Signaturen
4.6. Map für Textjustierung
4.7. Exportierte Prozeduren und Methoden
4.8. Skriptbeispiel
5. Modul DXFOUT - AutoCAD DXF schreiben
5.1. Allgemeines
5.2. Abhängigkeiten von anderen Modulen
5.3. Parametermap DXFOUT_PARAM
5.4. Objektmodell
5.5. Maps für Signaturen
5.6. DXF Templates
5.7. Exportierte Prozeduren und Methoden
5.8. Skriptbeispiel
6. Modul FILEGDBOUT - ESRI File-Geodatabase schreiben
6.1. Allgemeines
6.2. ESRI Lizenz
6.3. Parametermap FILEGDBOUT_PARAM
6.4. Objektmodell
6.5. Record Definitionen
6.6. Datasets
6.7. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
6.8. Exportierte Prozeduren und Methoden
6.9. Skriptbeispiel
7. Modul GEOJSONOUT - GeoJSON schreiben
7.1. Allgemeines
7.2. Abhängigkeiten von anderen Modulen
7.3. Parametermap GEOJSONOUT_PARAM
7.4. Objektmodell
7.5. Exportierte Prozeduren und Methoden
7.6. Skriptbeispiel
8. Modul GMMDBOUT - Intergraph GeoMedia ACCESS Datenbank schreiben
8.1. Allgemeines
8.2. Abhängigkeiten von anderen Modulen
8.3. Parametermap DB_PARAM
8.4. Parametermap DBOUT_PARAM
8.5. Parametermap GMMDBOUT_PARAM
8.6. Objektmodell
8.7. Record Definitionen
8.8. Datasets
8.9. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
8.10. Exportierte Prozeduren und Methoden
8.11. Skriptbeispiel
9. Modul GMORAOUT - Intergraph GeoMedia Oracle Datenbank schreiben
9.1. Allgemeines
9.2. Abhängigkeiten von anderen Modulen
9.3. Parametermap DB_PARAM
9.4. Parametermap DBOUT_PARAM
9.5. Parametermap ORAOUT_PARAM
9.6. Parametermap GMORAOUT_PARAM
9.7. Objektmodell
9.8. Record Definitionen
9.9. Datasets
9.10. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
9.11. Exportierte Prozeduren und Methoden
9.12. Skriptbeispiel
10. Modul GMSQLOUT - Intergraph GeoMedia SQL Server Datenbank schreiben
10.1. Allgemeines
10.2. Abhängigkeiten von anderen Modulen
10.3. Parametermap DB_PARAM
10.4. Parametermap DBOUT_PARAM
10.5. Parametermap GMSQLOUT_PARAM
10.6. Objektmodell
10.7. Record Definitionen
10.8. Datasets
10.9. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
10.10. Exportierte Prozeduren und Methoden
10.11. Skriptbeispiel
11. Modul IL2OUT - INTERLIS 2 schreiben
11.1. Allgemeines
11.2. Abhängigkeiten von anderen Modulen
11.3. Parametermap IL2OUT_PARAM
11.4. Objektmodell
11.5. Exportierte Prozeduren und Methoden
11.6. Skriptbeispiel
12. Modul ILOUT - INTERLIS 1 schreiben
12.1. Allgemeines
12.2. Abhängigkeiten von anderen Modulen
12.3. Parametermap ILOUT_PARAM
12.4. Objektmodell
12.5. Exportierte Prozeduren und Methoden
12.6. Skriptbeispiel
13. Modul KMLOUT - Google KML schreiben
13.1. Allgemeines
13.2. Abhängigkeiten von anderen Modulen
13.3. Parametermap KMLOUT_PARAM
13.4. Objektmodell
13.5. Record Definitionen
13.6. Folder Definitionen
13.7. KML Templates
13.8. Exportierte Prozeduren und Methoden
13.9. Skriptbeispiel
14. Modul MYSQLOUT - MySQL-Datenbank schreiben
14.1. Allgemeines
14.2. Abhängigkeiten von anderen Modulen
14.3. Parametermap DB_PARAM
14.4. Parametermap DBOUT_PARAM
14.5. Parametermap MYSQLOUT_PARAM
14.6. Objektmodell
14.7. Record Definitionen
14.8. Datasets
14.9. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
14.10. Prozeduren und Methoden
14.11. Skriptbeispiel
15. Modul ORAOUT - Oracle-Datenbank schreiben
15.1. Allgemeines
15.2. Abhängigkeiten von anderen Modulen
15.3. Parametermap DB_PARAM
15.4. Parametermap DBOUT_PARAM
15.5. Parametermap ORAOUT_PARAM
15.6. Objektmodell
15.7. Record Definitionen
15.8. Datasets
15.9. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
15.10. Prozeduren und Methoden
15.11. Skriptbeispiel
16. Modul PGRESOUT - PostGreSQL/PostGIS-Datenbank schreiben
16.1. Allgemeines
16.2. Abhängigkeiten von anderen Modulen
16.3. Parametermap DB_PARAM
16.4. Parametermap DBOUT_PARAM
16.5. Parametermap PGRESOUT_PARAM
16.6. Objektmodell
16.7. Record Definitionen
16.8. Datasets
16.9. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
16.10. Prozeduren und Methoden
16.11. Skriptbeispiel
17. Modul PSOUT - PostScript (PDF,JPEG,TIF) schreiben
17.1. Allgemeines
17.2. Abhängigkeiten von anderen Modulen
17.3. Parametermap PSOUT_PARAM
17.4. Symbole Clippen
17.5. Signaturen
17.6. True Type Fonts
17.7. GhostScript
17.8. Objektmodell
17.9. Exportierte Prozeduren und Methoden
17.10. Skriptbeispiel
18. Modul SHPOUT - ESRI Shapefile schreiben
18.1. Allgemeines
18.2. Abhängigkeiten von anderen Modulen
18.3. Parametermap SHPOUT_PARAM
18.4. Objektmodell
18.5. Map für Textsignaturen
18.6. Exportierte Prozeduren und Methoden
18.7. Skriptbeispiel
19. Modul SQLITEOUT - SQLite-Datenbank schreiben
19.1. Allgemeines
19.2. Parametermap SQLITEOUT_PARAM
19.3. Objektmodell
19.4. Record Definitionen
19.5. Datasets
19.6. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
19.7. Exportierte Prozeduren und Methoden
19.8. Skriptbeispiel
20. Modul TXTOUT - Textdateien schreiben
20.1. Allgemeines
20.2. Abhängigkeiten von anderen Modulen
20.3. Parametermap TXTOUT_PARAM
20.4. Objektmodell
20.5. Record Definitionen
20.6. Exportierte Prozeduren und Methoden
20.7. Skriptbeispiel
21. Modul XLSOUT - MS Excel schreiben
21.1. Allgemeines
21.2. Abhängigkeiten von anderen Modulen
21.3. Parametermap DB_PARAM
21.4. Parametermap DBOUT_PARAM
21.5. Parametermap XLSOUT_PARAM
21.6. Objektmodell
21.7. EXCEL Tabelle vorbereiten
21.8. Record Definitionen
21.9. Datasets
21.10. Datenbank Modellgenerierung mit CONFIG_PARAM.GENERATE_MODEL
21.11. Exportierte Prozeduren und Methoden
21.12. Skriptbeispiel
C. Verarbeitungs Module
1. Einleitung
2. Modul GEOINDEX - Geometrie Index
2.1. Allgemeines
2.2. Parametermap GEOINDEX_PARAM
2.3. Objektmodell
2.4. Exportierte Prozeduren und Methoden
2.5. Skriptbeispiel
3. Modul INTERSECT - Verschnitt Flächen, Linien, Punkte
3.1. Allgemeines
3.2. Abhängigkeiten von anderen Modulen
3.3. Beispiel
3.4. Funtionsweise
3.5. Hilfskonfiguration
3.6. Parametermap INTERSECT_PARAM
3.7. Objektmodell
3.8. Exportierte Prozeduren und Methoden
3.9. Skriptbeispiel
4. Modul LIST - ICS Objekte temporär speichern
4.1. Allgemeines
4.2. Abhängigkeiten von anderen Modulen
4.3. Parametermap
4.4. Objektmodell
4.5. Exportierte Prozeduren und Methoden
4.6. Skriptbeispiel
5. Modul MAP - ICS Objekte temporär speichern
5.1. Allgemeines
5.2. Abhängigkeiten von anderen Modulen
5.3. Parametermap
5.4. Objektmodell
5.5. Exportierte Prozeduren und Methoden
5.6. Skriptbeispiel
6. Modul MTOPO - Mehrere AREA Topologien berechnen
6.1. Allgemeines
6.2. Abhängigkeiten von anderen Modulen
6.3. Parametermap TOPO_PARAM
6.4. Objektmodell
6.5. Exportierte Prozeduren und Methoden
6.6. Skriptbeispiel
7. Modul NOOP - Spezielle Initialisierungen
7.1. Allgemeines
7.2. Abhängigkeiten von anderen Modulen
7.3. Parametermap
7.4. Objektmodell
7.5. Exportierte Prozeduren und Methoden
7.6. Skriptbeispiel
8. Modul OSTREAM - ICS Objekte temporär speichern
8.1. Allgemeines
8.2. Abhängigkeiten von anderen Modulen
8.3. Parametermap
8.4. Objektmodell
8.5. Exportierte Prozeduren und Methoden
8.6. Skriptbeispiel
9. Modul PLOT - Plotlayout schreiben
9.1. Allgemeines
9.2. Abhängigkeiten von anderen Modulen
9.3. Parametermap PLOT_PARAM
9.4. Plotlayout Map PLOT_LAYOUT
9.5. Koordinatenkreuze Map PLOT_COORDCROSS_WIDTH
9.6. Skalierungsband Map PLOT_SCALEBAND_WIDTH
9.7. Werte Map PLOT_VALUES
9.8. Objekt Map PLOT_WRITE_OBJECT
9.9. Anwendung
9.10. Exportierte Prozeduren und Methoden
9.11. Skriptbeispiel
10. Modul STAT - Statistiken aus INTERLIS Daten erzeugen
10.1. Allgemeines
10.2. Abhängigkeiten von anderen Modulen
10.3. Parametermap STAT_PARAM
10.4. Objektmodell
10.5. Exportierte Prozeduren und Methoden
10.6. Skriptbeispiel
10.7. Beispiel für Statistikdatei
11. Modul SURFCUT - Flächenverschnitt
11.1. Allgemeines
11.2. Anpassung eines Script vom Modul SURFCUT auf das Modul INTERSECT.
12. Modul TOPO - Topologie berechnen
12.1. Allgemeines
12.2. Abhängigkeiten von anderen Modulen
12.3. Parametermap TOPO_PARAM
12.4. Objektmodell
12.5. Exportierte Prozeduren und Methoden
12.6. Skriptbeispiel
13. Modul VPRIO - Vektor Elimination nach Prioritäten
13.1. Allgemeines
13.2. Abhängigkeiten von anderen Modulen
13.3. Parametermap VPRIO_PARAM
13.4. Objektmodell
13.5. Exportierte Prozeduren und Methoden
13.6. Skriptbeispiel
D. iG/Script Bibliotheken
1. Einleitung
2. Skriptbibliothek OS.LIB
2.1. Allgemeines
2.2. Exportierte Prozeduren
3. Skriptbibliothek UTIL.LIB
3.1. Allgemeines
3.2. Exportierte Prozeduren
4. Skriptbibliothek TRANSFORM.LIB
4.1. Allgemeines
4.2. Parametermap TRANFORM_PARAM
4.3. Exportierte Prozeduren
4.4. Skriptbeispiel

1. Allgemeiner Aufbau von ICS Konfigurationen

1.1. infoGrips Conversion System (ICS)

Schnittstellen für den Austausch von GIS-Daten (GIS = Geographisches Informations System) werden heute meist als C/C++, BASIC- oder FORTRAN-Programme kodiert. Der Programmieraufwand für die Erstellung einer Schnittstelle ist vor allem im Bereich der GIS-Systeme gross, da neben Sachdaten auch Geometriedaten übertragen werden müssen. Dies führt dazu, dass von den GIS-Systemherstellern nur relativ wenige Schnittstellen (häufig DXF) mit begrenztem Funktionsumfang angeboten werden.

Mit der Entwicklung von ICS wurde ein anderer Weg beschritten. Bei ICS handelt es sich um ein erweiterbares Schnittstellensystem für die schnelle Entwicklung von GIS-Schnittstellen. Folgende Ideen lagen der Entwicklung von ICS zugrunde:

  • Jedes Schnittstellenprogramm kann in einen Input- und in einen Outputmodul zerlegt werden. Dabei liest der Inputmodul Objekte aus der Inputdatei und wandelt sie in ein neutrales internes Objektformat um. Der Outputmodul nimmt Objekte vom Inputmodul entgegen und schreibt sie in die Outputdatei. Damit wird eine Entkoppelung des Schnittstellenprogramms in zwei unabhängige, wiederverwendbare Module erreicht.

  • Im Kern werden die Funktionen zusammengefasst, die von allen Modulen benötigt werden (z.B. String- und Geometriefunktionen). Dadurch müssen diese Funktionen nur einmal programmiert werden.

  • Der Datenfluss der Objekte vom Inputmodul zum Outputmodul wird nicht durch ein fix kodiertes Programm gesteuert, sondern über die Skriptsprache iG/Script.

Nachfolgend ist die Architektur einer ICS-Schnittstelle dargestellt:

Abbildung 1. ICS Architektur

ICS Architektur
[Anmerkung]

Der Kern und die Input- bzw. Outputmodule werden von der infoGrips GmbH entwickelt. iG/Script-Konfigurationen können auch vom Benutzer geschrieben werden.

Der ICS-Kern enthält neben den allgemeinen Funktionen für die Behandlung von Datenstrukturen (Strings, Geometrie, Maps etc.) einen Interpreter für die Sprache iG/Script. iG/Script ist eine allgemeine Programmiersprache mit einem vordefinierten Satz von Standardfunktionen. Die Sprache enthält neben arithmetischen-, logischen- und Zuweisungsoperationen, Kontrollstrukturen wie IF und WHILE. Daneben bietet sie die Möglichkeit, den Sprachumfang durch Prozeduren zu erweitern. Als Basistypen kennt die Sprache iG/Script die Typen Integer, Real, String, Boolean und Geometrie. Strukturierte Datentypen können über den Datentyp Map und List erzeugt werden. Input- bzw. Outputmodule können, falls nötig, zusätzliche Datentypen implementieren.

Zu bestehenden Programmiersprachen ist iG/Script am ehesten mit der Programmiersprache FORTH verwandt. Mit FORTH verbindet sie, dass sie ebenfalls alle Operationen über einen Stack abwickelt und eine klammerfreie Darstellung von Ausdrücken verwendet. Der wesentliche Unterschied zwischen FORTH und iG/Script liegt darin, dass FORTH für die hardwarenahe Programmierung entwickelt wurde, iG/Script hingegen ist eine hardwareunabhängige Sprache, die sich besonderst für die Entwicklung von Schnittstellenapplikationen eignet.

iG/Script ist im iG/Script Benutzer- und Referenzhandbuch detailliert beschrieben.

1.2. Grundstruktur von ICS Konfigurationen

Jeder ICS Konfigurationsscript besteht aus folgenden Skriptteilen:

  • Der .cfg Konfigurationsdatei, welche alle Konfigurationsparameter enthält und den Datenfluss der Schnittstelle regelt.

  • Den (optionalen) .out Dateien, welche benutzerdefinierte iG/Script Prozeduren enthalten.

  • Den .lib Dateien, welche nützliche Sammlungen von iG/Script Prozeduren enthalten.

  • Den .mod Dateien, welche Input-, Output- oder Verarbeitungsmodule implementieren.

  • Dem Verarbeitungsalgorithmus RUN1.

Will ein Benutzer eine ICS Konfiguration erstellen, so muss er eine .cfg Datei und allenfalls eine oder mehrere .out Datei erzeugen. Die übrigen Konfigurationsteile (d.h. .lib, .mod und .prg Dateien) werden von der infoGrips GmbH zur Verfügung gestellt, und sind vollständig in diesem Handbuch dokumentiert. Nachfolgend ist die Aufteilung einer ICS Konfiguration in ihre Skriptteile dargestellt:

Abbildung 2. Grundstruktur von ICS Konfigurationen

Grundstruktur von ICS Konfigurationen

Die benutzerdefinierbaren Konfigurationsteile sind in den nächsten Abschnitten beschrieben. Die Beschreibung der von der infoGrips GmbH zur Verfügung gestellten Komponenten ist in den Anhängen dieser Dokumentation enthalten.

1.3. Inhalt der .cfg Datei

Die .cfg Datei enthält folgende Konfigurationsteile:

  • Die Angabe der Lizenzinformationen.

  • Die Definition des Benutzerinputs.

  • Die Parameter für die Input-, Output- bzw. Verarbeitungsmodule.

  • Die Definition der Inputquellen.

  • Die Festlegung des Verarbeitungsablaufs.

  • Die Angabe der benötigten Skriptbibliotheken.

  • Die Angabe der benötigten Input-, Output- und Verarbeitungsmodule.

  • Die Angabe der verwendeten Benutzerprozeduren.

  • Die Angabe des Verarbeitungsalgorithmus RUN1.

Nachfolgend ist ein typisches Beispiel einer .cfg Datei dargestellt, an welchem die einzelnen Konfigurationsteile kurz vorgestellt werden:

!===============================================================!
!                                                               !
! INTERLIS => TEXT Configuration Vers. 1.0                      !
!                                                               !
!===============================================================!

!<1>
|LICENSE \license\iltoolspro.lic
|LICENSE \license\iltools.lic

!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!
! user input
!

!<2a>
MAP USER_INPUT1
   DIALOG => FILE ! FILE | STRING | ODBC
   MESSAGE => 'Enter .itf Input File'
   FILE_FILTER => itf
   FILE_EXISTS => TRUE
   OPT => input
END_MAP

!<2b>
MAP USER_INPUT2
   DIALOG => FILE ! FILE | STRING | ODBC
   MESSAGE => 'Enter .txt Output File'
   FILE_FILTER => txt
   FILE_EXISTS => FALSE
   OPT => output
END_MAP

!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!
! parameter maps for intput modules
!

!<3a>
MAP ILIN_PARAM
   INTERLIS_DEF => \models\Grunddatensatz.ili
   LOG_TABLE    => ON
   TRACE        => OFF
   STATISTICS   => ON
   VALUE_CHECK  => OFF
   ENUM_TO_TEXT => ON
END_MAP

!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!
! parameter maps for output modules
!

!<3b>
MAP TXTOUT_PARAM
   STATISTICS => ON
END_MAP

!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!
! input sources
!

!<4>
MAP INPUT_SOURCES
   I1 => ILIN,OPT.input
END_MAP

!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
!
! classification
!

!<5>
MAP INOUT
   I1 => IN.TOPIC,IN.TABLE
   I1,Fixpunkte,LFP  => Fix_Punkt0
   I1,Fixpunkte,LFP3 => Fix_Punkt0
   I1,* => OFF
END_MAP

!<6>
|INCL \script\util.lib
!<7>
|INCL \script\ilin.mod
|INCL \script\txtout.mod
!<8>
|INCL \script\il2txt\Grunddatensatz.out
!<9>
|INCL \script\run1.prg

Erläuterungen zu den einzelnen Konfigurationsteilen:

  1. Mit der |LICENSE Direktive werden die von der Konfiguration benötigten Lizenzen angegeben. Es können mehrere Lizenzdateien angebeben werden, wenn die Konfiguration unter verschiedenen Lizenzen lauffähig ist (z.B. INTERLIS Tools und INTERLIS Tools Professional). Falls diese Angaben vergessen werden, bricht die Konfiguration zur Laufzeit mit einer Fehlermeldung ab (no license found for ...).

  2. Die meisten Konfigurationen verlangen vom Benutzer interaktive Eingaben (z.B. Auswahl der Inputdatei bzw. Angabe der Outputdatei). Mit den USER_INPUTx Maps können beliebig viele Parameter interaktiv vom Benutzer abgefragt werden (s.a. ???).

  3. Alle Input-, Output- und Verarbeitungsmodule benötigen diverse Parameter, z.B. die Angabe des Datenmodells für einen INTERLIS 1 Outputmodul. Die Parameter für die diversen von der Konfiguration benötigten Module werden in den <MODUL>_PARAM Maps definiert. Alle Parameter der einzelnen Module sind im Anhang beschrieben. Einige Module benötigen neben der <MODUL>_PARAM Map noch weitere Angaben (z.B. Symbologie Maps für den DXFOUT Modul). In diesem Fall ist das ebenfalls in der Moduldokumentation im Anhang beschrieben.

  4. In der Map INPUT_SOURCES wird festgelegt, in welcher Reihenfolge die Inputmodule ausgelesen werden (s.a. ???).

  5. Die INOUT Map legt fest, wie die von den Inputmodulen gelesenen Objekte an die Verarbeitungs- bzw. Outputmodule weiter geleitet werden (s.a. ???).

  6. Skriptbibliotheken werden mit der |INCL Direktive eingebunden. Die verfügbaren Skriptbibliotheken sind im Anhang beschrieben.

  7. Alle benötigten Input-, Output- und Verarbeitungsmodule müssen mit |INCL eingebunden werden. Die verfügbaren Module sind im Anhang beschrieben.

  8. Falls die Konfiguration benutzerdefinierte Prozeduren verwendet, müssen diese mit |INCL eingebunden werden (s.a. ???).

  9. Schliesslich muss mit |INCL \script\run1.prg der Verarbeitungsalgorithmus angegeben werden, welcher den Inhalt der .cfg Datei interpretiert. Im Moment steht der RUN1 Algorithmus zur Verfügung (s.a. ???).

1.4. Der RUN1 Algorithmus

Der RUN1 Algorithmus interpretiert den Inhalt der .cfg Datei und steuert die Input-, Output- und Verarbeitungsmodule. Der RUN1 Algorithmus ist in der Skriptdatei \script\run1.prg implementiert. Diese Datei muss daher am Ende jeder .cfg Datei mit |INCL eingebunden werden. Der RUN1 Algorithmus verfügt über folgende Eigenschaften:

  • Kann beliebig viele Parameter vom Benutzer interaktiv abfragen.

  • Kann beliebig viele Inputquellen verarbeiten.

  • Kann beliebig viele Input-, Output- und Verarbeitungsmodule über die INOUT Map verknüpfen.

  • Kann Macros aus der Map MACRO verarbeiten.

  • Kann parametrisierte Benutzerprozeduren aufrufen.

  • Kann Triggerprozeduren aufrufen.

Die Einzelnen Eigenschaften von RUN1 werden in den folgenden Unterabschnitten näher erläutert.

1.4.1. Abfrage von Benutzerparametern

Sollen in einer Konfiguration interaktiv Parameter abgefragt werden (z.B. Input- und Outputdatei), so müssen in der .cfg Datei Maps der Form USER_INPUTx angelegt werden, wobei x für eine Zahl zwischen 1 .. 9 steht. Die USER_INPUTx Maps werden vom RUN1 Algorithmus in der Reihenfolge ihrer Nummer ausgewertet (zuerst 1, dann 2, dann 3, etc.). Nachfolgend ist ein Beispiel für eine USER_INPUT Map dargestellt:

MAP USER_INPUT2
   DIALOG => FILE ! FILE | FILES | ZIP | STRING | ODBC
   MESSAGE => 'Enter .txt Output File'
   FILE_FILTER => txt
   FILE_EXISTS => FALSE
   OPT => output
END_MAP

Das obige Beispiel fragt vom Benutzer eine Datei ab (DIALOG => FILE), welche nicht bereits existiert (FILE_EXISTS => FALSE) und die Endung .txt aufweisen muss (FILE_FILTER => txt). Die einzelnen Parameter der USER_INPUT Maps haben folgende Bedeutung:

DIALOG
FILE

Der Benutzer muss eine Datei auswählen. Ob die Datei bereits existieren muss oder nicht, wird mit dem Parameter FILE_EXISTS (TRUE | FALSE) festgelegt. Weiter kann mit FILE_FILTER angegeben werden, welche Dateieendung die Datei aufweisen muss.

FILES

Im Prinzip gleich wie FILE mit dem Unterschied, dass mehrere Dateien vom Benutzer ausgewählt werden können.

ZIP

Erweiterung zu FILE. Es muss ein .zip Archiv ausgewählt werden. In ZIP_FILTER kann zusätzlich ein Filter für die aus dem Archiv zu selektierenden Dateien angegeben werden.

DIRECTORY

Der Benutzer muss ein Dateiverzeichnis auswählen.

STRING

Der Benutzer muss eine Zeichenkette (String) eingeben.

ODBC

Der Benutzer muss eine bestehende ODBC Datenquelle auswählen.

ODBC_FILE

Der Benutzer muss eine bestehende ODBC Datenquelle oder ein Datenbankfile auswählen.

ARCGIS

Der Benutzer muss eine bestehende ArcGISI SDE Connection oder ein ArcGIS Datenbankfile auswählen.

PROCEDURE

Es wird eine vom Benutzer unter PROCEDURE_NAME angegebene Prozedur aufgerufen, welche den Parameterwert abfragt. Die Prozedur muss als Resultat einen String oder eine Liste von Strings auf dem Stack zurück liefern.

CONSTANT

Der Parameterwert ist eine Konstante. Der Parameterwert kann in OPT_VALUE gesetzt werden.

MESSAGE

Meldung welche dem Benutzer bei der Abfrage des Parameters angezeigt werden soll. Bemerkung: Falls die Meldung Leerzeichen enthält, muss die Meldung zwischen Hochkommas gestellt werden.

OPT

Name unter welchem der Wert des Parameters in der OPT Map abgespeichert werden soll.

1.4.2. Inputquellen

Von einer ICS Konfiguration können gleichzeitig mehrere Inputquellen verarbeitet werden. Inputquellen lesen Objekte von einer externen Datenquelle (z.B. INTERLIS-Datei, ODBC-Datenbank) und wandeln diese Objekte in eine interne Struktur um (IN-Objekt). Der Benutzer muss die von ihm benötigten Inputquellen in der Map INPUT_SOURCES definieren.

Beispiel 1. Definition von Inputquellen

MAP INPUT_SOURCES
   I1 => ILIN,OPT.input
   D1 => DB,features
END_MAP

Erläuterungen zum obigen Beispiel:

  • In der Map INPUT_SOURCES wurden die Inputquellen I1 und D1 definiert.

  • Die Quelle I1 liest Inputobjekte aus der vom Benutzer gewählten INTERLIS-Inputdatei (OPT.input) welche in ILIN_PARAM konfiguriert wurde.

  • Die Quelle D1 liest Datensätze aus der Tabelle features einer relationalen Datenbank, die in DB_PARAM konfiguriert wurde.

Es ist erlaubt beliebig viele Inputquellen (z.B. mehrere INTERLIS-Quellen und mehrere Datenbankquellen) gleichzeitig zu definieren. Die Inputquellen werden von RUN1 in der Reihenfolge geöffnet und gelesen, in der sie definiert wurden (hier: zuerst I1, dann D1).

1.4.3. Die INOUT Map

Alle von den Inputquellen gelieferten Objekte müssen klassifiziert werden. Die Klassifikation wird nach folgendem Schema durch Einträge in der Map INOUT ermittelt:

  1. Die erste Klassifikation ist der Name der gerade aktiven Inputquelle (z.B. I1).

  2. In den folgenden Schritten wird versucht, die Klassifikation zu verfeinern. Dazu wird die aktuelle Klassifikation erneut durch die Map INOUT abgebildet.

  3. Falls die Abbildung eine Abbildungsvorschrift liefert, ist die Klassifikation abgeschlossen. Das Resultat der Klassifikation ist die Abbildungsvorschrift (z.B. COPY). Weiter mit Schritt 7.

  4. Falls die Abbildung den Namen einer IN-Objekt Komponente liefert (z.B. IN.TABLE) wird der Wert (z.B. BoFlaeche) der Komponente an die aktuelle Klassifikation durch eine Komma getrennt angehängt. Weiter mit Schritt 2.

  5. Falls die Klassifikation in der Map INOUT keine Abbildung hat, wird der letzte Teil der aktuellen Klassifikation durch * ersetzt. Weiter mit Schritt 2.

  6. Falls noch immer keine Abbildung gefunden werden konnte, ist dies ein Fehler. Das Objekt wird in die Map UNDEFINED_OBJECTS eingetragen. Fertig.

  7. Falls die Abbildungsvorschrift gleich OFF ist, wird das Objekt ignoriert (bzw. in die Map IGNORED_OBJECTS eingetragen), sonst wird die gefundene Abbildungsvorschrift ausgeführt.

Im folgenden Beispiel werden Objekte aus der INTERLIS Tabelle Fixpunkte.HFP je nach Inhalt der Komponente IN.TOPIC und IN.TABLE klassifiziert.

Beispiel 2. INOUT Map

MAP INOUT
   I1 => IN.TOPIC,IN.TABLE
   I1,Fixpunkte,HFP => COPY_IN_OUT0
END_MAP

Erläuterungen:

  • Da die Daten von der Inputquelle I1 gelesen werden, ist der Wert der ersten Klassifikation für jedes Objekt I1 (Schritt 1).

  • I1 wird durch INOUT abgebildet das Resultat ist IN.TOPIC,IN.TABLE (Schritt 2).

  • Da es sich bei IN.TOPIC,IN.TABLE um Komponenten des IN-Objekts handelt, wird der Inhalt von IN.TOPIC,IN.TABLE durch ein Komma getrennt an die aktuelle Klassifikation angehängt (hier: I1,Fixpunkte,HFP)(Schritt 4).

  • Die aktuelle Klassifikation wird wieder durch INOUT abgebildet (Schritt 2) und man erhält schliesslich COPY_IN_OUT0 (Schritt 3).

  • COPY_IN_OUT0 ist eine Abbildungsvorschrift, die von ICS ausgeführt wird.

Man kann das obige Beispiel auch als eine speziell kodierte IF Anweisung verstehen. Der iG/Script Code dazu lautet wie folgt:

IF VAR.SOURCE = 'I1' THEN
   IF IN.TOPIC = 'Fixpunkte' THEN
      IF IN.TABLE = 'HFP' THEN
         COPY_IN_OUT0
      END_IF
   END_IF
END_IF

1.4.4. Ausführen der Abbildungsvorschrift

Die in ??? gefundenen Abbildungsvorschriften werden nach folgendem Schema ausgeführt:

  1. Die Abbildungsvorschrift ist eine Liste von iG/Script Prozeduren und/oder Macros.

  2. Alle Macros werden durch ihren Wert ersetzt (Macros können in der Map MACRO deklariert werden, s.a. 4.1.7).

  3. Falls das erste Element der Liste eine iG/Script Prozedur ist, wird die Prozedur aufgerufen. Weiter mit Schritt 5.

  4. Falls das erste Element der Liste keine iG/Script Prozedur ist, ist dies ein Fehler (unknown procedure ...). Fertig.

  5. Die Prozedur wird ausgeführt und die aktuelle Abbildungsvorschrift wird um die Prozedur und ihre Argumente reduziert.

  6. Falls die Abbildungsvorschrift nach der Reduktion leer ist, sind wir fertig.

  7. Falls die Liste nach der Reduktion nicht leer ist, weiter mit Schritt 3.

1.4.5. Die MACRO Map

In der Map MACRO können Sie Abbkürzungen für häufig gebrauchte Prozeduraufrufe und/oder Argumente definieren.

Beispiel 3. MACRO Map

MAP MACRO
   DIN => DISPLAY_OBJECT1,IN
END_MACRO

Hier wurde z.B. der Macro DIN definiert. Der Macro wird zur Laufzeit durch seinen Wert ersetzt (hier: DISPLAY_OBJECT,IN). Der Macro DIN kann nun in jeder Abbildungsvorschrift der INOUT Map benutzt werden.

1.4.6. Benutzerprozeduren in Abbildungsvorschriften

Der Benutzer kann ICS Konfigurationen mit eigenen iG/Script Prozeduren ergänzen. Die neuen Prozeduren sollten in einer .out Datei definiert werden. Die benutzerdefinierten Prozeduren können in jeder Abbildungsvorschrift benutzen werden. Es ist sogar möglich Prozeduren mit Parametern zu definieren. Die Programmiersprache iG/Script ist ausführlich im iG/Script Benutzer- und Referenzhandbuch beschrieben.

Benutzerprozeduren müssen ihre Parameter mit den vordefinierten Prozeduren:

GET_SPARAM

String Parameter.

GET_IPARAM

Integer Parameter.

GET_RPARAM

Real Parameter.

GET_PPARAM

Punkt Parameter.

GET_LPARAM

Linien Parameter.

GET_APARAM

Flächen Parameter.

GET_PARAM

Beliebiges ICS-Objekt.

Diese Prozeduren sind in der Skriptbibliothek \script\util.lib definiert.

Beispiel 4. Parameterübernahme in Benutzerprozeduren

PROCEDURE Bodb_Centroid1 ! Art
   'Bodenbedeckung' => OUT.TOPIC
   'BoFlaeche' => OUT.TABLE
   IN.OBJID => OUT.OBJID
   IN.Geometrie => OUT.Geometrie
   GET_SPARAM => OUT.Art
   WRITE_OBJECT
END_PROCEDURE

Die Prozedur Bodb_Centroid1 schreibt eine Bodenbedeckungszentroid in die INTERLIS Transferdatei. Die Prozedur übernimmt den Artcode (Art) des Zentroids als Parameter. Die neue Prozedur kann wie folgt in einer Abbildungsvorschrift der INOUT Map benutzt werden:

MAP INOUT
   ...
   I1,Bodenbedeckung,BoFlaeche => Bodb_Centroid1,befestigt.Bahn
   ...
END_MAP

Beim Ausführen der Abbildungsvorschrift wird die Prozedur Bodb_Centroid1 mit dem Parameter befestig.Bahn aufgerufen und damit ein Centroid in der INTERLIS-Tabelle BoFlaeche erzeugt.

[Anmerkung]

Die Zahl 1 am Schluss des Namens der Benutzerprozedur, gibt an, dass die Benutzerprozedur einen Parameter verlangt. Die Angabe der Anzahl Parameter im Benutzerprozedurnamen ist obligatorisch. Falls die Prozedur keine Parameter übernimmt, muss 0 angegeben werden.

1.4.7. Triggerprozeduren

Triggerprozeduren sind Prozeduren, welche in einem bestimmten Moment in der Konfiguration automatisch aufgerufen werden. Der RUN1 Algorithmus unterstützt folgende Triggerprozeduren:

PRE_TRANSFER

Wird einmal vor dem Öffnen aller Sourcen aufgerufen.

PRE_SOURCE_<SOURCE>

Wird vor dem Öffnen der Source <SOURCE> aufgerufen.

PRE_OPEN_<SOURCE>

Wird aufgerufen bevor Objekte aus der Source <SOURCE> ausgelesen werden. Die <SOURCE> ist aber bereits offen (im Gegensatz zu PRE_SOURCE_<SOURCE>).

[Anmerkung]

In älteren Versionen der INTERLIS Tools wurde PRE_OPEN_<SOURCE> vor PRE_SOURCE_<SOURCE> aufgerufen. Falls alte Konfigurationen von dieser Reihenfolge der Trigger abhängig sind, müssen sie auf die neue Reihenfolge umgestellt werden.

[Anmerkung]

Falls mit der in der USER_INPUTx Map der Dialog FILES ausgewählt wurde, wird PRE_OPEN_<SOURCE> und POST_CLOSE_<SOURCE> für jede ausgewählte Datei einmal aufgerufen.

PRE_INOUT_<SOURCE>

Wird vor dem Durchlaufen der INOUT Map aufgerufen. Dieser Trigger kann z.B. für die Berechnung von virtuellen Attributen benutzt werden.

[Anmerkung]

In älteren Versionen der INTERLIS Tools hiess dieser Trigger POST_READ_<SOURCE>. Aus Kompatibiltätsgründen ist daher POST_READ_<SOURCE> weiterhin mit der gleichen Bedeutung verfügbar.

POST_INOUT_<SOURCE>

Wird nach dem Durchlaufen der INOUT Map aufgerufen.

POST_CLOSE_<SOURCE>

Wird vor dem Schliessen der Source <SOURCE> aufgerufen.

POST_SOURCE_<SOURCE>

Wird nach dem Schliessen der Source <SOURCE> aufgerufen.

POST_TRANSFER

Wird einmal nach dem Schliessen aller Sourcen aufgerufen.

Den gleichen Effekt wie mit Triggern kann man z.T. auch durch Verwendung der Pseudoinputquelle NOOP erreichen. NOOP ist eine spezielle Datenquelle die nur ein einziges Objekt liefert. Diese Eigenschaft kann man z.B. wie folgt nutzen:

MAP INPUT_SOURCES
   N1 => NOOP
   M1 => MSIN,OPT.input
END_MAP
MAP INOUT
   N1 => MeineInitialisierung0
   M1 => ... ! etc.
END_MAP

Die Inputquellen werden von ICS in der Reihenfolge geöffnet und gelesen, in der sie definiert wurden, d.h. zuerst N1 (NOOP) und dann M1 (MSIN). Das von NOOP generierte Objekt bewirkt, dass die Benutzerprozedur MeineInitialisierung0 einmal aufgerufen wird (z.B. für spezielle Initialisierungen von Benutzermaps). In diesem Fall hätte man das Gleiche jedoch auch ohne NOOP, mit einem PRE_SOURCE_M1 Trigger, erreichen können.

[Anmerkung]

Wir empfehlen die Verwendung von NOOP, wenn die Initialisierung nicht direkt mit einem bestimmten Inputmodul zu tun hat. Wenn es jedoch nur darum geht z.B. die Quelle I1 zu intialisieren, dann soll auch PRE_SOURCE_I1 für die Initialisierung der Quelle benutzt werden.