Open Government Data für dieRaumplanung - TU...

Technische Universität Wien

Bachelorarbeit

Open Government Data für dieRaumplanung

OGD in Österreich und deren Potential für die Raumplanung, dargestellt an einer

Webapplikation für RadfahrerInnen.

verfasst von

Johannes Kastenhofer

(Mat.-Nr. 0826640, Stud.-Knz. 033 240)

im Rahmen der Lehrveranstaltung

280.155 Seminar zur Bachelorarbeit

Bachelorstudium Raumplanung und Raumordnung (033 240)

Studienjahr 2011/2012

unter Anleitung von

Ass.-Prof. Dipl.-Ing. Dr. Johann Bröthaler

Fachbereich Finanzwissenschaft und Infrastrukturpolitik

im Department für Raumentwicklung, Infrastruktur- und Umweltplanung

Technische Universität Wien

Wien, 30. Juli 2012

Johannes Kastenhofer Open Government Data

Die Gra�k auf der Titelseite wurde mit Hilfe des Tools auf www.wordle.net erstellt. Der Schriftgrad der

Wörter in der Gra�k entspricht der Häu�gkeit der Verwendung in dieser Arbeit.

Seite ii

www.wordle.net


Inhaltsverzeichnis

1 Einleitung und Problemstellung 1

2 Grundlagen von Open Government Data (OGD) 2

2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Begri�sde�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.2 Die 10 Eigenschaften von OGD . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Strategischen Leitlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 EU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.2 Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Rechtliche Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 EU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 OGD-Daten in Österreich und deren Relevanz für die Raumplanung 9

3.1 OGD-Plattformen in Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Klassi�zierung und Charakterisierung der Datenbestände . . . . . . . . . . . 10

3.3 Schnittstellen und Formate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Qualität von Datenangeboten nach Tim Berners-Lee . . . . . . . . . . 13

3.3.2 Dateiformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.3 Anwendungsschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Lizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Beispiele anderer �freier� Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Relevanz für die Raumplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6.1 Welche Daten sind relevant? . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6.2 Wer ist �die Raumplanung�? . . . . . . . . . . . . . . . . . . . . . . . . 21

3.6.3 RaumplanerInnen in der ö�entlichen Verwaltung . . . . . . . . . . . . 22

3.6.4 RaumplanerInnen in der Wirtschaft . . . . . . . . . . . . . . . . . . . 24

Seite iii


3.6.5 RaumplanerInnen in Verbänden, Interessensvertretungen und NGOs . 25

3.6.6 RaumplanerInnen in der Wissenschaft . . . . . . . . . . . . . . . . . . 25

3.6.7 Welche Daten sind noch wünschenswert? . . . . . . . . . . . . . . . . 25

4 Nutzung und Verknüpfung der Daten: Der Radfahrbegleiter - Ein Beispielprojekt 27

4.1 Der Radfahrbegleiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Datengrundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Hintergrundkarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Geo-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5 OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5.2 Anpassungen im OpenLayer-Quellcode . . . . . . . . . . . . . . . . . . 32

4.5.3 Proxy für WFS-Zugri�e . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6.1 Benutzerober�äche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6.2 Verzeichnisstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.6.3 Funktionsweise des Radfahrbegleiters: Die Datei map.js . . . . . . . . 37

5 Zusammenfassung und Schlussfolgerungen 41

6 Verzeichnisse 43

6.1 Quellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3 Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Anhang 49

7.1 Datenanalyse der österreichischen OGD-Portale . . . . . . . . . . . . . . . . . 49

iv


1 Einleitung und Problemstellung

Open Government Data (OGD), also die Ö�nung und Freigabe von Regierungsdaten im

Internet in maschinenlesbarer Form, ist ein Phänomen der letzten drei Jahre. Was ist das

besondere an diesen Daten? Gibt es diese Daten auch in Österreich? Und was hat die Raum-

planung davon? Die vorliegende Arbeit greift das Thema OGD auf und gibt Antwort auf

diese Fragen.

Ziel der Arbeit ist es zum einen den Entwicklungsstand von Open Government Data in

Österreich darzustellen. Zum anderen soll die Frage beantwortet werden, welchen Nutzen

die Raumplanung von OGD ziehen kann. Es wird eine Beispielapplikation mit den Daten

der OGD-Plattform der Stadt Wien entworfen und implementiert, um abschlieÿend eine

mögliche Anwendung darzustellen.

Nach dieser Einleitung folgt das zweite Kapitel, in dem der Begri� Open Government Data

de�niert wird. Die 10 Eigenschaften o�ener Verwaltungsdaten werden beschrieben. Danach

wird der Frage nachgegangen, ob es strategische Leitlinien bezüglich OGD seitens der EU

und in Österreich gibt. Die dafür relevanten Gesetzestext werden erläutert.

Das dritte Kapitel beginnt mit einer Beschreibung der derzeit in Österreich vorhandenen

OGD-Plattformen von Bund, Länder und Gemeinden. Es werden die vorhandenen Daten

analysiert und die verwendeten Dateiformate und Lizenzen besprochen. Danach folgen Bei-

spiele anderer �freier� Daten, die nicht zu OGD gezählt werden können. Das Kapitel schlieÿt

mit der Darstellung der Relevanz von OGD für die Raumplanung.

Kapitel vier beschreibt eine Beispielanwendung, den �Radfahrbegleiter�. Mit seiner Hilfe

kann der/die RadfahrerIn Fragen beantworten wie: �Wo ist der nächste Trinkbrunnen? Wo

gibt es Radwege?�. Der Radfahrbegleiter verbindet die Daten der OGD-Plattform der Stadt

Wien mit den ebenfalls freien Straÿenkarten von openstreetmap.org. Im Rahmen dieser Ba-

chelorarbeit wurde diese Anwendung ausprogrammiert.

Das fünfte Kapitel fasst die Erkenntnisse aus der Arbeit zusammen.

Seite 1

openstreetmap.org


2 Grundlagen von Open Government

Data (OGD)

In diesem Kapitel wird der Begri� Open Governmet Data erklärt. Es wird die Frage geklärt,

ob es in der EU und in Österreich strategische Leitlinien zu OGD gibt. Abschlieÿend wird

die Rechtsgrundlage von OGD besprochen.

2.1 Allgemeines

2.1.1 Begri�sde�nition

Im Open Government Weiÿbuch der Semantic Web Company wird Open Government Data

folgendermaÿen de�niert:

�O�ene Verwaltungsdaten sind Datenbestände, die von der ö�entlichen Verwal-

tung im Bereich der Hoheitsverwaltung und privatwirtschaftlichen Verwaltung

im Interesse der Allgemeinheit erhoben werden und in einem anerkannt o�e-

nen, maschinenlesbaren Format zur beliebigen, digitalen Weiterverarbeitung zur

Verfügung gestellt werden.� (Kaltenböck/Thurner, 2011, S. 16)

OGD sollen also möglichst gut weiter maschinell verarbeitet werden können. Bisherige Da-

tenangebote der ö�entlichen Verwaltung sind dagegen meist für den/die EndanwenderIn

konzipiert, d.h. schlecht maschinen- aber gut anwenderlesbar. Auÿerdem sind die Daten

dieser Angebote meist restriktiv lizenziert.

2.1.2 Die 10 Eigenschaften von OGD

An Open Governemnt Data lassen sich 10 Kerneigenschaften festmachen (vgl. Kalten-

böck/Thurner, 2011, S. 15-16) zit. nach (Lucke et. al 2010, S. 2-3):

Seite 2


1. Vollständigkeit

2. Primärquelle

3. Zeitliche Nähe

4. Leichter Zugang

5. Maschinenlesbarkeit

6. Nicht diskriminierend

7. Verwendung o�ener Standards

8. Liberale Lizenzierung

9. Dauerhaftigkeit

10. Keine oder nicht diskriminierende Nutzungskosten

Es sollen alle ö�entlichen Daten der Verwaltung vollständig zur Verfügung gestellt werden.

Dabei ist der Datenschutz zu beachten. Auÿerdem sind sicherheitskritische Daten von der

Verö�entlichung auszuschlieÿen. Daten sollen in ihrer ursprünglichen Form (Primärquelle)

und nicht aggregiert, möglichst zeitnah, auf leicht zugänglichen Websites angeboten werden.

Es sollen o�ene Dateiformate gewählt werden. Das sind Formate, die frei verwendet wer-

den können und deren Spezi�kation frei zur Verfügung steht. Die Daten sollen nicht nur

für den/die EndnutzerIn formatiert zur Verfügung gestellt werden. Stattdessen soll ein �ma-

schinenlesbares� Format gewählt werden, also ein Format, das leicht von Rechnern gelesen

und in Anwendungen verarbeitet werden kann. Der Zugang zu den Daten soll allen gleich

möglich sein (nicht diskriminierend). Die Lizenzierung soll möglichst zu keiner Beschrän-

kung der Nutzbarkeit der Daten führen. Insbesondere sollte auch die kommerzielle Nutzung

erlaubt sein. Die Daten sollen möglichst dauerhaft unter der gleichen Adresse zur Verfügung

stehen. Werden Nutzungskosten verlangt, sollen sie für alle gleich hoch sein.

2.2 Strategischen Leitlinien

2.2.1 EU

Auf EU-Ebene gibt es zur Zeit keine gemeinsame Strategie zur Forcierung von Open Gover-

nment Data. Es wurden aber eine Reihe von Initiativen gesetzt und Strategien beschlossen,

die das Themenfeld OGD berühren:

Kapitel 2. Grundlagen von Open Government Data (OGD) Seite 3


Grünbuch über Informationen des ö�entlichen Sektors in der Informationsgesellschaft

Das �Grünbuch über Informationen des ö�entlichen Sektors in der Informationsgesellschaft�

wurde im Jahr 1998 von der Europäischen Kommission verö�entlicht. In diesem wird die Be-

deutung der Zugänglichkeit der Daten des ö�entlichen Sektors für die Wirtschaft, die Bürge-

rInnen und auch für die Verwaltung intern dargestellt. Durch den Einsatz von Informations-

und Kommunikationstechnik (IKT) soll die E�zienz der Verwaltung gesteigert und �elektro-

nische Verwaltungsdienstleistungen� aufgebaut werden (vgl. Europäische Kommission, 1998,

S. 9). Der Begri� �Open Government Data� �ndet keine Verwendung. Es geht im Grünbuch

vielmehr um fertige Dienstleistungen mit aufbereiteten Daten, die die Verwaltung zur Ver-

fügung stellen soll. Es wird aber bereits der Zugang zu Primärdaten in den Raum gestellt:

�Inwieweit sollten die Bürger nicht nur zu den fertig aufbereiteten Daten Zugang

haben, sondern auch zu Rohdaten und Daten, die noch nicht fertig aufbereitet

sind?� (Europäische Kommission, 1998, S. 14, Punkt 88)

IKT-Strategien

Ab dem Jahr 2000 beschloss die EU-Kommission Strategien zum Thema IKT in der Ver-

waltung, Gesellschaft und Wirtschaft. Zu jeder Strategie wurde ein Aktionsplan erstellt, der

konkrete Maÿnahmen enthält, um die strategischen Ziele zu erreichen. Nach dem Auslaufen

eines Programmes wurde jeweils eine Nachfolgestrategie beschlossen:

� Von 2000-2002: e-Europe 2002

� Von 2002-2005: e-Europe 2005

� Von 2005-2010: i2010-Initiative

� Von 2010-2020: Eine Digitale Agenda für Europa

In den Strategien wird OGD nicht direkt erwähnt.

Eine Digitale Agenda für Europa

In einer Mitteilung aus dem Jahr 2010 formuliert die Europäischen Kommission eine Strate-

gie im Bezug auf die IKT bis 2020 - Die Digitale Agenda für Europa (vgl. Europäische Kom-

mission, 2010, S. 3). Darin werden die IKT als ein wichtiges Element beschrieben, um den

Problemen Europas Herr zu werden (z. B. Überalterung, Klimawandel, erhöhte Gesundheits-

kosten...) (ebd. S. 7). Gegliedert in Aktionsbereichen wie �Interoperabilität� oder �Vertrauen



und Sicherheit� werden Schlüsselaktionen festgeschrieben. Im Aktionsbereich �IKT-gestützte

Vorteile für die Gesellschaft� be�ndet sich der Unterpunkt �Elektronischen Behördendienste

(eGovernment)�. Open Government Data, also die maschinenlesbare Verö�entlichung von

Primärdaten, wird nicht erwähnt. Lediglich für den Umweltbereich wird festgehalten, dass

die �Richtlinie 2003/4/EG über den Zugang der Ö�entlichkeit zu Umweltinformationen�

überprüft werden soll. Auÿerdem sollen grenzübergreifende �eUmweltdienste� forciert wer-

