Projekt/OpenBochum: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
(Weitere Ideen)
(Weitere Ideen)
Zeile 32: Zeile 32:
 
** Punkte nach objektiven Kriterien
 
** Punkte nach objektiven Kriterien
 
*** Schemas vorhanden? Maschinenlesbares Schema?
 
*** Schemas vorhanden? Maschinenlesbares Schema?
*** Aktualisierungen?
+
*** Aktualisierungen? Häufigkeit, Aktualität der letzten Daten
 
*** Permalinks
 
*** Permalinks
 
*** Genauigkeit, Fehlerquote in den Daten
 
*** Genauigkeit, Fehlerquote in den Daten
 +
*** Zeichensatz-Kodierungen (Unicode, ...)
 
*** Datenformate standardisiert? Gängige Formate oder Exoten? Freie Formate?
 
*** Datenformate standardisiert? Gängige Formate oder Exoten? Freie Formate?
 
*** klare Ansprechpartner
 
*** klare Ansprechpartner
Zeile 40: Zeile 41:
 
*** Abdeckung verschiedener Themenbereiche
 
*** Abdeckung verschiedener Themenbereiche
 
*** Automatische Abrufbarkeit ("Crawler")
 
*** 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
 
** Subjektive Punkte
 
*** Ansprechpartner Test
 
*** Ansprechpartner Test

Version vom 23. August 2017, 18:00 Uhr

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

Probleme

  • 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.

Weitere Ideen

  • "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