KURTOGLU
SINAN

Ingenieur für Elektrotechnik & Elektronik
Embedded Systems · Energie · Software

Stadt­informations­system Eskişehir — Kommunale Daten, GIS & System­integration

Eskişehir | 1998–2004

Modernisierung kommunaler Systeme, gemeinsame Bürgerdatensätze, stadtweite Felderhebungen, Migration von Altdaten, Server­infrastruktur, ein kommunen­übergreifendes Glasfaser-Backbone und MIS/GIS-Integration.

Projekthintergrund

Die Arbeit begann 1998 mit dem Ziel, eine gemeinsame, verlässliche Informationsinfrastruktur für die Kommunen von Eskişehir zu entwickeln. Der Umfang reichte von der Prüfung der bestehenden kommunalen Anwendungen bis zur Verbindung von Verwaltungsdaten, Geoinformationen, Felddaten und der Infrastruktur, die sie unterstützt.

Damals stützten sich die kommunalen Abläufe überwiegend auf getrennte COBOL-basierte Anwendungen, die von SAMPAŞ geliefert wurden. Diese Anwendungen unterstützten ihre jeweiligen Aufgaben, aber ihre zugrunde liegenden Datenstrukturen bereiteten Schwierigkeiten, wenn Datensätze über Kommunen und Fachabteilungen hinweg gemeinsam genutzt werden mussten.

Dieselbe Person konnte mehrere Registrierungsnummern haben, die über viele Jahre von verschiedenen Fachabteilungen, Kommunen oder bei verschiedenen Vorgängen vergeben worden waren. Doppelte Bürger- und Steuerpflichtigendatensätze erschwerten es, verlässliche Beziehungen zwischen Personen, Liegenschaften, Veranlagungen und kommunalen Vorgängen herzustellen.

Die Arbeit fand zudem statt, bevor der Abgleich und die Überprüfung anhand nationaler Identitätsdaten zu einem routinemäßigen Bestandteil kommunaler Informations­systeme geworden waren. Eine einheitliche Identität über die vorhandenen Datensätze hinweg herzustellen, erforderte daher umfangreiche Analyse und Abstimmung.

Ausgangspunkt war das Verhältnis zwischen Identität, Registrierungsdatensätzen, Datenintegrität und Informationsaustausch. Dieses Verhältnis wurde zur Grundlage des umfassenderen Stadt­informations­systems.

1. Bewertung der bestehenden Systeme und Daten

Die erste Phase bestand darin, die bestehenden kommunalen Anwendungen, ihre Datenstrukturen und die Art, wie die Fachabteilungen sie nutzten, zu untersuchen.

Bevor Ersatzsoftware eingeführt wurde, mussten wir den Zustand der vorhandenen Daten verstehen und herausfinden, wo die Systeme Inkonsistenzen erzeugten.

Zu den Hauptproblemen gehörten:

  • Mehrfache Registrierungsdatensätze für dieselbe Person.
  • Getrennte Bürger- und Steuerpflichtigendatensätze, die von verschiedenen Kommunen geführt wurden.
  • Abteilungsspezifische Datensätze, die an einzelnen betrieblichen Anforderungen ausgerichtet waren.
  • Historische Datensätze in uneinheitlichen Formaten.
  • Unzuverlässige Beziehungen zwischen Personen und Liegenschaftsdatensätzen.
  • Begrenzter Informationsaustausch zwischen Einrichtungen.
  • Fehlende direkte Verknüpfungen zwischen physischen Merkmalen der Stadt und Verwaltungsdatensätzen.
  • Das Fehlen eines aktuellen stadtweiten Bestandsverzeichnisses, das mit den Gegebenheiten vor Ort abgeglichen werden konnte.

Die Bewertung ergab, dass verlässliche Daten eine Voraussetzung für das umfassendere System waren. Die vorhandenen Datensätze mussten zunächst geprüft, abgestimmt und für die gemeinsame Nutzung geeignet gemacht werden.

2. Ein gemeinsames Bürgerregister

Ein zentraler Teil des Ansatzes war, jede Person nach Möglichkeit über einen gemeinsamen Registerdatensatz zu identifizieren, statt für jeden kommunalen Dienst einen weiteren unabhängigen Datensatz anzulegen.

Die angestrebte Beziehung war:

Person → Gemeinsamer Registerdatensatz → Kommunale Vorgänge