den, also die grenzüberschreitend kompatible Aufzeichnung und Darstellung von Umweltin-

formationen auf elektronischem Weg (ebd. S. 37f).

2.2.2 Österreich

Es gibt einige Initiativen, die OGD in Österreich vorantreiben wollen:

Plattform Digitales Österreich

Die Plattform �Digitales Österreich� ist die Website der Bundesregierung zum Thema E-Gov-

ernment. Hier kann die Bürgerkarte beantragt und Behördengänge online erledigt werden.

Unter �Verwaltung� �ndet man auch einen Eintrag zu OGD (vgl. Bundeskanzleramt Öster-

reich, 2007). Dort �nden sich Links zu den OGD-Plattform in Österreichs sowie Verweise

auf Veranstaltungen zum Thema.

E-Government Bund - Länder - Gemeinden

Das Portal reference.e-government.gv.at dient als interne Arbeitsplattform zum Thema E-Gov-

ernment. Es handelt sich bei der Plattform um eine Kooperation des Bundes, der Länder, des

Städtebundes und des Gemeindebundes. In Ausschüssen, an denen Mitglieder der Koopera-

tionspartner teilnehmen, werden Konventionen sowie Whitepapers (Diskussionsgrundlagen)

für E-Government-Anwendungen erarbeitet und auf der Website verö�entlicht. So erarbeite-

te Konventionen können bei Einstimmigkeit zum Standard erhoben werden (vgl. Grandits,

2006, S. 6, 9).

Im Whitepaper �Rahmenbedingungen für Open Government Data Plattformen� werden die

URL-Struktur von Portalen, Dateiformate, die zu bevorzugen sind sowie die zu verwendende

Lizenz festgelegt (vgl. Eibl/Höchtl et al., 2011). In einem weiteren Whitepaper wird die

Bezeichnung und die Struktur der Metadaten beschrieben (vgl. Habernig/Kaltenböck, 2012).


reference.e-government.gv.at


OGD Austria

OGD Austria ist eine Kooperation des Bundeskanzleramts, der Städte Wien, Linz, Salzburg

und Graz sowie des Vereins �Open Knowlegde Forum Österreich�. Ziel ist es, die OGD in

Österreich zu fördern, Verwaltung, Politik, Forschung und Wirtschaft zusammen zu bringen

und die jeweiligen Aktivitäten abzustimmen. Bisherige Initiativen reichen von Konferenzen,

einer Zeitschrift (Open Government Data Digest Österreich), einem Katalog o�ener Daten

(o�ener.datenkatalog.at) bis hin zu OGD-Stammtischen.

Die Kerngruppe des Vereins �Open Knowlede Forum Österreich� besteht aus Vertretern von

Joanneum Research, der Universität Wien, dem KDZ (Zentrum für Verwaltungsforschung),

der Donau-Universität Krems, Salzburg Research und der Semantic Web Company (vgl.

Verein Open Knowledge Forum Österreich, 2010).

Verein �Open3�

Open 3 versteht sich als gemeinnütziger Verein zur Förderung von openSociety, openGover-

nment und openData in Österreich (vgl. open 3, 2012). Auf der Website des Vereins �nden

sich viele Beiträge und Links zum Thema OGD.

2.3 Rechtliche Grundlagen

2.3.1 EU

Es gibt auf EU-Ebene keine Rechtstexte, die OGD explizit erwähnen. Es gibt aber zwei

Richtlinien, die das Thema �Open Government Data� berühren:

EU-Richtlinie 2003/98/EG

Im Jahr 2003 hat das europäische Parlament und der Rat der Europäischen Union die �Richt-

linie über die Weiterverarbeitung von Informationen des ö�entlichen Sektors� verabschiedet.

Die Richtlinie wird oft auch PSI-Richtlinie (nach �Public Sector Information�) genannt. Sie

beschreibt, wie und unter welchen Bedingungen Daten des ö�entlichen Sektors weitergegeben

werden sollen. So wird beispielsweise eine Nichtdiskriminierung bei der Datenauskunft vor-

geschrieben. Auÿerdem sollen Daten soweit wie möglich in elektronischer Form übermittelt

werden (vgl. Europäisches Parlament und Rat der Europ. Union b, 2003).


offener.datenkatalog.at


Das Informationsweiterverwendungsgesetz setzt die Richtlinie im österreichischen Recht um

(siehe Abschnitt 2.3.2).

EU-Richtlinie 2003/4/EG

Die �Richtlinie über den Zugang der Ö�entlichkeit zu Umweltinformation und zur Aufhebung

der Richtlinie 90/313/EWG� ersetzt die Richtlinie aus dem Jahr 1990 zu diesem Thema. Sie

hat das Ziel, die Transparenz der Daten über die Umweltsituation zu erhöhen und damit

zum Umweltschutz beizutragen. Dabei sollen sich die Behörden bemühen, die Daten in

elektronischer Form zur Verfügung stellen zu können (vgl. Europäisches Parlament und Rat

der Europ. Union a, 2003).

2.3.2 Österreich

Auch in Österreich �ndet man keine direkte Erwähnung von OGD in Gesetzestexten. Im

Bezug die Verö�entlichung von Verwaltungsdaten sind folgende Gesetze interessant:

Auskunftsp�ichtgesetz

Das Auskunftsp�ichtgesetz sieht eine P�icht der Verwaltung vor, Auskünfte bei schriftlichem

Antrag zu erteilen, soweit dies nicht einen unverhältnismäÿigen Aufwand darstellt und keine

anderen gesetzlichen Regelungen dagegensprechen (vgl. Auskunftsp�ichtgesetz, 1987). Auch

auf Landesebene gibt es derartige Gesetze.

Informationsweiterverwendungsgesetz

Das Informationsweiterverwendungsgesetz setzt die EU-Richtlinie 2003/98/EG in nationales

Recht um (vgl. IWG, 2005). Damit wird die Weitergabe von Daten des ö�entlichen Sektors

EU-weit vereinheitlicht. Siehe auch 2.3.1 auf Seite 6.

Bundesstatistikgesetz

Das Bundesstatistikgesetz regelt die Aufgaben, Ziele sowie den Aufbau und die Organisation

der Bundesstatistik. Die von der Bundesstatistik zu erfassenden Daten werden per Verord-

nung erlassen. Neben dem Bundesstatistikgesetz gibt es eine Reihe weiterer Statistikgesetze



des Bundes sowie der Länder. Die Verö�entlichung der Statistiken muss weder unentgeltlich

erfolgen noch muss eine �liberale� Lizenzierung oder ein maschinenlesbares Format gewählt

werden (vgl. Bundesstatistikgesetz, 2009). Die Daten der Bundesstatistik sind damit nicht

zu den OGD zu zählen.

Umweltinformationsgesetz

Das Umweltinformationsgesetz regelt die Informationsp�icht der Verwaltung bezüglich Um-

weltinformationen wie Luftverschmutzung, Lärm oder Wasserqualität (vgl. UIG, 2005).

Das Gesetz wurde 2005 novelliert um der EU-Richtlinie 2003/4/EG zu entsprechen (Siehe

auch 2.3.1 auf Seite 7). Die Umweltdaten müssen nicht in leicht maschinenlesbaren Formaten

verö�entlicht werden und entsprechen damit nicht zwingend den Anforderungen von OGD.

Für die Nutzung von IKT in der Verwaltung ist folgendes Gesetz von Interesse:

E-Government-Gesetz

Das E-Government-Gesetz behandelt die österreichische Bürgerkarte und die Identi�kation

und Authenti�zierung mit dieser auf elektronischem Weg. Es wird auch auf die Verwendung

der Bürgerkartenfunktion im privaten Bereich und auf die Besonderheiten elektronischer

Aktenführung eingegangen (vgl. E-GovG, 2010).



3 OGD-Daten in Österreich und deren

Relevanz für die Raumplanung

Dieses Kapitel beschäftigt sich mit OGD in Österreich. Zuerst werden die vorhandenen

OGD-Plattformen vorgestellt sowie die dort abrufbaren Daten klassi�ziert. Danach wer-

den die Datenqualität auf Maschinenlesbarkeit geprüft und die verwendeten Dateiformate

und Schnittstellen beschrieben. Die Art der Lizenzierung wird besprochen. Andere �freie�

Datenquellen werden vorgestellt, die nicht zu OGD zu zählen sind. Schlieÿlich wird die Re-

levanz der derzeit verfügbaren und zukünftig zu erwartenden Daten für die Raumplanung

analysiert.

3.1 OGD-Plattformen in Österreich

Die erste OGD-Plattform in Österreich hat die Stadt Wien eingerichtet und im Mai 2011

online gestellt. Die Stadt Linz startete im Oktober 2011 ihr Portal für o�ene Verwaltungs-

daten. Es folgten das Land Tirol und der Bund im April 2012 sowie Vorarlberg im Mai 2012

(Tabelle 3.1 auf Seite 10). Konkrete Überlegungen für eine OGD-Plattform gibt es in der

Stadt Salzburg (vgl. Harm, 2011).

Seite 9


Tabelle 3.1: Bestehende Open-Data-Plattformen

Bezeichnung URL Startdatum

Bund data.gv.at April 2012

Land Tirol data.tirol.gv.at April 2012

Land Vorarlberg data.tirol.gv.at Mai 2012

Linz data.linz.gv.at Oktober 2011

Wien data.wien.gv.at Mai 2011

Quelle: Eigene Recherche und Darstellung, 2012

Die Stadt Linz hat sich bei der freien Zugänglichkeit nicht nur auf Verwaltungsdaten be-

schränkt: Im April 2011 fand die Auftaktveranstaltung zur Vorstellung der �Open Commons

Region Linz� statt (vgl. Pawel, 2011). Wörtlich übersetzt bedeutet �Open Commons� �o�enes

Allgemeingut�. Die Stadt Linz versteht darunter nicht nur die Ö�nung der Regierungsda-

ten, sondern auch die Förderung o�ener Standards und o�ener Software. Sie unterstützt

beispielsweise den Einsatz von Open O�ce in Schulen. Zugleich wurde eine Vielzahl freier

Hotspots eingerichtet. Jede/r BürgerIn erhält auf Wunsch einen eigenen Webspace sowie ein

E-Mail-Konto. Die Initiative soll einerseits dem Gemeinwohl, andererseits der Förderung der

Wirtschaft dienen. Nebenbei sollen Kosten eingespart werden (vgl. Stadt Linz, 2012).

3.2 Klassi�zierung und Charakterisierung der

Datenbestände

Im Rahmen der vorliegenden Arbeit wurde eine Klassi�zierung und Charakterisierung des

Datenangebotes der OGD-Plattformen Österreichs durchgeführt, um in einem weiteren Schritt

die Relevanz der Daten für die Raumplanung bestimmen zu können. Abbildung 3.1 auf Sei-

te 11 zeigt einen Auszug aus der detaillierten Analyse. Die Datenbestände wurden in thema-

tische Gruppen eingeteilt. Beispielsweise wurden die Grupppen �Wirtschaft�, �Soziales� und

�Umwelt� gebildet. Neben der Gruppeneinteilung charakterisieren den Datenbestand fünf

Attribute:

Kapitel 3. OGD-Daten in Österreich und deren Relevanz für die Raumplanung Seite 10

data.gv.at

data.tirol.gv.at

data.tirol.gv.at

data.linz.gv.at

data.wien.gv.at


I. Die Räumliche Au�ösung der Daten. Beispielsweise liegt die Wirtschafts- und Sozi-

alstatistik im OGD-Portal Vorarlberg für das gesamte Land sowie für die einzelnen

Gemeinden vor (Abbildung 3.1).

II. Der Zeitliche Bezug gibt den Abstand der Datenerfassung in Zeitreihen an. Liegt

keine Zeitreihe vor, so wird angegeben, ob es sich um aktuelle Daten oder Daten mit

Datumsangabe handelt.

III. Die Datenart gibt an, ob es sich um Pixel- Vektor- oder alphanumerische Daten han-

delt.

IV. Die Zugri�sart gibt Auskunft, ob die Daten als Datei, via WebService (beispielsweise

WMS) oder über eine Webplattform mit Formulareingabe zur Verfügung stehen.

V. Das Attribut �Datentyp� bezeichnet das Dateiformat oder die Dateiformate, die ange-

boten werden.

Im Anhang (Kapitel 7 auf Seite 49) �ndet sich die vollständige Analyse. Sie gibt einen

detailierten Überblick über die derzeit in Österreich verfügbaren o�enen Regierungsdaten.

Die Übersicht soll ein schnelles Au�nden der gewünschten Daten sowie eine Beurteilung für

die Brauchbarkeit im jeweiligen Anwendungsfall ermöglichen.

Abbildung 3.1: Auszug aus der umfassenden Datenanalyse der OGD-Plattformen Österreichs

