OpenBochum

Aus LaborWiki
Wechseln zu: Navigation, Suche
OpenBochum

Release status: stable [box doku]

Description Bochum besitzt viele Stellen, die mit offenen Daten arbeiten. Wir wollen Ihnen dabei helfen, ihren Datensatz zu erweitern und zu verbessern.



Defibrillatoren in Bochum[Bearbeiten | Quelltext bearbeiten]

Protokoll: Sichtbarkeit für Anwender[Bearbeiten | Quelltext bearbeiten]

  • Google-Suche
    • "defibrillator bochum" ergibt die herzsicher-Karte als ersten Treffer
      • zweiter Treffer ist ein PDF-Dokument, dass nicht nutzbar ist
    • "herzinfarkt bochum"
      • klinikum-bochum.de
      • herzinfarktverbund-bochum.de
    • keine Erwähnung der Karte auf den Seiten, auch nicht auf WAZ-Artikeln verlinkt werden
  • Kartennutzung
    • Mobile Nutzung möglich
    • kurze URL bochum.de/herzsicher
      • wahrscheinlich unbekannt
  • Rot Kreuz Defi App hat ca. 15-20 Defibrillatoren in Bochum eingetragen (von insgesamt 115)
  • OSM hat drei Stück
  • Google Maps hat keinen einzigen

Protokoll: Sichtbarkeit für Entwickler[Bearbeiten | Quelltext bearbeiten]

  • Google-Suche
    • "defibrillator opendata bochum"
      • gut auffindbar und direkt auf dem Portal verlinkt
  • Eintrag im Portal:
    • Metadaten: geonetzwerk.Metropoleruhr Portal
      • wird verlinkt durch das OpenData-Portal Bochum
      • Datenumfang toll: letzte Atualisierung, Taxonomie, rechtliche Informationen, Kontakt (für Daten und Metadaten), Status, sind aktuelle Daten, IDs, SocialMedia, Bewertung,
      • Permalink: registry.gdi-de.org hat keinen funktionierenden Resolver
      • Sackgasse: kein Link auf die Daten im OpenData-Portal Bochum, nur ein Link auf die Karte selber
  • Todo: Kontakt mit dem Geoinformationsamt herstellen
  • Alternative:
    • Im OpenData-Portal gibt es einen Direktlink zu einer csv-Datei.
      • Praktische Probleme: Zeichensatz, ISO8859-1,
    • Kein Zusammenhang zwischen den Metadaten erkennbar.

Probleme[Bearbeiten | Quelltext bearbeiten]

  • Daten müssen aufbereitet werden
    • Encoding kaputt
    • Geoinformation ist im "EPSG25832"-Format, was OSM nicht standardmäßig verwendet
  • Daten sind lizenztechnisch nicht kompatibel mit OSM
    • Dadurch müssen wir jeden Defibrillator per Hand überprüfen und in OSM eintragen (Video dazu)
  • Es werden Stadtteildaten benötigt, die nicht im OpenData-Portal als Polygone zu bekommen sind und deswegen aus OSM entnommen werden müssen.

Denkmäler[Bearbeiten | Quelltext bearbeiten]

  • PDFs und Bilder, die nicht mit OCR eingescannt wurden
    • "Die Präsentation der PDF-Dokumente ist nur nach Absprache möglich."
  • Was sagt "datum" überhaupt aus?
  • Gibt es im OpenData-Portal der Stadt Bochum rechtsverbindliche Datensätze?
  • Bei den Vertriebsinformationen → Transferinformationen: Angegeben ist ein ESRI Shapefile, aber es wird nur auf die Visualisierung und WMS Denkmalübersicht bei dem das XML invalide ist, als auch der WFS Server zeigt einen "Unknown operation name"-Fehler.

Weitere Ideen[Bearbeiten | Quelltext bearbeiten]

  • "Hackathon" bzw. Vortrag bzgl. OpenData und OpenStreetMap in der Verwaltung
  • Die csv-Dateien müssen bei Aktualisierungen immer über den selben Link erreichbar sein
  • Walkability Score, der die fußläufige Erreichbarkeit von POIs durch die bauliche Struktur ermittelt
  • Lärmkarte aufgrund der städtischen Architektur und Infrastruktur
    • Erweiterbar durch CitizenScience: Lärmsensoren und Erhebungen
  • OpenData-Scoreboard nach Checklist zur Förderung des Wettbewerbs zwischen den Städten
    • Punkte nach objektiven Kriterien
      • Schemas vorhanden? Maschinenlesbares Schema?
      • Aktualisierungen? Häufigkeit, Aktualität der letzten Daten
      • Permalinks
      • Genauigkeit, Fehlerquote in den Daten
      • Zeichensatz-Kodierungen (Unicode, ...)
      • Datenformate standardisiert? Gängige Formate oder Exoten? Freie Formate?
      • klare Ansprechpartner
      • Quantität der Datensätze
      • Abdeckung verschiedener Themenbereiche
      • Automatische Abrufbarkeit ("Crawler")
      • Mobile-Schnittstelle
      • Qualität der Datenserver (Response-Zeit, Ausfallsicherheit)
      • Lizenz der Daten (klare Kennzeichnung, Freiheit, Kompatibilität mit Open Source)
      • Tools zur Verarbeitung von nicht-standard Daten?
    • Subjektive Punkte
      • Ansprechpartner Test
      • Usability Tests ("finde die Daten zu X")
    • Meta-Kriterien
      • Vergleichbarkeit der Daten unter den Städten