Dies erforderte mehr als die Vergabe einer gemeinsamen Nummer. Dieselbe Person konnte unter verschiedenen Namensschreibweisen, Adressen, unvollständigen Angaben, historischen Datensatzformaten oder Abteilungsdatensätzen auftreten.

Die Arbeit umfasste daher:

  • Prüfung der vorhandenen Datensätze.
  • Identifizierung möglicher Dubletten.
  • Abgleich zusammengehöriger Datensätze über Systeme hinweg.
  • Erhalt der Integrität der zugehörigen Vorgänge.
  • Entwicklung eines gemeinsamen Datenmodells.

Dieser Ansatz des gemeinsamen Registers bildete eine Grundlage, um Datensätze über kommunale Dienste hinweg zu verbinden, und wurde zu einem wesentlichen Bestandteil des entstehenden Stadt­informations­systems.

3. Festlegung der technischen Anforderungen

Die Umsetzung des Ansatzes mit gemeinsamem Register erforderte koordinierte Änderungen an der unterstützenden Infrastruktur.

Die Anforderungen betrafen Serverkapazität, Speicher, Datensicherung, Clientsysteme, Netzwerkinfrastruktur, Kommunikation zwischen Einrichtungen, Datenmigration, Benutzerorganisation und technisches Personal.

Bewertungen der erforderlichen Hardware, Netzwerkinfrastruktur, des Personals und der technischen Kapazität wurden erstellt und der Leitung vorgelegt.

Mit zunehmender Klarheit dieser Anforderungen entwickelte sich die Arbeit zu einem Projekt für eine kommunale Informationsinfrastruktur mit mehreren voneinander abhängigen technischen und betrieblichen Ebenen.

4. Stadtweite Felderhebungen und das Einwohner- und Liegenschafts­verzeichnis

Vorhandene Computerdatensätze allein konnten kein ausreichend verlässliches Bild der Stadt liefern. Sie mussten mit Gebäuden, Nutzungseinheiten, Adressen und der tatsächlichen Belegung oder Nutzung abgeglichen werden.

Eine stadtweite Felderhebung wurde geplant, um diese Informationen direkt zu erfassen.

Ausgehend von den optischen Formularen, die damals im Hochschulbereich und bei zentralen Prüfungen verwendet wurden, schlug ich einen Ansatz mit optischen Formularen vor, um die effiziente Digitalisierung großer Mengen von Erhebungsdaten zu unterstützen.

Nach den erforderlichen Verwaltungsgenehmigungen und Beschlüssen der Stadträte wurden die Formulare in der Druckerei der Anadolu University vorbereitet und gedruckt.

Feldteams erfassten Informationen in einer Erhebung nach Art einer Volkszählung und dokumentierten:

  • Gebäude.
  • Nutzungseinheiten innerhalb von Gebäuden.
  • Adressen.
  • Einwohner und Nutzungsmuster.

Die Erhebung weitete sich zu einem umfangreichen stadtweiten Einwohner- und Liegenschafts­verzeichnis aus. Sie lieferte eine feldbasierte Informationsquelle, anhand derer die vorhandenen kommunalen Datensätze bewertet und aktualisiert werden konnten.

5. Wachsende Datenmengen und Server­infrastruktur

Mit der Ausweitung des Feldverzeichnisses nahm das Datenvolumen rasch zu.

Die Systeme mussten außerdem die Aufbewahrung historischer Datensätze, die Aufnahme neu erfasster Informationen, den gemeinsamen Zugriff zwischen Kommunen und die Einführung weiterer kommunaler Anwendungen unterstützen.

Diese zusammenwirkenden Anforderungen erhöhten den Druck auf Server- und Speicherkapazität. Neue Serversysteme wurden installiert und konfiguriert, um die wachsende Last zu bewältigen.

Die Anforderung reichte über die Rechenleistung hinaus. Kommunen und Einrichtungen an getrennten Standorten benötigten verlässlichen, schnellen Zugriff auf gemeinsame Informationsressourcen.

Die Architektur entwickelte sich dadurch entlang einer verbundenen Abfolge:

Felddatenerfassung → Gemeinsame Datenressourcen → Server­infrastruktur → Konnektivität zwischen Einrichtungen

Die Unterstützung von Systemen an getrennten Standorten machte eine schnelle Glasfaserverbindung zunehmend notwendig.

Damals beschrieben wir die entstehende Architektur nicht mit Begriffen wie Stretched Clusters, SAN-Erweiterung oder verteilter Server- und Speicherinfrastruktur. Die Arbeit bewegte sich jedoch bereits in diese Richtung: Server- und Datenressourcen über getrennte physische Standorte hinweg auszudehnen und über ein gemeinsames, schnelles Glasfaser-Backbone zu verbinden.