Quelle: Eigene Konzeption und Darstellung, 2012



Abbildung 3.2 zeigt die Gruppeneinteilung der Datensätze in der Analyse. Grün dargestellt

sind jene Gruppen, bei denen im jeweiligen Portal Daten vorhanden sind. Es fällt sofort

auf, dass die Portale von Wien und Linz am weitesten fortgeschritten sind. Bei Ihnen fehlen

jeweils nur vier Gruppen. Es folgen die Portale von Vorarlberg und jenes des Bundes. Die

Website des Bundes verlinkt auch auf die Daten der OGD-Plattformen der Länder und

Gemeinden. In der Analyse werden diese Daten nicht dem Bund zugerechnet. Tirol stellt

zurzeit nur Daten aus den Bereichen Verkehr und Umwelt bereit.

Abschnitt 3.3.1 auf Seite 13 behandelt die Maschinenlesbarkeit von OGD und bewertet die

jeweiligen OGD-Plattformen in dieser Hinsicht.

Abbildung 3.2: Vorhandene Datensatzgruppen auf den österreichischen OGD-Portalen

Quelle: Eigene Darstellung und Erhebung, 2012

3.3 Schnittstellen und Formate

Die Auswahl des Dateiformates und damit die Strukturierung der Daten spielt eine entschei-

dende Rolle für die Verwertbarkeit der Informationen. Während sich für menschliche Leser-

Innen Formate wie PDF oder das Excelformat XLS anbieten, sind diese zur automatischen,

maschinellen Verarbeitung nicht geeignet. Zu beachten ist auch, ob ein Format proprietär



oder frei verfügbar ist. Proprietär bedeutet, dass eine Firma oder Institution Schutzrechte

für dieses Format besitzt oder die Formatspezi�kation nicht vollständig o�enlegt. Eine freie

Verwendbarkeit auch in der Zukunft kann dabei nicht gewährleistet werden.

3.3.1 Qualität von Datenangeboten nach Tim Berners-Lee

Um die Qualität eines OGD-Angebotes zu bewerten, hat Tim Berners-Lee ein 5-Stern-Modell

entwickelt (Tabelle 3.2 auf Seite 14). Tim Berners-Lee gilt als der Er�nder des WWW und

wirkt bei der Konzeption und Gestaltung des OGD-Portals data.gov.uk mit (vgl. Kalten-

böck/Thurner, 2011, S. 24).

Einen Stern bekommt ein Datenangebot, wenn die Dateien mit einer o�enen Lizenz zur

Verfügung gestellt werden (z. B. Creative Commons). Zwei Sterne werden für Daten in

strukturierter Form vergeben, drei Sterne wenn das verwendete Format nicht proprietär

ist. Den vierten Stern gibt es für eine eindeutige, sich nicht ändernde URL. Für den fünften

Stern sind das Verlinken der Daten mit den Methoden des Semantic Webs erforderlich. Die

Grundidee des Semantic Webs ist es, nicht nur die Daten als solche zu speichern, sondern

auch Informationen über deren semantische Bedeutung. So wird beispielsweise nicht nur eine

Telefonnummer als solche gespeichert, sondern auch die Information, dass es sich um eine

Telefonnummer handelt. Dies erfolgt in maschinenlesbarer Form - zum Beispiel mit dem

Resource Description Framworks (RDF) (vgl. W3C, 2012) - und ermöglicht die Einordnung

der Daten in den Kontext und deren Verknüpfung. Diese Daten werden dann �Linked Data�

genannt. Auf den österreichischen Plattformen sind solcherart verlinkte Dateien noch nicht

vorhanden.

Tabelle 3.3 auf Seite 15 zeigt eine Bewertung der österreichischen OGD-Plattformen nach

dem Modell von Tim Berners-Lee. Man sieht sofort, dass die Plattformen von Wien und Linz

die beste Datenqualität hinsichtlich Maschinenlesbarkeit aufweisen. Bei den Plattformen des

Bundes und dem Land Vorarlberg �nden sich Datensätze, die sehr schlecht maschinenlesbar

sind und streng genommen nicht zu den OGD gehören. Man muss aber bedenken, dass

diese Plattformen noch im Aufbau sind. Es ist zu erwarten, dass die Datenqualität in den

kommenden Quartalen zunehmen wird.

3.3.2 Dateiformate

Folgende Dateiformate werden von den OGD-Plattformen in Österreich verwendet:


data.gov.uk


Tabelle 3.2: Qualität von Linked Data. 5-Stern-Modell von Tim Berners-Lee.

Kein Stern Daten im Web (Format egal), ohne o�ene Lizenz

Ein Stern F Daten im Web (Format egal), mit o�ener Lizenz

Zwei Sterne FF Daten in strukturiertem Format (z. B. Excel)

Drei Sterne FFF Daten in strukturiertem, nicht proprietärem Format

(z. B. CSV statt Excel)

Vier Sterne FFFF Verwendung von eindeutigen URLs, sodass Datensätze

verlinkt werden können

Fünf Sterne FFFFF Verlinkung der eigenen Daten mit anderen Daten, um

Kontext herzustellen

Quelle: (Berners-Lee, 2006) in der deutschen Übersetzung von(Kaltenböck/Thurner, 2011, S. 250f), Eigene Darstellung, 2012

Dateiformate für Bilder und Gra�ken

PNG (Portable Network Graphics) speichert Pixelgra�ken verlustfrei und kann Transparen-

zen darstellen. Es eignet sich für Gra�ken mit wenigen Farben und harten Farbüber-

gängen (vgl. Wikipedia c, 2012).

JPEG (Joint Photographic Experts Group) ist ein Format zur verlustbehafteten Speiche-

rung von Pixelgra�ken. Es geeignet sich besonders, Bilder mit vielen Farben und �ie-

ÿenden Übergängen darzustellen wie es bei Fotos der Fall ist. Transparente Bereiche

können nicht gespeichert werden (vgl. Wikipedia b, 2012).

TIFF (Tagged Image File Format) ist ein Format zur verlustfreien Speicherung von Pixel-

gra�ken. Es bietet die Möglichkeit Transparenzen darzustellen und mehrere Ebenen

zu speichern (vgl. Wikipedia a, 2012).

Textdateien

TXT Dateien sind einfache Dateien, die Text enthalten. Eine bestimmte Formatierung oder

Gliederung des Textes ist nicht vorgeschrieben.



Tabelle 3.3: Bewertung der Daten der österreichischen Open-Data-Plattformen mit dem

5-Stern-Modell

Bezeichnung URL Datenqualität

Bund (nur eigene Daten) data.gv.at 0-3 Sterne1

Land Tirol data.tirol.gv.at 2-3 Sterne

Land Vorarlberg data.tirol.gv.at 0-3 Sterne

Wien data.wien.gv.at 4 Sterne

Linz data.linz.gv.at 3 bis 4 Sterne

1Es wurden nur die Daten des Bundes bewertet, nicht aber die der Länder und Gemeinden aufdie Bundesplattform verweist.

Quelle: Eigene Recherche und Bewertung, 2012

Dateiformate für tabellarische und strukturierte Daten

CSV (Comma Seperated Values) ist ein Format in dem Datentabellen gespeichert werden

können. Die einzelnen Datenfelder werden durch Kommata oder wahlweise auch durch

ein anderes Zeichen getrennt. Für die CSV spricht der einfache Dateiaufbau. CSV-

Dateien lassen sich in alle gängigen Tabellenkalkulationen importieren. Ein Nachteil

ist, dass es zu CSV keinen allgemeinen Standard gibt. Das Trennzeichen, die Zei-

chencodierung und andere Eigenschaften können daher von Datei zu Datei variieren

und erschweren eine automatische maschinengestützte Verarbeitung (vgl. Wikipedia

d, 2012).

XML (Extensible Markup Language) ist eine Auszeichnungssprache, in der Elemente, in der

gleichen Weise wie in HTML mit spitzen Klammern (< >) abgegrenzt und bezeich-

net werden. XML ist eine sogenannte Metasprache. Sie de�niert den grundsätzlichen

Aufbau einer XML-Datei. Durch weitere inhaltliche und strukturelle Einschränkun-

gen, sogenannte Schemata, können dann konkrete anwendungsspezi�sche Sprachen

de�niert werden. Beispiele für solche XML-Sprachen sind SVG zur Darstellung von

Vektorgra�ken und auch beiden Formate GML und KML die im nächsten Abschnitt

behandelt werden. Eigene Schemata können de�niert werden um XML für individuelle

Anwendungen anzupassen. XML ist daher vielseitig einsetzbar und dadurch im Inter-

net omnipräsent. Durch den klar de�nierten Aufbau lassen sich XML-Dateien sehr gut


data.gv.at

data.tirol.gv.at

data.tirol.gv.at

data.wien.gv.at

data.linz.gv.at


maschinell verarbeiten (parsen). Die Daten können leicht mit Metadaten angereichert

werden (vgl. Wikipedia e, 2012).

PDF (Portable Document Format) ist ein Dateiformat für elektronische Dokumente. Es ist

darauf ausgelegt, Dokumente unabhängig vom ursprünglichen Anwendungsprogramm,

vom Betriebssystem und von der Hardwareplattform originalgetreu wiederzugeben und

dabei möglichst wenig Speicherplatz zu belegen. Es können beliebige Texte, Gra�ken

und Tabellen und beliebige gra�sche Elemente wiedergegeben werden. Für das ma-

schinelle Auslesen von Daten ist das PDF-Format ungeeignet (vgl. Wikipedia f, 2012).

XLS (Excel Spreadsheet) ist ein Format, das von der Tabellenkalkulation Microsoft Excel

verwendet wird. Heute ist das Standardformat von Excel XLSX, ein Format das auf

XML basiert. Im Internet wird trotzdem häu�g noch das ältere Format XLS verwendet,

um möglichst breite Kompatibilität gewährleisten zu können. XLSX zählt zu den pro-

prietären Formate und sollte daher durch o�ene Alternativen wie ODS ersetzt werden.

Daten einer Tabellenkalkulation sind nur bedingt maschinenlesbar (vgl. Wikipedia g,

2012).

ODS (Open Document Spreadsheet) ist das Standardformat von Open und Libre O�ce.

Es basiert auf XML und wurde von der ISO zum Standard erhoben. Es ist eine o�ene

Alternative zu XLS. Man sollte aber bedenken, dass auch mit diesem Format keine

gute Maschinenlesbarkeit erreicht werden kann, da die Daten in den Tabellenblättern

beliebig angeordnet und mit Text und Metadaten gemischt werden können. Datenan-

gebote sollten nach Möglichkeit auf CSV oder noch besser auf XML-Derivate, die eine

striktere Datenstruktur vorschreiben, umgestellt werden.

Dateiformate zur Speicherung von Geodaten

GML (Geography Markup Language) ist ein XML-Derivat zur Speicherung von raumbezo-

genen Objekten. Es lässt sich sehr gut maschinell verarbeiten. GML wird vom Open

Geospatial Consortium (OGC) gemeinsam mit der ISO festgelegt und entwickelt (vgl.

Wikipedia h, 2012).

JSON (JavaScript Objekt Notation) ist ursprünglich eine Notationsform um JavaScript

Objekte darzustellen. Heute wird das Format im Internet aber zur Speicherung und

zum Austausch von Objekten aller Art verwendet. Grund für die Beliebtheit von JSON

ist die geringe Dateigröÿe von JSON-Dateien. Eine JSON-Datei fällt im Vergleich zu



einer XML-Datei mit denselben Daten sehr viel kleiner aus. Auch JSON lässt sich sehr

leicht maschinell lesen und schreiben.

KML (Keyhole Markup Language) ist eine Sprache zur Beschreibung von Geodaten die auf

XML basiert. Sie wurde von Google für die Programme Google Earth und Google

Maps entwickelt. KML zählt zu den o�enen Formaten und ist ein Standard des OGC

(vgl. Wikipedia i, 2012).

GeoRSS (Geo Real Simple Syndication) ist eine Erweiterung von RSS um Geoobjekte über-

tragen zu können (siehe auch RSS in Abschnitt 3.3.3 auf Seite 18).

ESRI Shape�le (.shp) ist ein proprietäres Dateiformat zur Speicherung von Geodaten, das

von der Firma ESRI entwickelt wurde und sich als Quasi-Standard im Desktop-GIS-

Bereich etabliert hat. Neben dem .shp-File sind mindestens zwei weitere Dateien (.shx,

.dbf) erforderlich um einen gültigen Datensatz zu repräsentieren (vgl. Wikipedia j,

2012).

3.3.3 Anwendungsschnittstellen

Auf einer OGD-Plattform können einerseits einzelne Daten�les mit einer �xen URL zu-

gänglich gemacht werden. Andererseits kann die Plattform Web-Dienste (WebServices) zur

Verfügung stellen. Ein Benutzerprogramm kann bei einem solchen Dienst über eine de�er-

te Schnittstelle Daten abfragen. So kann der Server gezielter Daten zur Verfügung stellen.

Wenn beispielsweise eine Anfrage nur einen Teil der Daten betri�t, müssen auch nur diese

übertragen werden. Es gibt vorgefertigte Softwarebibliotheken, die die Kommunikation mit

demWebService der OGD-Plattform über die Anwendungsschnittstelle übernehmen können.

WMS (Web Map Service) de�niert eine Schnittstelle, die es einem Client ermöglicht von

einem Server einen Kartenausschnitt abzufragen. Der Client schickt dazu eine XML-

Anfrage mit den Koordinaten, der gewünschten Projektion und weiterer Parameter

zum Server. Bei einer korrekten Anfrage zeichnet der Server eine Pixelgra�k die dann

zum Client zurückgeschickt wird. Zur Performancesteigerung können diese Gra�ken

auch serverseitig gecached werden, um nicht bei jeder Anfrage neu erstellt werden zu

müssen. Der Vorteil des WMS liegt darin, dass er mehrere Projektionen und beliebige

Zoomstufen zulassen kann. Mit der Erweiterung �Styled Layer Desciptor� (SLD) kann,

sofern der Server das unterstützt, das Aussehen der zurückgelieferten Gra�k beein�usst



werden. So können z. B. die Farbe und Stärke von Linien vom Client festgelegt werden

(vgl. Open Geospatial Consortium Inc., 2012a, 2007).

WMTS (Web Map Tile Service) de�niert eine Schnittstelle ähnlich der von WMS. Aller-

dings werden hier fertig Kacheln (sog. Tiles) vom Server zur Verfügung gestellt. Diese

liegen in nur einer Projektion und für feste Zoomlevels vor. Das zur Verfügung stellen

von Kacheln wird von allen groÿen Kartendiensten wie GoogleMaps, BingMaps oder

OpenStreetMap angewandt. Der Vorteil ist die höhere Perfomanz, da bei einem Auf-

ruf keine Gra�ken mehr berechnet werden müssen. Der Nachteil ist, dass die Karten

nur in einer Projektion und in den �xen Zoomlevels dargestellt werden kann. Möchte

man Karten über einen WMTS in eine eigene Anwendung einbinden, dann muss man

genau jene Projektion und die jeweiligen Zoomlevels verwenden (vgl. Open Geospatial

Consortium Inc., 2012b).

WFS (Web Feature Service) de�niert eine Schnittstelle, mit der die vorhandenen Geoobjekte

in einem Kartenausschnitt abgefragt werden können. Der Server liefert hier als Antwort

nicht ein fertig gerendertes Bild. Stattdessen werden die Datensätze der Objekte in der

Regel in einer XML- oder JSON-Datei übertragen. Der Client hat nun die Möglichkeit,

die Geoobjekte nach den eigenen Vorstellungen zu verwenden und darzustellen (vgl.

Open Geospatial Consortium Inc., 2012b).

Die Stadtplan API Wien bietet eine Möglichkeit, die auf wien.gv.at/stadtplan verfügbare

Karte in eigene Webseiten einzubinden. Dazu reichen wenige Zeilen JavaScript aus

(vgl. Stadt Wien, 2012).

RSS (Real Simple Syndication) ist ein auf XML basierendes Format zur Verö�entlichung

kurzer Nachrichten und Meldungen. Ein Server kann einen sogenannten RSS-Feed zur

Verfügung stellen, also eine Schnittstelle, die aktuelle Nachrichten abrufbar macht. Ein

Nutzer kann sich dann mit einem Browser-Plugin oder einem externen RSS-Reader die-

sen RSS-Feed abonnieren. Der RSS-Reader fragt regelmäÿig den RSS-Feed des Servers

ab und zeigt dem Nutzer neue Nachrichten an (vgl. Wikipedia k, 2012).

3.4 Lizenzierung

Wie in Abschnitt 2.1.2 auf Seite 2 erwähnt sollen OGD �liberal� lizenziert werden. Die

�Creative Commons Lizenzen� (CC-Lizenzen) werden sehr häu�g für OGD verwendet. Ab-

bildung 3.3 auf Seite 19 zeigt die verschiedenen Abstufungen des Rechtevorbehalts, den die


wien.gv.at/stadtplan


CC-Lizenzen bieten. Für OGD ist die CC-BY-Lizenz die interessanteste Variante. Sie er-

möglicht ein beliebiges Weiterverwenden unter Namensnennung der Datenquelle. Die Daten

dürfen bearbeitet und verändert werden.

Abbildung 3.3: Übersicht über die verschiedenen Creative Commons Lizenzen

Quelle: (Kaltenböck/Thurner, 2011, S. 193)

In Österreich wird vielfach die CC-BY-Lizenz eingesetzt. Daneben sind auch individuelle

Lizenzen üblich. Die CC-Lizenzen bieten gegenüber eigens verfassten Nutzungsbedingungen

einige Vorteile: Sie sind international und auch für Nicht-Juristen verständlich, ein langwie-

riges Einlesen in individuelle Vereinbarungen entfällt. Ihr Text liegt in vielen verschiedenen

Sprachen vor. Die einfache Symbolisierung erleichtert ein schnelles Erfassen der Nutzungs-

beschränkungen (vgl. Kaltenböck/Thurner, 2011, S. 192).

3.5 Beispiele anderer �freier� Daten

Neben OGD gibt es eine Vielzahl anderer, freier Informationen der Verwaltung, die aufgrund

ihrer strengen Lizenzierung oder ihres schwer maschinell zu verarbeitenden Format nicht den

Anforderungen von OGD entsprechen. Einige Beispiele dafür sind in Tabelle 3.4 auf Seite 20



dargestellt. In den Spalten �L� und �M� ist angegeben, warum diese Daten nicht zu den

OGD zu zählen sind.

Tabelle 3.4: Beispiele �freier� Datenquellen in Österreich

Bezeichnung URL Beschreibung

der Daten

Format(e) La Mb

Statistik Austria statistik.at Amtliche Statistik html, pdf, xlsx x x

Umweltbundesamt umweltbundesamt.at Umweltdaten,

Schadsto�e

webgis, html, teilw.

visualisiert

x x

AMS ams.at Arbeitsmarktdaten html x

ZAMG zamg.ac.at Wetterdaten html, visualisiert x x

geoland.at geoland.at GIS-Daten der

Länder

webgis x x

Geoimage-Austria geoimage.at Orthophotos WMS x

aDaten sind wegen der zu strikten Lizenz nicht zu den OGD zu zählen.bDaten sind wegen der schlechten Maschinenlesbarkeit nicht zu den OGD zu zählen.

Quelle: Eigene Recherche und Darstellung, 2012

3.6 Relevanz für die Raumplanung

3.6.1 Welche Daten sind relevant?

Für die Relevanz der Daten für die Raumplanung wurden zwei Kriterien aufgestellt:

� Es muss sich um raumbezogende Daten handeln.

� Es muss ein thematischer Bezug zur Raumplanung vorhanden sein.

Abbildung 3.4 auf Seite 21 zeigt die Datensatzgruppen, die in der Analyse der Daten der

OGD-Plattformen Österreichs erarbeitet wurden. Grün dargestellt sind Gruppen, die einen

starken Raumbezug sowie einen thematischen Bezug zur Raumplanung aufweisen. Sie werden

als besonders relevant erachtet. Die Gruppen �Politik� und �Recht/Verwaltung� weisen nur

einen schwachen räumlichen Bezug auf. Da sie thematisch wichtig für die Raumplanung sind,

werden sie ebenfalls als relevant erachtet. Die Gruppe �Wetter� ist für die Raumplanung


statistik.at

umweltbundesamt.at

ams.at

zamg.ac.at

geoland.at

geoimage.at


nicht relevant. Ein Groÿteil der Daten kann also als potentiell nützlich für die Raumplanung

angesehen werden.

Abbildung 3.4: Raumplanungsrelevanz der Daten der OGD-Plattformen Österreichs auf-

grund des räumlichen und thematischen Bezugs


3.6.2 Wer ist �die Raumplanung�?

Es soll die Relevanz von OGD für die Raumplanung untersucht werden. Doch wer ist �die

Raumplanung�? Der Studienplan für das Bachelorstudium �Raumplanung und Raumord-

nung� an der TU Wien listet als potentielle ArbeitgeberInnen für AbsolventInnen unter

anderen die folgenden Bereiche auf (vgl. TU Wien, 2011, S. 4):

� ö�entliche Verwaltung und nachgelagerte Institutionen,

� private Planungsbüros,

� privatwirtschaftliche Unternehmen, insbesondere im Bereich Immobilien- und Stand-

ortentwicklung,

� Verbände, Interessensvertretungen, NGOs,

� Wissenschafts- und Forschungseinrichtungen.



RaumplanerInnen sind also für die ö�entliche Verwaltung, in privatwirtschaftlichen Unter-

nehmen, in der Wissenschaft sowie in Vertretungen der Zivilgesellschaft tätig. Für Plane-

rInnen der verschiedenen Tätigkeitsbereiche ergeben sich unterschiedliche Anforderungen an

Datenangebote. Im Folgenden wird die Relevanz von OGD für die einzelnen Berufsgruppen

erörtert.

3.6.3 RaumplanerInnen in der ö�entlichen Verwaltung

Für PlanerInnen in der ö�entlichen Verwaltung stellt OGD eine groÿe Chance dar. Gerade

bei Planungsvorhaben ist hohe Transparenz und die Einbeziehung der BürgerInnen eine Vor-

raussetzung für die Akzeptanz der Maÿnahmen. OGD ist ein erster Schritt in Richtung mehr

Transparenz. Information stellt auch die Basis für konsultative Beteiligung und schlieÿlich

für die kooperative Einbeziehung der Bevölkerung in den Entscheidungsprozess dar (Abbil-

dung 3.5). In Planungsprozessen kann mit der Einbeziehung der Bevölkerung nicht nur die

Akzeptanz, sondern auch die Qualität der Planung gesteigert werden.

Einen Schritt in Richtung konsultative Beteiligung geht z. B. das App �Mach mit!�1, das

auf der Homepage der OGD-Plattform Wien verlinkt ist. Mit diesem kann man Mängel im

ö�entlichen Raum direkt bei der Gemeinde melden.

Ein weiterer Vorteil von OGD ist die Reduktion von Kosten für die Verwaltung. Abbil-

dung 3.6 auf Seite 23 zeigt schematisch die Vorgangsweise bei der Entwicklung von Services

durch die Verwaltung. Im klassischen Fall übernimmt die Verwaltung die Erhebung, Auf-

1http://data.wien.gv.at/apps/machmit.html

Abbildung 3.5: Intensitätsstufen der Beteiligung

Quelle: (Parycek, 2008, S. 10)



bereitung der Daten sowie die Konzeption, Erstellung und Wartung von Anwendungen auf

Basis der Daten. Bei OGD bezieht die Verwaltung bereits nach der Erhebung der Daten die

Ö�entlichkeit mit ein. Jeder hat dann Gelegenheit auf Basis der Daten Services zu entwi-

ckeln. Durch diese O�enheit steigt potentiell die Qualität der Anwendungen. Die Verwaltung

erspart sich ein hohes Maÿ an IT-Investitionen. Damit diese Symbiose zwischen Verwaltung

und Ö�entlichkeit funktioniert, ist es wichtig, dass die Verwaltung mit der OGD-Comunity

in einem steten, konstruktiven Dialog bleibt. Die Raumplanung pro�tiert von aktiven Bür-

gerInnen, die durch OGD motiviert sind mitzugestalten.

Abbildung 3.6: Vergleich der Vorgangsweise im klassischen Fall und bei OGD, um von Re-

gierungsdaten verfügbar zu machen.

Quelle: Nach (Kaltenböck/Thurner, 2011, S. 226), eigene Darstellung, 2012

Nachteilig ist, dass nur Menschen mit Internetanschluss bzw. bei mobilen Apps Menschen

mit Smartphone von diesen Anwendungen pro�tieren. Die Raumplanung muss deshalb dar-

auf bedacht sein, auch für Menschen ohne Zugang zu modernen Kommunikationsmitteln



Serviceangebote bereit zu stellen und Wege �nden, sie an Planungsprozessen teilhaben zu

lassen.

3.6.4 RaumplanerInnen in der Wirtschaft

Planungsbüros

Die leichte Verfügbarkeit und die beliebige Verwertbarkeit der Daten macht OGD für Pla-

nungsbüros attraktiv. Allerdings ist bei den derzeit verfügbaren statistischen Daten die