Die praktische Anforderung war klar: Systeme an verschiedenen Standorten mussten zusammenarbeiten, mit verlässlichem Zugriff auf gemeinsame Datenressourcen.

6. Erhalt und Migration von Altdaten

Der Erhalt der Daten, die sich über Jahre kommunaler Tätigkeit angesammelt hatten, war eine zentrale Anforderung des Übergangs.

Die vorhandenen SAMPAŞ- und COBOL-basierten Anwendungen enthielten Datensätze, die verfügbar und nutzbar bleiben mussten, als die Kommune zu Lösungen von İztek A.Ş. überging.

Die Migrationsarbeit umfasste:

  • Untersuchung der vorhandenen Datenstrukturen.
  • Vergleich der Datenmodelle von Alt- und Ersatzsystem.
  • Bereinigung von Datensätzen.
  • Prüfung auf Dubletten.
  • Neubewertung der Beziehungen zwischen Personen und Registrierungsdatensätzen.
  • Umwandlung der Daten in die erforderlichen Formate.
  • Migration der Daten.
  • Prüfung der Integrität der übertragenen Datensätze.

Ziel war es, Daten zu erzeugen, die über die neuen kommunalen Anwendungen hinweg abgeglichen, in Beziehung gesetzt und genutzt werden konnten, und dabei ihren historischen Wert zu bewahren.

7. Gemeinsame Daten und Unternehmens­anwendungen

Die Ersatzumgebung führte DB2-Datenbanken und Java-basierte Unternehmens­anwendungen ein.

Dies unterstützte die vorgesehene Nutzung gemeinsamer zugrunde liegender Datenressourcen über die kommunalen Fachabteilungen hinweg.

Das Arbeitsmodell war:

Gemeinsame Daten → Unternehmens­anwendungen → Kommunale Fachabteilungen → Kommunale Dienstleistungen

Informationen wurden zunehmend zu einer gemeinsamen institutionellen Ressource, mit Beziehungen, die mehrere kommunale Prozesse unterstützen konnten.

8. Planung der Glasfaser­infrastruktur während der ESTRAM-Bauarbeiten

Anfang 2002 waren die Straßen entlang der ESTRAM-Trassen gesperrt, und große Tiefbauarbeiten waren im Gange.

Zu diesem Zeitpunkt hatten sich die Felderhebungen intensiviert, die Datenmengen waren gewachsen, neue Serversysteme waren installiert worden, und der Bedarf an schneller Kommunikation zwischen Einrichtungen war deutlich geworden.

Die laufenden Ausschachtungsarbeiten boten die Gelegenheit, Glasfasertrassen vorzubereiten, solange die Straßen bereits offen waren. Dies würde künftige Kommunikationsanforderungen unterstützen, ohne dass entlang derselben Trassen erneut gegraben werden müsste.

Die Anforderungen des Stadt­informations­systems und der kommunalen Kommunikation wurden daher während der Tiefbauarbeiten berücksichtigt.

Die Vorbereitungen umfassten:

  • Leerrohre für Glasfaserkabel.
  • Streckenquerungen.
  • Unterirdische Zugangsschächte.
  • Anschlusspunkte.
  • Oberirdische Feldschränke an ausgewählten Standorten.

Diese Arbeiten schufen physische Trassen, die das entstehende Netz unterstützen und eine spätere Erweiterung ermöglichen konnten.

9. Das kommunen­übergreifende Glasfaser-Backbone

Die vorbereiteten Trassen ermöglichten es, Kommunen und Einrichtungen an verschiedenen Standorten über Glasfaserverbindungen zu verbinden.

Meine direkte Arbeit umfasste sowohl das Backbone als auch die lokale Infrastruktur, die erforderlich war, um Server und Benutzer daran anzuschließen:

  • Installation von Glasfaserkabeln.
  • Fusions­spleißen.
  • Glasfaserabschluss.
  • Prüfung der Verbindungen.
  • Medienkonverter.
  • Nortel-Switches und -Hubs.
  • NetWare-basierte lokale Netzverteilung.
  • Kupfer-Netzwerkverkabelung.
  • Kabelführungssysteme.
  • Gebäudeinterne Netze.
  • Serveranschlüsse.
  • Clientanschlüsse.