räumliche Au�ösung für die meisten Analysen wohl zu gering. Da OGD in Österreich noch

am Anfang steht, ist anzunehmen, dass die Zahl und die Di�erenzierung der Daten stark

zunehmen wird. Umso mehr wird OGD für Planungbüros in Zukunft nützlich sein.

Privatwirtschaftliche Unternehmen

Für privatwirtschaftliche Unternehmen ist besonders die kommerzielle Verwertbarkeit der

OGD wichtig. Die liberale Lizenzierung lässt auch eine Mischung der Daten mit eigenen

Datenbeständen zu. Dank der Maschinenlesbarkeit der OGD ist dies einfach zu bewerkstel-

ligen.

Der derzeitige Datenbestand ist - zumindest auf den Plattformen von Wien und Linz - bereits

jetzt interessant für diese Gruppe. Da in Zukunft mit wesentlich mehr verfügbaren Daten

zu rechnen ist, gilt es für Unternehmen die weitere Entwicklung von OGD in Österreich im

Auge zu behalten.

Haftung

Die Frage der Haftung ist für Unternehmen besonders dringend. Wer ist verantwortlich

wenn jemand durch fehlerhafte Daten einer Applikation zu Schaden kommt? Das ist bei

der Verwendung von falschen Daten aus österreichischen OGD-Plattformen nicht einfach zu

klären. Die meisten Verö�entlichungen erfolgen unter einer Creative Commons Lizenz 2, die

die Namensnennung der Quelle fordert. Diese Lizenz beinhaltet aber keinen Haftungsaus-

schluss. Auch im �Open Government Weiÿbuch� wird die Dringlichkeit der Lösung dieser

Frage betont (vgl. Kaltenböck/Thurner, 2011, S. 156).

2http://creativecommons.org/licenses/by/3.0/at/deed.de



3.6.5 RaumplanerInnen in Verbänden, Interessensvertretungen und

NGOs

RaumplannerInnen in den oben genannten Institutionen pro�tieren sehr stark von OGD.

Die Transparenz und Nachvollziehbarkeit von Verwaltungshandlungen wird durch OGD er-

höht. So verö�entlicht die Stadt Linz die Protokolle der Gemeinderatssitzungen auf ihrer

Plattform3. Durch die Verö�entlichung von Primärdaten ist eine unabhängige Interpretati-

on der Daten möglich. Die Verwaltung verliert die Deutungshoheit über die Daten. Dank

der liberalen Lizenzierung ist eine Weiterverarbeitung und Visualisierung leicht möglich.

3.6.6 RaumplanerInnen in der Wissenschaft

Die Analyse der OGD-Plattformen zeigt, dass statistischen Daten nur in sehr grober räum-

licher Au�ösung vorliegen. So beziehen sich die Daten der OGD-Plattform Wien oft auf die

ganze Stadt oder auf Bezirke. Auÿerdem sind die Daten meist nur für die Gesamtbevölkerung

verfügbar oder nur nach wenigen Indikatoren (z. B. Geschlecht, Alter, ...) aufgeschlüsselt.

Für Analysen im wissenschaftlichen Bereich sind oft feinere räumliche Au�ösungen sowie

eine Aufschlüsselung nach bestimmten Indikatoren, die der Fragestellung entsprechen, von-

nöten. Die OGD-Plattformen in Österreich sind für die Wissenschaft daher keine maÿgebliche

Quelle für statistische Daten.

3.6.7 Welche Daten sind noch wünschenswert?

OGD in Österreich steht erst am Anfang. Auf allen Plattformen kommen in sehr kurzen

zeitlichen Abständen neue Daten hinzu. Aus Sicht der Raumplanung wären folgende weitere

Daten wünschenswert:

� Statische Daten mit höherer räumlicher Au�ösung

� Flächenwidmungs- und Bebauungspläne

� Umweltdaten (Schadsto�e)

� Daten des ö�entlicher Verkehr (Fahrpläne, Positionsdaten der Fahrzeuge und Züge)

� Daten des Individualverkehrs (Staumeldungen, Verkehrszählungen)

3http://data.linz.gv.at/daten/Politik_Verwaltung/


http://data.linz.gv.at/daten/Politik_Verwaltung/


Werden bestimmte Daten benötigt, die noch nicht online sind, ist es sinnvoll den Bedarf

an die jeweiligen OGD-Plattformen heranzutragen. Das Konzept von OGD kann nur durch

einen konstruktiven Dialog zwischen Datennutzern und Datenbereitstellern gut funktionie-

ren.



4 Nutzung und Verknüpfung der

Daten: Der Radfahrbegleiter - Ein

Beispielprojekt

Um die Möglichkeiten von OGD aufzuzeigen wurde eine Beispielapplikation entwickelt:

Der Radfahrbegleiter. Dieses Kapitel beschreibt die funktionalen Anforderungen, die Da-

tengrundlagen, die Benutzerober�äche und die Implementierung dieser Anwendung. Der

Radfahrbegleiter ist unter student.i�p.tuwien.ac.at/bachelor/rpl/kastenhofer aufrufbar. Von

dort kann auch der Quellcode der Anwendung bezogen werden.

4.1 Der Radfahrbegleiter

Da ich selbst begeisterter Radfahrer bin und meine täglichen Wege in Wien mit dem Rad

zurücklege, habe ich mich entschieden, eine Anwendung zu entwickeln, die den/die Radfah-

rerIn beim Erkunden der Stadt unterstützen soll. Als Basis für die Entwicklung diente die

Analyse der Daten der OGD-Plattform von Wien. Mit Hilfe einer interaktiven Karte sollen

Fragen folgender Art beantworten werden:

� Wo be�ndet sich ein Trinkbrunnen?

� Wo ist das nächste WC und wann hat es geö�net?

� Wo sind Citybike-Stationen, wo Fahrradabstellplätze?

� Wie kann ich meinen täglichen Radweg optimieren?

� Wo sind die Radwege, wo sind am wenigsten Ampeln?

� Wie komme ich am besten mit dem Rad von A nach B?

Seite 27

student.ifip.tuwien.ac.at/bachelor/rpl/kastenhofer


Beim Radfahrbegleiter handelt es sich um eine Webapplikation, die für Bildschirme mit einer

Au�ösung von 1024x768 Pixel und mehr gelayoutet ist. Er ist also für PCs, Laptops und

Tablets geeignet.

Diese und ähnliche Anwendungen können dazu beitragen, den Radverkehr in Wien zu fördern

und attraktiver zu machen.

4.2 Funktionale Anforderungen

Vor der Implementierung der Applikation wurden folgende funktionale Anforderungen de�-

niert:

1. Mehrere verschiedene Kartenhintergründe sollen geladen werden können. Es sollen

verschiedene Hintergründe der OpenStreetMap sowie der Stadt Wien wählbar sein.

Auch ein Orthophoto soll verfügbar sein.

2. Es sollen die einzublendenden Objektarten wählbar sein. Diese sollen über den Hinter-

grundkarten dargestellt werden. Passend zu den Objekten sollen Zusatzinformationen

- beispielsweise Ö�nungszeiten - angegeben werden, wenn dies sinnvoll erscheint. Diese

sollen in Popups angezeigt werden.

3. Die Kartendaten sollen nicht direkt auf der Website gespeichert werden. Stattdessen

sollen sie über WebMapServices eingebunden werden. Dadurch sind die Daten stets

aktuell und es wird auf dem eigenen Server Speicherplatz gespart.

4. Die Applikation soll für PC, Laptop und Tablets gelayoutet werden. Sie ist also eher

dafür gedacht, einen Radweg im Voraus zu planen, weniger um direkt während der

Fahrt zu navigieren.

5. Die Website soll auch eine kurze Beschreibung der Vorgehensweise und der benütz-

ten Bibliotheken (OpenLayers) geben. Der Quellcode der Seite soll leicht verfügbar

gemacht und gut kommentiert werden.

6. Es ist auf leichte Erweiterbarkeit der Applikation zu achten. Neue Daten sollen schnell

integrierbar sein.

Kapitel 4. Nutzung und Verknüpfung der Daten: Der Radfahrbegleiter - Ein Beispielprojekt Seite 28


4.3 Datengrundlagen

Beim Radfahrbegleiter werden Daten der OGD-Plattform Wiens1 und der freien Karte

OpenStreetMap2 kombiniert. Die vorhandenen Daten wurden auf ihre Relevanz für Rad-

fahrer geprüft. Geeignete Daten wurden ausgewählt.

4.3.1 Hintergrundkarten

Der/die BenutzerIn kann zwischen fünf verschiedenen Hintergrundkarten wählen. Das Or-

thophoto und der Stadtplan können jeweils mit und ohne Beschriftungen angezeigt werden.

Daten von der OGD-Plattform Wien

� Orthophoto (via WMTS): Zeigt ein Luftbild von Wien. Beschriftungen können ein

und ausgeblendet werden. Diese werden über WMTS angefordert und über das Luftbild

gelegt.

� Stadtplan (via WMTS): Zeigt den Stadtplan wie man ihn von wien.gv.at/stadtplan

kennt. Der Stadtplan kann ebenfalls mit und ohne Beschriftung eingeblendet werden.

Daten von OpenStreetMap

� Radfahrkarte (via WMTS): Blendet die �OpenCycleMap� ein. Diese Karte wurde mit

den Daten von OpenStreetMap speziell für Radfahrer gelayoutet. Es werden Radwege

und Radfahrstreifen sowie Einbahnen dargestellt.

� Mapnik (via WMTS): Mapnik ist die Standardkarte der OpenStreetMap und wird

auch auf der Startseite openstreetmap.org angzeigt.

� ÖV-Karte (via WMTS): Zeigt die �OpenTransportMap�. In dieser Karte werden die

Linien ö�entlicher Verkehrsmittel besonders hervorgehoben.

1http://data.wien.gv.at2http://openstreetmap.org


wien.gv.at/stadtplan

openstreetmap.org


4.3.2 Geo-Objekte

Die folgenden Objekte können über die Hintergrundkarten gelegt werden. Sie stammen alle

von der OGD-Plattform Wien. Zur Darstellung werden die Symbolgra�ken verwendet, die

von der Plattform zur Verfügung gestellt werden.

� Citybike-Stationen (via WMS): Standorte der Citybike-Stationen in Wien.

� Fahrradabstellplätze (via WMS): Für das sichere Abstellen des Zweirades.

� Trinkbrunnen (via WMS): Wenn einem nach langer Fahrt der Durst plagt, ist es gut

die Standorte der zahlreichen Trinkbrunnen zu kennen.

� ö�entliche WC-Anlagen (via WFS): Fährt man mit der Maus über ein derartiges

Symbol werden die Ö�nungszeiten der WC-Anlage in einem Popup eingeblendet. Da-

mit diese Zusatzinformationen verfügbar ist, wird dieser Layer über WFS eingebunden.

� Ampeln (via WMS): Möchte man nicht zu oft bei Rot an der Kreuzung stehen,

emp�ehlt es sich eine Route mit weniger Ampeln zu suchen.

4.4 Datenmodell

Abbildung 4.1 auf Seite 31 zeigt den Daten�uss beim Aufruf des Radfahrbegleiters. Der

Ablauf beim Aufruf des Radfahrbegleiters lässt sich in 3 Schritte einteilen:

Schritt 1 Der/die BenutzerIn ruft die URL des Radfahrbegleiters auf. Der Browser holt die

Programmlogik vom Server des Radfahrbegleiters. Darin enthalten ist auch die Datei

OpenLayer.js die das gleichnamige Framework enthält.

Schritt 2 Sobald eine Karte oder ein Kartenobjekt angezeigt werden sollen, wird eine XML-

Anfrage an den Server der Stadt Wien bzw. an openstreetmap.org versandt. Je nach

Art der Karte bzw. des Objekts wird eine XML-Anfrage verschickt, die dem WMS-,

dem WMTS- oder dem WFS-Standard genügt.

Schritt 3 Ist die Anfrage korrekt, so schickt der Server eine passende Antwort. Beim WMS

und WMTS ist das ein Bild, das den Kartenausschnitt zeigt. Beim WFS schickt er

eine XML-Datei mit den Geo-Objekten, die im Kartenausschnitt liegen.

Schritt 2 und 3 wiederholen sich bei jeder Veränderung des Kartenausschnitts und wenn

neue Layer eingeblendet werden.


openstreetmap.org


Abbildung 4.1: Darstellung des Daten�usses beim Aufruf des Radfahrbegleiters

Quelle: Eigene Konzeption und Darstellung, Karte: data.wien.gv.at, 2012

4.5 OpenLayers

4.5.1 Allgemeines

OpenLayers3 ist ein OpenSource-Framework zur dynamischen Einbindung von Karten in

Webapplikationen. Beim Radfahrbegleiter wird die Version 2.12 verwendet.

OpenLayers stellt eine Reihe von grundlegenden Funktionalitäten wie das Verschieben und

Zoomen des Kartenausschnittes mit der Maus zur Verfügung. Es können zahlreiche vorde�-

nierte Steuerelemente eingebunden werden. Etwa eines zum Auswählen von Layern, Anzei-

gen einer Maÿstabsleiste, zum Zoomen oder zum Feststellen der Geo-Position des Users bei

Mobilgeräten.

3http://openlayers.org/



Auÿerdem können mit OpenLayers Karten (=Layers) über WMS, WMTS und WFS, sowie

einer Reihe weiterer Schnittstellen eingebunden werden. Diese Layer stehen dem Program-

mierer dann als einfach handhabbare Objekte zur Verfügung. Die Kommunikation mit dem

WebMapServer über diese Schnittstellen übernimmt OpenLayers (Abbildung 4.2).

Abbildung 4.2: Die Rolle von OpenLayers im Daten�uss


Um die Dateigröÿe des Frameworks zu verringern, kann der JavaScript-Code von OpenLayers

�kompiliert� werden. Dabei werden beispielsweise über�üssiger Whitespace und Kommentare

entfernt. Bei starken Komprimierungen entsteht so ein für Menschen unleserlicher Code, der

allerdings zu einer wesentlich geringeren Dateigröÿe führt. Weiters kann man OpenLayers

bei der Kompilierung anweisen, nur die in der Applikation wirklich benötigten Klassen mit

einzubauen. Dadurch konnte die Gröÿe der Datei �OpenLayers.js� von 2,7 MB auf 318 KB

reduziert werden.

4.5.2 Anpassungen im OpenLayer-Quellcode

Bei der Implementierung der Klasse Openlayers.Layer.WMTS waren folgende Änderungen

nötig, um sie mit dem Server der OGD-Plattform Wien zum Laufen zu bringen:

Zeile 79681: "image/jpeg": "jpg",

geändert auf: "image/jpeg": "jpeg",

Zeile 79683: "jpeg": "jpg",

geändert auf: "jpeg": "jpeg",

Zeile 79941: var path = this.version + "/" + this.layer + "/" + this.style + "/";

geändert auf: var path = this.layer + "/" + this.style + "/";



Die Zeilenangaben beziehen sich auf die Datei OpenLayers.debug.js, die sich im Wurzel-

verzeichnis des OpenLayers-Quellcodes be�ndet. Die ersten beiden Änderungen bewirken,

dass OpenLayers bei der Anfrage eines Tiles nach einem Bild mit der Endung �.jpeg� fragt

und nicht nach einem mit �.jpg� als Endung. Die dritte Änderung bewirkt, dass die Versi-

on von WMTS nicht im Anfragepfad enthalten ist. Dies ist bei der OGD-Plattform Wiens

anscheinend nicht der Fall.

4.5.3 Proxy für WFS-Zugri�e

Die Daten, die OpenLayers über WFS einbindet, werden direkt via JavaScript nachgeladen.

Für solche Zugri�e gilt die �Same Origin Policy�. D.h. JavaScript kann auf diese Weise

nur auf Dateien zugreifen, die den gleichen Ursprung wie die JavaScript-Datei haben. Das

sind die Dateien auf dem eigenen Server. Um trotzdem auf Dateien auÿerhalb zugreifen

zu können, kann man ein Proxy einrichten, der als Vermittler fungiert. Der Proxy be�ndet

sich auf dem eigenen Server und übernimmt die Kommunikation nach auÿen. OpenLayers

liefert ein Beispielproxy mit, das man mit dem Apache-Webserver verwenden kann (vgl.

Jansen/Adams, 2010, S. 187).

Abbildung 4.3 zeigt wie man das Proxy-Skript in OpenLayers einbindet. Das Script muss

sich dabei im Ordner �cgi-bin� von Apache be�nden.

Abbildung 4.3: OpenLayers anweisen, ein Proxy-Script zu verwenden


4.6 Implementierung

4.6.1 Benutzerober�äche

Abbildung 4.4 auf Seite 35 zeigt einen Screenshot der Benutzerober�äche des Radfahrbeglei-

ters. Im oberen Bereich be�nden sich das Banner und die Links zu den verschiedenen Teilen



der Applikation. Hier kann man von der Karte zur Dokumentation, zu weiterführenden Links

und zum Impressum gelangen (1).

Auf der rechten Seite be�ndet sich eine Toolbox. Damit kann man die darzustellenden Inhalte

auswählen. In der Auswahlliste (2) kann man die Basiskarte wählen, die im Hintergrund

angezeigt werden soll. Es können die in Abschnitt 4.3.1 auf Seite 29 angeführten Karten

gewählt werden.

Mit den Checkboxen darunter können die Objekte ausgewählt werden, die über der Basis-

karte dargestellt werden sollen (3). Die in Abschnitt 4.3.2 auf Seite 30 angeführten Objekte

stehen zur Auswahl. Zoomt der/die NutzerIn hinaus, so werden nach und nach jene Layer

ausgeblendet, die die Karte mit zu vielen Objekten überschwemmen würden. Die entspre-

chenden Checkboxen werden deaktiviert. Beim Hineinzoomen werden die Layer dann wieder

angezeigt. Ganz unten in der Toolbox werden noch die Lizenzhinweise der verwendeten Da-

ten angezeigt.

Den Rest des Bildschirms füllt die Karte (4). Es werden die ausgewählte Basiskarte und

darüber die jeweiligen Objekte angezeigt. Der/die NutzerIn kann per Maus zoomen und

den Kartenausschnitt verschieben. Links oben be�nden sich alternativ zwei Buttons zum

Zoomen. Links unten wird eine kleine Maÿstabsleiste angezeigt.



Abbildung 4.4: Die Benutzerober�äche des Radfahrbegleiters

Quelle: Eigene Konzeption und Darstellung, Karte: data.wien.gv.at, 2012

4.6.2 Verzeichnisstruktur

Abbildung 4.5 auf Seite 36 zeigt die Verzeichnisstruktur der Applikation. Die �Homepage� der

Anwendung ist die Datei index.html. Von hier aus kann der/die NutzerIn zu den anderen

Teilen der Anwendung - der Hauptkarte (map.html), der Dokumentation (documentation.

html), den Weblinks (links.html) sowie dem Impressum (impressum.html) - navigieren.

Im Ordner css (CascadingStyleSheets) sind die Formatierungsinformationen der jeweiligen

HTML-Dokumente enthalten. In der Datei basis.css werden grundlegende Formatierungen

für alle Seiten gesetzt.

Der Ordner img enthält die in der Applikation verwendeten Bilder. Auÿerdem ist das Icon

enthalten, das im Browser neben der URL angezeigt wird (Favicon).


data.wien.gv.at

documentation.html

documentation.html

basis.css


Abbildung 4.5: Verzeichnisstruktur der Web-App


Die JavaScript-Dateien be�nden sich im Ordner js. Abbildung 4.6 zeigt den Inhalt dieses

Ordners. OpenLayers.js enthält das OpenLayers-Framework. OpenStreetMap.js enthält

drei Klassen zur direkten Einbindung der OpenStreetMap-Karten in OpenLayers. In der

Datei map.js ist die Logik des Radfahrbegleiters enthalten, die ich selbst implementiert

habe. Der nächste Abschnitt beschreibt den Aufbau dieser Datei.

Abbildung 4.6: Inhalt des Ordners js




4.6.3 Funktionsweise des Radfahrbegleiters: Die Datei map.js

Die Datei map.js enthält die Programmlogik der Anwendung. Im Folgenden werden die

Funktionen beschrieben, die darin de�niert werden.

init_map()

init_map() wird beim Starten der Applikation ausgeführt. Die Funktion dient der Initali-

sierung der Anwendung. Zuerst werden die Steuerelemente der Toolbox auf ihre Ausgangs-

stellung gebracht (Zeilen 36-44).

Dann wird ein Kartenobjekt erstellt (Abbildung 4.7). Dieses Objekt ist das Hauptobjekt

in OpenLayers. Ihm werden später Layer und Steuerelemente hinzugefügt. Die Funktion

OpenLayers.Map() erwartet zwei Parameter. Der erste ist die ID des HTML-Elements,

das die Karte enthalten soll. Im Beispiel ist diese ID �main_map�. Der Zweite Parameter

ist eine Liste von Optionen, die für die Karte gelten sollen. In Abbildung 4.7 wird die

Projektion, sowie die Einheiten der Karte gesetzt. Der Mittelpunkt der Karte wird de�niert.

In unserem Fall die Variable center, welche die Koordinaten des Stephansdoms enthält. Zeile

57 legt die Anzahl der Zoomstufen fest. In der Auswahl der Projektion und der Zoomstufen

ist man insofern beschränkt, als die Karten, die über WMTS eingebunden werden, nur in

einer bestimmten Projektion und nur in gewissen Maÿstäben zur Verfügung stehen. Um die

Hintergrundkarten einbinden zu können, musste als Projektion Spherical Mercartor mit der

ID �EPSG:3857� sowie 19 Zoomstufen gewählt werden. Schlieÿlich wird noch festgelegt, dass

beim Zoomen die Funktion zoom_changed aufgerufen werden soll.

Abbildung 4.7: Erstellen der Hauptkarte für OpenLayers




Im nächsten Schritt werden die Hintergrundlayer sowie die Objektlayer erstellt und der Karte

hinzugefügt (Zeilen 68-238). Abbildung 4.8 zeigt die De�nition des Objektlayers mit den

Citybike-Stationen. Dem Konstruktor OpenLayers.Layer.WMS werden folgende Parameter

übergeben:

Ein beliebiger Name für den Layer (Zeile 132). Die URL des Servers, von dem die Da-

ten abgefragt werden sollen (Zeile 133). Der dritte Parameter ist eine Liste von Optionen,

die bei der WMS-Anfrage verwendet werden sollen. Im Beispiel wird der Layer �CITYBI-

KEOGD� abgefragt und es wird um Bilder im PNG-Format gebeten. Auÿerdem soll der

Hintergrund der Karte transparent sein, um die Hintergrundkarten sichtbar durchscheinen

lassen zu können (Zeilen 134-138). Der Vierte Parameter ist eine Liste von Eigenschaften

die das OpenLayers-Objekt erhalten soll (Zeilen 139-143). Es wird eine Layer-ID gesetzt.

Dabei handelt es sich um eine von mir de�nierte Eigenschaft um den Layer später identi-

�zieren zu können. Die Objektlayer werden nicht als Hintergrundlayer de�niert (Zeile 141)

und standardmäÿig ausgeblendet (Zeile 142).

Abbildung 4.8: Erstellen des City-Bike-Layers


Abschlieÿend wird die Anzeige der Popups de�niert, die erscheinen wenn der/die NutzerIn

mit der Maus über das Symbol einer ö�entlichen Toilette fährt (Zeilen 238-295).

zoom_changed()

Damit der Bildschirm bei niedrigen Zoomstufen nicht von Objekten überschwemmt wird,

werden diese automatisch aus- und auch wieder eingeblendet. Abbildung 4.9 auf Seite 39



zeigt den entsprechenden Codeteil. Die Fahrradabstellplätze werden bereits ab Zoomlevel 15

(von 19) ausgeblendet, da von ihnen sehr viele vorhanden sind. Trinkbrunnen und Citybikes

werden dagegen erst ab Zoomlevel 12 deaktiviert (Zeile 384-392).

Abbildung 4.9: Ausblenden der Objektlayer je nach Zoomstufe


set_baselayer(identi�er)

Diese Funktion wird beim Ändern der Auswahl des Baselayers in der Toolbox aktiviert. Sie

blendet den mit identifier bezeichneten Layer ein. Gegebenenfalls wird auch der Beschrif-

tungslayer darüber eingeblendet (Zeilen 436-486).

set_layer(checkbox)

Die Funktion dient zum Ein- und Ausblenden von Objektlayern. Es wird die ID der jeweiligen

Checkbox an die Funktion übergeben. Je nachdem, ob bei der Checkbox das Häkchen gesetzt

ist und ob die Checkbox deaktiviert ist oder nicht wird der Layer ein- oder ausgeblendet



(Zeilen 491-540). Die Funktion wird einerseits beim Klicken auf eine der Checkboxen in der

Toolbox aufgerufen. Andererseits wird sie auch von der Funktion zoom_changed verwendet

in der je nach Zoomstufe Checkboxen aktiviert oder deaktiviert werden. Anschlieÿend wird

mit jeder Checkbox-ID set_layer ausgeführt. Dadurch werden die richtigen Layer ein- bzw.

ausgeblendet (Abbildung 4.10).

Abbildung 4.10: Aufruf der Funktion set_layer beim Ändern der Zoomstufe


map_resize()