Diese Infrastruktur stellte die Kommunikationsverbindungen bereit, die geografisch getrennte Einrichtungen für den Zugriff auf gemeinsame Informations­systeme benötigten.

Das Glasfaser-Backbone verband die Server-, Daten-, Anwendungs- und Benutzerebenen des entstehenden Stadt­informations­systems.

10. Glasfaser­infrastruktur für die Kommunikation und Signaltechnik der ESTRAM

Die ESTRAM benötigte außerdem Glasfaserverbindungen für ihre betriebliche Kommunikation und ihre Signalsysteme.

Die während der Tiefbauarbeiten vorbereiteten physischen Trassen und Leerrohre konnten diese Anforderung aufnehmen. Für die ESTRAM wurden separate Glasfaserkabel installiert, und die betreffenden Fasern wurden der eigenen Nutzung und Kontrolle der ESTRAM unterstellt.

Der gemeinsame physische Korridor unterstützte daher zwei unterschiedliche Anforderungen:

  • Kommunale Datenkommunikation für das Stadt­informations­system.
  • Betriebliche Kommunikation und Signaltechnik der ESTRAM.

Die Systeme profitierten von derselben Tiefbauinfrastruktur, während die Verantwortung für Nutzung und Verwaltung ihrer Fasern getrennt blieb.

Dies war Teil eines koordinierten Ansatzes, die Stadtinfrastruktur für mehrere betriebliche Systeme zu planen.

11. Management­informations­system

Mit der Entwicklung der Server-, Daten- und Kommunikationsinfrastruktur erweiterte sich die Arbeit auf die betrieblichen Abläufe der kommunalen Fachabteilungen.

Wir untersuchten die Informationen und Geschäftsregeln zu Bürgern, Steuerpflichtigen, Liegenschaften, Veranlagungen, Zahlungseingängen, Vorgängen, Datumsangaben, Sätzen und Rechtsvorschriften.

Eine erhebliche Herausforderung war, dass sich die kommunalen Geschäftsregeln im Lauf der Zeit änderten. Änderungen von Gesetzen, Verordnungen und amtlichen Bekanntmachungen konnten Sätze, Berechnungsmethoden, Gültigkeitsdaten und die Behandlung bestimmter Zeiträume beeinflussen.

Die Anwendungen mussten daher die zum Zeitpunkt eines Vorgangs geltende Regel berücksichtigen.

Tausende möglicher Fälle wurden untersucht in Bezug auf:

  • Gültigkeitszeiträume.
  • Satzänderungen.
  • Gesetzesänderungen.
  • Vorgangsarten.

Die Umsetzung dieser Anforderungen in Softwareverhalten war ein wesentlicher Teil der MIS-Arbeit.

12. Geo­informations­system

Die nächste große Phase bestand darin, kommunale Verwaltungsinformationen mit der physischen Stadt zu verknüpfen.

Die NetCad-basierte GIS-Arbeit konzentrierte sich darauf, Beziehungen zwischen kartierten Objekten und den zugehörigen kommunalen Datensätzen herzustellen.

Die angestrebte Informationskette war:

Stadt → Katasterblock und Flurstück → Gebäude → Nutzungseinheit → Registrierungsdatensatz → Bürger oder Steuerpflichtiger → Kommunale Vorgänge

Ein praktisches Ergebnis war die Möglichkeit, auf der Karte eine Nutzungseinheit oder ein verwandtes geografisches Objekt auszuwählen und die zugehörigen MIS-Informationen abzurufen.

Dies stellte eine direkte Verbindung zwischen räumlichen Informationen und kommunaler Verwaltung her.

13. MIS/GIS-Integration

MIS und GIS wurden als einander ergänzende Informationsebenen betrachtet, die dieselbe Stadt beschreiben.

Das MIS enthielt Personen, Steuerpflichtige, Vorgänge, Veranlagungen und Verwaltungsprozesse. Das GIS bildete Standorte, Flurstücke, Gebäude, Nutzungseinheiten und andere physische Objekte ab.

Die Integrationsarbeit stellte Beziehungen zwischen diesen Ebenen her, sodass eine kartierte Liegenschaft zu den zugehörigen Registrierungs-, Personen- und kommunalen Vorgangsdatensätzen führen konnte.

Dies ermöglichte es Benutzern, die physische Stadt und ihre Verwaltungsinformationen in einer verbundenen Informationsumgebung zu betrachten.

Die entstehende Beziehung war:

Geografischer Standort → Flurstück → Gebäude → Nutzungseinheit → Registrierungsdatensatz → Bürger oder Steuerpflichtiger → Kommunale Vorgänge