Die Funktion berechnet je nach Fenstergröÿe des Browsers die richtige Länge und Breite für

den Kartenausschnitt und weist diese Werte zu (Zeilen 543-613). Diese Funktion ist nur durch

die etwas andere Implementierung mancher CSS-Eigenschaften und des Document Object

Model (DOM) durch den Internet Explorer nötig geworden. Indem man die Kartengröÿe

via JavaScript - also mit dieser Funktion - setzt, erreicht man die Browserkompatibilität der

Anwendung auch beim Internet Explorer.



5 Zusammenfassung und

Schlussfolgerungen

Open Government Data ist ein Konzept, das die Verö�entlichung von Verwaltungsdaten

in maschinenlesbarer Form und mit liberaler Lizenzierung vorsieht. In den Strategien der

EU wird OGD noch nicht direkt erwähnt. Auch in Gesetzestexten in Österreich und der

EU �ndet man das Konzept derzeit nicht wieder. Allerdings hat sowohl die EU als auch

Österreich die Wichtigkeit der Daten der ö�entlichen Verwaltung für Zivilgeselschaft und

Wirtschaft erkannt. In Österreich wird in Kooperation von Bund, Ländern und Gemeinden

an der Umsetzung von OGD gearbeitet.

Die erste OGD-Plattform hat die Stadt Wien im Frühjahr 2011 eingerichtet. Die Plattform

der Stadt Linz startete im Herbst 2011. Im Frühjahr 2012 folgten der Bund, Tirol und

Vorarlberg. Der Umfang der angebotenen Daten variert sehr stark und spiegelt den Ent-

wicklungsstand der Portale wieder: Wien und Linz bieten am meisten Daten und decken

fast alle der ingesamt gebotenen Kategorien ab. Die Portale des Bundes und von Vorarlberg

folgen dahinter. Das Portal von Tirol bietet Datensätze aus nur 2 von 15 Kategorien an.

Hinsichtlich der Maschinenlesbarkeit der Daten unterscheiden sich die Portale deutlich: Im

Portal des Bundes und des Landes Vorarlberg be�nden sich einige Datensätze, die aufgrund

ihrer schlechten Maschinenlesbarkeit nicht zu den OGD zu zählen sind. Am Besten schneiden

auch hier die Portale von Linz und Wien ab.

Die Relevanz für die Raumplanung variert mit dem Tätigkeitsbereich der PlanerInnen: Für

RaumplanerInnen in der Verwaltung stellt OGD eine groÿe Chance dar, um Transparenz zu

fördern und einen ersten Schritt Richtung mehr Beteiligung zu gehen. Für Planungsbüros

und privatwirtschaftliche Unternehmen sind OGD längerfristig eine ausgezeichnete Daten-

quelle. Die Frage der Haftung bei falschen Daten ist noch zu klären. Für die Wissenschaft

sind OGD als Quelle statistischer Daten weniger interessant, da sie derzeit nur unzureichende

räumliche Au�ösung bieten.

Seite 41


Um die Nutzungsmöglichkeiten von OGD im Umfeld der Raumplanung darzustellen, wurde

im Rahmen dieser Arbeit die Beispielanwendung �Radfahrbegleiter für Wien� entwickelt.

Daten der OGD-Plattform Wiens und der OpenStreetMap werden darin verknüpft, um

RadfahrerInnen mit einer interaktiven Karte auf ihren täglichen Wegen zu unterstützen.

Die Web-Anwendung und der Quellcode sind online verfügbar.

�Open Government Data� steht in Österreich erst am Anfang. Bereits jetzt kann man sinnvoll

mit den Daten arbeiten und Anwendungen erstellen. Sowohl das Datenangebot, als auch die

Zahl der OGD-Plattformen in Österreich wird weiter zunehmen. Die Nützlichkeit und damit

der Erfolg von OGD wird davon abhängen, ob es gelingt, die Datenangebote in Österreich

und auch auf Ebene der EU zu verknüpfen und kompatibel zu gestalten.

Kapitel 5. Zusammenfassung und Schlussfolgerungen Seite 42


6 Verzeichnisse

Seite 43


6.1 Quellenverzeichnis

Auskunftsp�ichtgesetz (1987), Bundesgesetz über die Auskunftsp�icht der Verwaltung des

Bundes, BGBl. Nr. 287/1987 idF BGBl. I Nr. 158/1998.

Berners-Lee, T. (2006), Linked Data - Design Issues, w3.org/DesignIssues/LinkedData.html,

(21. 05. 2012).

Bundeskanzleramt Österreich (2007), Plattform Digitales Österreich, digitales.oesterreich.gv.

at, (18. 9. 2012).

Bundesstatistikgesetz (2009), Bundesgesetz über die Bundesstatistik, BGBl. I Nr. 163/1999

idF BGBl. I Nr. 125/2009.

E-GovG (2010), E-Government-Gesetz, Bundesgesetz über Regelungen zur Erleichterung

des elektronischen Verkehrs mit ö�entlichen Stellen, BGBl. I Nr. 10/2004 idF BGBl. I Nr.

111/2010.

Eibl, G., Höchtl, J., Lutz, B., Parycek, P., Pawel, S. und Pirker, H. (2011), White Paper Open

Government Data - 1.0.0, e-government Bund-Länder-Gemeinden, reference.e-government.

gv.at/Veroe�entlichte-Informationen.2774.0.html, (13. 03. 2012).

Europäische Kommission (1998), Grünbuch über Informationen des ö�entlichen Sektors,

KOM(1998)585.

Europäische Kommission (2010), Eine Digitale Agenda für Europa, KOM(2010) 245.

Europäisches Parlament und Rat der Europ. Union a (2003), Richtlinie über den Zugang der

Ö�entlichkeit zu Umweltinformationen und zur Aufhebung der Richtlinie 90/313/EWG

des Rates, 2003/4/EG.

Europäisches Parlament und Rat der Europ. Union b (2003), Richtlinie über die Weiterver-

wendung von Informationen des ö�enlichen Sektors, 2003/98/EG.

Grandits, F. (2006), Konvention e-gov-koop 2.0.2, reference.e-government.gv.at/

ORG-KOOP-e-gov-koop-2-0-2.916.0.html, (14. 03. 2012).

Habernig, C., Kaltenböck, M. und Lutz, B. (2012), White Paper OGD Metadaten - 1.1,

reference.e-government.gv.at/Veroe�entlichte-Informationen.2774.0.html, (15. 04. 2012).

Harm, R. (2011), OGD-Stammtisch in Salzburg, open3.at/2011/09/

2-ogd-stammtisch-in-salzburg, (12. 09. 2012).

Kapitel 6. Verzeichnisse Seite 44

w3.org/DesignIssues/LinkedData.html

digitales.oesterreich.gv.at

digitales.oesterreich.gv.at

reference.e-government.gv.at/Veroeffentlichte-Informationen.2774.0.html


reference.e-government.gv.at/ORG-KOOP-e-gov-koop-2-0-2.916.0.html

reference.e-government.gv.at/ORG-KOOP-e-gov-koop-2-0-2.916.0.html


open3.at/2011/09/2-ogd-stammtisch-in-salzburg

open3.at/2011/09/2-ogd-stammtisch-in-salzburg


IWG (2005), Informationsweiterverwendungsgesetz, Bundesgesetz über die Weiterverwen-

dung von Informationen ö�entlicher Stellen, BGBl. I Nr. 135/2005.

Jansen, M. und Adams, T. (2010), OpenLayers, Webentwicklung mit dynamischen Karten

und Geodaten.

Kaltenböck, M. und Thurner, T., Hrsg. (2011), Open Government Data Weiÿbuch, Edition

Donau-Universität Krems, Wien.

open 3 (2012), Verein zur Förderung von openSociety, openGovernment und openData,

Impressum, open3.at/impressum, (14. 03. 2012).

Open Geospatial Consortium Inc. (2007), Styled Layer Descriptor pro�le of the Web Map

Service Implementation Speci�cation, opengeospatial.org/standards/sld, (25. 08. 2012).

Open Geospatial Consortium Inc. (2012a), OpenGIS Web Map Server Implementation Spe-

ci�cation 1.3.0, opengeospatial.org/standards/wms, (01. 05. 2012).

Open Geospatial Consortium Inc. (2012b), OpenGIS Web Map Tile Service Implementation

Standard 1.0.0, opengeospatial.org/standards/wmts, (19. 06. 2012).

Parycek, P. (2008), Withepaper EDEM-1.0.0, e-government Bund-Länder-Gemeinden,

reference.e-government.gv.at/PG-EDEM-E-Democracy-E-Partic.1827.0.html, (12. 03. 2012).

Pawel, S. (2011), Auftaktveranstaltung der Open Commons Region Linz, opencommons.

public1.linz.at/?p=211, (12. 09. 2012).

Stadt Linz (2012), Open Commons Region Linz, linz.at/leben/55472.asp, (12. 09. 2012).

Stadt Wien (2012), Stadtplan-API, data.wien.gv.at/katalog/stadtplan-api.html, (19. 06.

2012).

TU Wien (2011), Curriculum für das Bachelorstudium Raumplanung und Raumordnung,

ar.tuwien.ac.at/�leadmin/artu_data/Daten/Studium/Bachelorstudium_Raumplanung/

Bachelorstudium_Raumplanung_und_Raumordnung_ab_01_10_2011_letztStand.pdf,

(20. 06. 2012).

UIG (2005), Uweltinformationsgesetz BGBl. I Nr. 495/1993 idF BGBl. I Nr. 6/2005.

Verein Open Knowledge Forum Österreich (2010), Impressum OGD-Austria, gov.opendata.

at/site/imprint, (14. 03. 2012).


open3.at/impressum

opengeospatial.org/standards/sld

opengeospatial.org/standards/wms

opengeospatial.org/standards/wmts

reference.e-government.gv.at/PG-EDEM-E-Democracy-E-Partic.1827.0.html

opencommons.public1.linz.at/?p=211

opencommons.public1.linz.at/?p=211

linz.at/leben/55472.asp

data.wien.gv.at/katalog/stadtplan-api.html

ar.tuwien.ac.at/fileadmin/artu_data/Daten/Studium/Bachelorstudium_Raumplanung/Bachelorstudium_Raumplanung_und_Raumordnung_ab_01_10_2011_letztStand.pdf

ar.tuwien.ac.at/fileadmin/artu_data/Daten/Studium/Bachelorstudium_Raumplanung/Bachelorstudium_Raumplanung_und_Raumordnung_ab_01_10_2011_letztStand.pdf

gov.opendata.at/site/imprint

gov.opendata.at/site/imprint


W3C (2012), Dokuments - RDFWorking Group Wiki, w3.org/2011/rdf-wg/wiki/Documents,

(19. 06. 2012).

Wikipedia a (2012), Tagged Image File Format (TIFF), en.wikipedia.org/wiki/Tagged_

Image_File_Format, (18. 6. 2012).

Wikipedia b (2012), JPEG, de.wikipedia.org/wiki/JPEG, (18. 06. 2012).

Wikipedia c (2012), Portable Network Graphics, de.wikipedia.org/wiki/Portable_Network_

Graphics, (18. 06. 2012).

Wikipedia d (2012), CSV (Dateiformat), e.wikipedia.org/wiki/CSV_(Dateiformat), (18. 06.

2012).

Wikipedia e (2012), Extensible Markup Language, de.wikipedia.org/wiki/XML, (18. 06. 2012).

Wikipedia f (2012), Portable Document Format, de.wikipedia.org/wiki/Pdf, (19. 06. 2012).

Wikipedia g (2012), Microsoft Excel, de.wikipedia.org/wiki/Microsoft_Excel, (19. 06. 2012).

Wikipedia h (2012), Geography Markup Language, de.wikipedia.org/wiki/Geography_

Markup_Language, (19. 06. 2012).

Wikipedia i (2012), Keyhole Markup Language, de.wikipedia.org/wiki/Keyhole_Markup_

Language, (19. 06. 2012).

Wikipedia j (2012), Shape�le, en.wikipedia.org/wiki/Shape�le, (19. 06. 2012).

Wikipedia k (2012), RSS, de.wikipedia.org/wiki/RSS, (19. 06. 2012).


w3.org/2011/rdf-wg/wiki/Documents

en.wikipedia.org/wiki/Tagged_Image_File_Format

en.wikipedia.org/wiki/Tagged_Image_File_Format

de.wikipedia.org/wiki/JPEG

de.wikipedia.org/wiki/Portable_Network_Graphics

de.wikipedia.org/wiki/Portable_Network_Graphics

e.wikipedia.org/wiki/CSV_(Dateiformat)

de.wikipedia.org/wiki/XML

de.wikipedia.org/wiki/Pdf

de.wikipedia.org/wiki/Microsoft_Excel

de.wikipedia.org/wiki/Geography_Markup_Language

de.wikipedia.org/wiki/Geography_Markup_Language

de.wikipedia.org/wiki/Keyhole_Markup_Language

de.wikipedia.org/wiki/Keyhole_Markup_Language

en.wikipedia.org/wiki/Shapefile

de.wikipedia.org/wiki/RSS


6.2 Abbildungsverzeichnis

3.1 Auszug aus der umfassenden Datenanalyse der OGD-Plattformen Österreichs 11

3.2 Vorhandene Datensatzgruppen auf den österreichischen OGD-Portalen . . . . 12

3.3 Übersicht über die verschiedenen Creative Commons Lizenzen . . . . . . . . . 19

3.4 Raumplanungsrelevanz der Daten der OGD-Plattformen Österreichs aufgrund

des räumlichen und thematischen Bezugs . . . . . . . . . . . . . . . . . . . . 21

3.5 Intensitätsstufen der Beteiligung . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Vergleich der Vorgangsweise im klassischen Fall und bei OGD, um von Re-

gierungsdaten verfügbar zu machen. . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Darstellung des Daten�usses beim Aufruf des Radfahrbegleiters . . . . . . . . 31

4.2 Die Rolle von OpenLayers im Daten�uss . . . . . . . . . . . . . . . . . . . . . 32

4.3 OpenLayers anweisen, ein Proxy-Script zu verwenden . . . . . . . . . . . . . . 33

4.4 Die Benutzerober�äche des Radfahrbegleiters . . . . . . . . . . . . . . . . . . 35

4.5 Verzeichnisstruktur der Web-App . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 Inhalt des Ordners js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.7 Erstellen der Hauptkarte für OpenLayers . . . . . . . . . . . . . . . . . . . . . 37

4.8 Erstellen des City-Bike-Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.9 Ausblenden der Objektlayer je nach Zoomstufe . . . . . . . . . . . . . . . . . 39

4.10 Aufruf der Funktion set_layer beim Ändern der Zoomstufe . . . . . . . . . 40



6.3 Tabellenverzeichnis

3.1 Bestehende Open-Data-Plattformen . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Qualität von Linked Data. 5-Stern-Modell von Tim Berners-Lee. . . . . . . . 14

3.3 Bewertung der Daten der österreichischen Open-Data-Plattformen mit dem

5-Stern-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Beispiele �freier� Datenquellen in Österreich . . . . . . . . . . . . . . . . . . . 20



7 Anhang

7.1 Datenanalyse der österreichischen OGD-Portale

Seite 49

Wien Linz Tirol Vorarlberg BundBasisdaten I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Grenzen B,Z Akt V D,S *1 B Akt V D csv, gml K Akt V D shpFläche der Gemeindebezirke B Akt T D pdf, csv

Gemeindeliste G Akt T D csvStraßenplan P Akt P S WMTS 25cm Akt P D,S tiff, gif

Flächenwidmungsplan P Akt P D,S kmzOrthophoto P Akt P S WMTS 25cm Akt P D,S tiff, gif P Akt P W html

Höhenschichtmodell 1m Akt V D gml P Akt P W htmlDemographie I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Bev. nach Geschlecht + w. Merkmale B,Z J T D csv L,G 10J T D xlsBev. nach Altersgruppen + w. Merkmale B,Z Akt T D csv

Bev. nach Staatsangehörigkeit B,Z Akt T D csv G J T D pdf,csvStaatsbürgerschaftsverleihungen G Akt T D pdf

Bev. nach Geburtsland B,Z Akt T D csvBev. Migrationshintergrund B,Z Akt T D csvHauptwohnsitzbevölkerung G J T D pdf, csv

Datenbank zur Verwaltungszählung L,G J T W htmlEU-SILC: Tabellen Familie Ö Akt T D xlsBevölkerungsindikatoren G,B J T D csv

Geburten, Sterbefälle B Akt T D csv G,B J T D pdf, csv G J T D csvGeburtenüberschuss G J T D pdf, csv G Akt T D pdf

Wanderung nach (div.) Merkmalen G,B J T D csv G J T D pdfZuzüge, Wegzüge, Binnenwanderung G J T D pdf, csvPrognose der Bev. und der Haushalte L 5J T D xls

Beliebteste Vornamen G J T D csv G J T D csv L Akt T D pdfPolitik I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Wahlergebnisse G B Dat T D pdf, csv G J T D csvGemeinderatsprotokolle G Dat T D txt

G Dat T D txt

Buget I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Rechnungsabschluss G J T D csvFinanzgebarung G J T D csv

Recht / Verwaltung I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

RIS – Bundesrecht konsolidiert Ö,L,G Akt T W html

Liste österreichischer Finanzämter K Akt V D

Wirtschaft I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Arbeitsmarktindikatoren G J T D csv L M T D pdfWirtschaftsindikatoren G J T D csv

Wirtschafts- und Sozialstatistik L,G J T D

Arbeitslose G J T D pdf, csvGewerbeberechtigungen G J T D pdf, csv

AMS Aus- und Weiterbildung Ö Akt T W htmlAMS Arbeitsmarktdaten Ö,L Akt T W html

Prognose der Erwerbspersonen L 5J T D xlsExporte L J T D pdf

L J T D pdf

Neues von der Statistik L 2M T D pdf

Ö Akt T W html

Ö Akt T D xls

EU-SILC: Tabellen Jahreseinkommen Ö Akt T D xls

EU-SILC: Tabellen Arbeit Ö Akt T D xlsEU-SILC: Tabellen Konsumgüter Ö Akt T D xlsInternationale Organisationen K Akt V D,S *1

Infrastruktur I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Offene Bauvorhaben (Anzahl) G Akt T D csvPolizei K Akt V D,S *1

Einsätze der Feuerwehr (Art, Anzahl) G J T D pdf, csvFriedhöfe K Akt V D,S *1

Müllentsorgung K Akt V D,S *1Öffentliche WC-Anlagen K Akt V D,S *1

Trinkbrunnen K Akt V D,S *1Bürgerdienststellen K Akt V D,S *1

Multimediastationen K Akt V D,S *1Bauperiode B J T D pdf, csv

Anzahl der Wohungen in den Gebäuden B J T D pdf, csvGeschoßanzahl der Gebäude B J T D pdf, csv

Rechtsgrund der Wohnungsbenutzung B J T D pdf, csv

B J T D pdf, csv

B J T D pdf, csv

Wohnungen – Nutzfläche B J T D pdf, csv

Wohnungen – Wohnräume B J T D pdf, csvEU-SILC: Tabellen Wohnen Ö Akt T D xls

Verkehr (Teil 1) I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

ÖV-Haltestellen K Akt V D,S *1 K Akt V D csv, gmlÖV-Linien K Akt V D gml

Elektronische Fahrplanauskunft G Akt T S xmlAmpeln mit/ohne Akustikkennung K Akt V D,S *1Radfahranlagen, Themenradwege K Akt V D,S *1

Mountainbike-Rounten K Akt V D

Citybikestationen K Akt V D,S *1

Tagesordnung der Gemeinderatssitzungen

kml, Json

pdf, xls, html

Wirtschaftsbericht, Grafiken zur Wirtschaft

BALI web / ELISweb (Nat. & Internat. Arbeitsmarkt)EU-SILC: Tabellen Verteilung

Jahreseinkommen

Überwiegende Nutzung, Eigentumsverhältnisse der Gebäude

Wohnungen in neu- errichteten Gebäuden

shp,gpx,Kml

Kurzparkstreifen & Kurzparkzonen K Akt V D,S *1Taxistandplätze K Akt V D,S *1

Behindertenparkplätze K Akt V D,S *1Fahrradabstellanlagen K Akt V D,S *1Motorradabstellplätze K Akt V D,S *1Kraftfahrzeugbestand G J T D pdf, csv L J T D pdf

G J T D pdf, csv L J T D pdf

G J T D pdf, csv

Aufzüge in ÖV-Stationen K Akt V D,S *1

Bildung I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Schulen K Akt V D,S *1 A Akt T pdf, csv G J T D pdf

Schüler nichtdeutscher Muttersprache L 5J T D htmlPrognosen der Schülerzahlen G J T D pdf

Universitäten und Fachhochschulen K Akt V D,S *1Kindergarten K Akt V D,S *1 K Akt V D csv G J T D pdf

Krabbelstuben K Akt V D csvHorte K Akt V D csv

Volkshochschulen K Akt V D,S *1 A Akt T pdf, csvMusik- und,Singschulen K Akt V D,S *1

Büchereien K Akt V D,S *1

Ö Akt T D csv

Ö Akt T D csv

Ö Akt T D csv

EU-SILC: Tabellen Bildung Ö Akt T D xls

Gesundheit I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

A Akt T W html

Liste der Präventivdienste A Akt T W html

Krankenanstalten, Ambulatorien K Akt V D,S *1 K Akt V D csv A Akt T D pdfKrankenhausstationen K Akt V D,S *1

G J T D pdf, csv

ÄrztInnen in Krankenanstalten G J T D pdf, csv

Seniorenzentren K Akt V D csv

Wohn- und Pflegehäuser K Akt V D,S *1Apotheken K Akt V D csv

Defibrillatoren K Akt V D,S *1Daten der Sozialversicherung L Akt T D xls, pdf

G J A D pdf, csv

AKH Linz – Herkunft der PatientInnen G J T D pdf, csv

Soziales I II III IV V I II III IV V I II III IV V I II III IV V I II III IV VSozialausgaben in Österreich Ö J T D xls

Sozialberatungsstellen K Akt V D csvSozialmärkte K Akt V D,S *1

Jugendzentren K Akt V D csvClub AKTIV K Akt V D csv

EU-SILC: Tabellen Riskikogruppen Ö Akt T D xlsEU-SILC: Tabellen Armutsgefährdung Ö Akt T D xls

Umwelt I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Schutzgebiete K Akt V D,S *1 K Akt V D shp

K Akt V D,S *1 K Akt V D shp

Ramsargebiet K Akt V D,S *1 K Akt V D shp

Biotoptypenkartierung K Akt V D,S *1 K Akt V D shp

Naturparke K Akt V D shp

Biosphärenpark K Akt V D,S *1

Naturdenkmäler K Akt V D,S *1 K Akt V D shp

K Akt V D,S *1

Baumkataster K Akt V D,S *1

Solarpotentialkataster P Akt P S WMS

Gründachpotentialkataster P Akt P S WMS

Fließgewässer K Akt V D shp

Umweltwegweiser L Akt T W html

Freizeit I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Hotspot K Akt V D csv

Veranstaltung A Dat T S RSS A Dat V D csv

Sportanlagen K Akt V D,S *1 K Akt V D csv

Spielanlagen K Akt V D,S *1 K Akt V D csv

Schwimmbäder, Badestellen K Akt V D,S *1

Burgen und Schlösser K Akt V D,S *1

Campingplätze K Akt V D,S *1

Museen und Sammlungen K Akt V D,S *1

Tourismus I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Beherbergunsbetriebe G J T D pdf, csv G J T D xls

G J T D pdf, csv

Wetter I II III IV V I II III IV V I II III IV V I II III IV V I II III IV V

Meterologische Messerte L Akt Dat D csv

Straßenverkehrsunfälle mit Personenschaden

Flugfracht und Flugfrequenz am Flughafen

Hochschulen: Erteilte Lehrbefugnisse (Habilitationen)

Hochschulen: Wissensch./Künstl. Veröffentlichungen

Hochschulen: Lohngefälle zw. Frauen und Männern

Liste der ermächtigten Ärztinnen und Ärzte

Niedergelassene ÄrztInnen, Krankenanstalten

Belegung der stätischen Senioren- und Pflegeheime

Natura 2000 Habitat- & Vogelschutzrichtlinie

Netzwerk Natur, Ökologische Entwicklungsflächen

Herkunftsländer der Gäste von Beherbergungsbetrieben

I Räumliche Auflösung II Zeitlicher Bezug III Datenart IV ZugriffsartÖ Österreich Akt Aktuelle Daten P Pixeldaten D DatensatzL (Bundes)Land Dat mit Datum versehene Daten V Vektordaten S ServiceG Gemeinde M Monatiliche Daten T Alphanumerische Daten W WebplattformB Gemeindenbezirk 2M Zweimonatliche DatenZ Zählbezirk J Jährliche DatenA Adresse 5J Fünfjährliche Daten V DatentypP Pixeldaten 10J Zehnjährliche DatenK Koordinaten

*1 GML (WFS), JSON (WFS), KML (WMS – GeoServer), GeoRSS (WMS – GeoServer), CSV (WFS), ESRI Shapefile (WFS)

Open Government Data für dieRaumplanung - TU...

Documents

Transcript of Open Government Data für dieRaumplanung - TU...