14. Vorarbeiten zur Integration von Grundbuch und Kataster

Mit der Entwicklung der MIS/GIS-Beziehungen wurden amtliche Eigentums- und Katasterdaten zu einem weiteren Untersuchungsbereich.

Es bestand die Notwendigkeit, kommunale Informationen zu Personen, Liegenschaften, Flurstücken, Gebäuden und Nutzungseinheiten mit den entsprechenden amtlichen Datensätzen in Beziehung zu setzen.

Mit den zuständigen Einrichtungen wurden Gespräche geführt, um Möglichkeiten der Daten­integration zu prüfen. Vorläufige Gespräche betrafen auch den Informationsaustausch im Rahmen der jeweiligen institutionellen Zuständigkeiten.

Dies blieb vorbereitende Arbeit. Sie untersuchte, wie das Stadt­informations­system mit Informationen anderer öffentlicher Einrichtungen verbunden werden könnte.

15. Ein integrierter Systemansatz

Der Umfang erforderte, dass mehrere technische und betriebliche Ebenen zusammenwirkten:

  • Elektrische und physische Infrastruktur.
  • Verkabelung und Glasfasertechnik.
  • Netzwerkgeräte.
  • Server, Speicher und Datensicherung.
  • Datenbanken und Unternehmens­anwendungen.
  • Altsysteme und Datenmigration.
  • MIS und GIS.
  • Felderhebungsdaten.
  • Rechtsvorschriften und kommunale Geschäftsregeln.
  • Benutzer-Workflows.

Das Projekt entwickelte sich entlang der Beziehungen zwischen diesen Ebenen:

Physische Infrastruktur → Kommunikation → Server und Daten → Unternehmens­anwendungen → MIS/GIS → Kommunale Dienstleistungen

Installationsentscheidungen, Datenstrukturen, Anwendungsanforderungen und Abteilungsprozesse beeinflussten einander. Ihre Koordination war ein zentraler Teil der Arbeit.

16. Meine Rolle und direkte Beiträge

Meine Verantwortung umfasste mehrere Fachgebiete und veränderte sich im Verlauf des Projekts.

Im Bereich System- und Datenanalyse umfasste meine Arbeit:

  • Bewertung der vorhandenen Anwendungen und Datenprobleme.
  • Entwicklung des Ansatzes mit gemeinsamem Register.
  • Festlegung der technischen Anforderungen.
  • Berichterstattung über Hardware- und Personalbedarf.
  • Entwicklung des Erhebungsmodells und der Methode mit optischen Formularen.
  • Unterstützung des stadtweiten Verzeichnisses.
  • Prüfung von Altsystemen.
  • Bereinigung und Abstimmung von Datensätzen.
  • Durchführung der Datenmigration.

Im Bereich Infrastruktur und Kommunikation umfasste meine Arbeit:

  • Installation und Konfiguration von Serversystemen.
  • Konfiguration von Servern und Clients.
  • Entwicklung von Netzwerkkonzepten.
  • Planung von Glasfasertrassen.
  • Arbeit an Leerrohren, Zugangsschächten und Feldschränken.
  • Installation, Spleißen, Terminierung und Prüfung von Glasfasern.
  • Arbeit mit Nortel-Geräten, Medienkonvertern, Switches und Hubs.
  • Unterstützung der NetWare-Infrastruktur.
  • Installation von Kupferverkabelung und gebäudeinternen Netzen.

Im Bereich Anwendungen und Integration umfasste meine Arbeit:

  • Arbeit mit der DB2-Datenumgebung und Java-basierten Unternehmens­anwendungen.
  • Unterstützung der MIS-Entwicklung.
  • Arbeit mit GIS- und NetCad-Anwendungen.
  • Herstellung von Beziehungen zwischen MIS- und GIS-Daten.
  • Übersetzung von Rechtsvorschriften und kommunalen Geschäftsregeln in Softwareanforderungen.
  • Beteiligung an vorbereitenden Arbeiten zur Integration von Grundbuch und Kataster.
  • Testen von Systemen und Unterstützung der Inbetriebnahme vor Ort.

Dies war einer der umfangreichsten System­integrationsaufträge meiner Laufbahn und brachte Hardware, Netzwerke, Kommunikation, Daten, Unternehmens­anwendungen und Geoinformationen in dieselbe kommunale Umgebung.

Entwicklung von 1998 bis 2004

Die Arbeit entwickelte sich über eine Reihe miteinander verbundener Phasen:

  1. 1998 — Erste Bewertung: Untersuchung kommunaler Anwendungen, Altdaten, doppelter Registrierungsdatensätze und von Problemen der Datenintegrität.
  2. Gemeinsame Registrierung und Feldverzeichnis: Entwicklung des Ansatzes mit gemeinsamem Register und Erfassung von Informationen zu Gebäuden, Einheiten, Adressen, Einwohnern und Nutzung mithilfe optischer Formulare.
  3. Daten- und Serverausbau: Installation von Serverkapazität zur Unterstützung wachsender Datenmengen, der Migration von Altdaten und der DB2/Java-Anwendungsumgebung.
  4. 2002 — ESTRAM-Tiefbauarbeiten: Vorbereitung von Leerrohren, Zugangsschächten, Streckenquerungen und Feldschränken für die Glasfaser­infrastruktur.
  5. Integration von Kommunikation und Anwendungen: Entwicklung des kommunen­übergreifenden Backbones, des MIS, des NetCad-basierten GIS und der Beziehungen zwischen Verwaltungs- und Geodatensätzen.
  6. Weitere Integrationsplanung: Vorarbeiten zu Verbindungen mit Informationen von Grundbuch und Kataster.
  7. 2004 — Ende meiner Projektphase: Abschluss meiner Beteiligung an dieser Phase der Arbeit.

Von getrennten Anwendungen zu einer vernetzten Stadt­informations­infrastruktur

Das Ausgangsumfeld bestand aus getrennten kommunalen Anwendungen, fragmentierten Datensätzen, doppelten Registrierungsdatensätzen, begrenztem Informationsaustausch und Verwaltungsdatensätzen mit wenigen direkten Verknüpfungen zur physischen Stadt.

Die Arbeit führte einen Ansatz mit gemeinsamem Register, feldbasierte Verzeichnisdaten, bereinigte und migrierte Datensätze, erweiterte Serverkapazität, Glasfaserverbindungen und Beziehungen zwischen MIS und GIS ein.

Das angestrebte Ergebnis war eine Informationsumgebung, in der Standorte, Liegenschaften, Personen und kommunale Vorgänge über ihre Beziehungen verstanden werden konnten, unterstützt durch gemeinsame Daten und Kommunikationsinfrastruktur.

Technische Bedeutung

Die Bedeutung der Arbeit von 1998 bis 2004 liegt in den Methoden und der Infrastruktur, die in diesem Zeitraum entwickelt wurden.

In einer Zeit, in der der Abgleich anhand nationaler Identitätsdaten und digitale Dienste zwischen Einrichtungen weniger etabliert waren, befasste sich die Arbeit mit mehreren Anforderungen, die für Stadt­informations­systeme weiterhin zentral sind:

  • Abstimmung von Bürgerdatensätzen mit einem Ansatz des gemeinsamen Registers.
  • Erzeugung feldbasierter Einwohner- und Liegenschaftsinformationen.
  • Erhalt von Altdatensätzen bei der Migration.
  • Aufbau gemeinsamer institutioneller Datenressourcen.
  • Erhöhung der Serverkapazität für wachsende Lasten.
  • Verbindung von Kommunen und Einrichtungen über Glasfaser.
  • Planung physischer Trassen mit Blick auf künftigen Kommunikationsbedarf.
  • Verknüpfung kommunaler Verwaltungsdatensätze mit geografischen Objekten.
  • Prüfung eines weitergehenden Informationsaustauschs zwischen öffentlichen Einrichtungen.

Diese Aktivitäten bildeten eine frühe Initiative für ein Stadt­informations­system in Eskişehir, bei der Daten, Server, Kommunikation, Anwendungen, Geoinformationen und Feldinfrastruktur als Teile desselben Systems entwickelt wurden.

2004 — Ende meiner Beteiligung

Meine Beteiligung am Projekt endete 2004, nach sechs Jahren Arbeit an kommunalen Daten, physischer Infrastruktur, Kommunikation, Unternehmens­anwendungen und Geoinformationen.

Die Erfahrung schuf eine praktische Grundlage für die Arbeit über kommunale Daten, physische Stadtinfrastruktur, Unternehmenssysteme und Geoinformationen hinweg. Sie stärkte auch meine Fähigkeit, ein komplexes institutionelles System anhand der Beziehungen zwischen seinen technischen Komponenten und den Leistungen zu bewerten, die es unterstützen musste.