+34

Freie Daten (API) statt APPS


Die Stadt München soll eine Schnittstellen-Plattform (API) entwickeln lassen, über die verfügbare strukturierte Daten zur freien Verwendung bereitgestellt werden. Dies erlaubt externen Entwicklern darauf aufsetzende Applikationen zu entwickeln. Sei es Webapplikationen oder native Apps für Mobil-Geräte.

Die Daten sollen in einem zeitgemäßen Format und Schnittstelle angeboten werden, beispielsweise RESTful JSON oder XML.

Ein Großteil der in mogdy genannten App-Vorschläge liese sich damit lösen:

  • Spielplatzfinder
  • Rollstuhlgerechte Wege (OpenWheelMap)
  • Veranstaltungsdaten
  • Umweltdaten (Luftqualität)
  • Wahlinformationen
  • Städtische Termine
  • Stadtratsveröffentlichungen (Protokolle)
  • Verkehrsinformationen (Baustellen/Beeinträchtigungen etc)
  • allgemeine POI (Points of Interest) Geodaten
  • sämtliche statistischen Informationen (Mietspiegel etc. pp)

Würde man diese Infrastruktur einmal aufbauen und mit externen Entwicklern zusammen definieren, so könnte die Stadt für sehr wenig finanziellen Einsatz einen deutlichen Mehrwert generieren. Vorhandene Datenquellen kann man nach und nach oder bei Interesse einbinden (Erweiterbarkeit, Investitionssicherheit)

Als Vorbilder dienen können:


Diskussionen

  • Ein Teil der Daten ist bereits vorhanden. Wir arbeiten daran, z.B. die POI's frei einstellen zu können. Viele der Daten gibt es (Mietspiegel, Verkehrsinformationen (aktuelle Karte), Stadtratsveröffentlichungen (RIS)).

    Andere Daten leben von der Pflege, die aber nur aufwändig durch Begehungen zu erhalten sind.

    Anders rum gefragt - wäre eine App, die uns in der Sondierung von Rollstuhlgerechten Wegen hilft nicht auch ein nettes Bürger-Projekt?

    • Wheelmap für das iPhone und wheelmap.org aus München ist ein super Projekt!

  • stefanmux ist dafür
    +2

    Ein Teil der oben angesprochenen Daten ist unter folgender Adresse als XML zu finden:

    http://api.mux.de/

  • anked ist dagegen
    +2

    Apps und open APIs sind kein widerspruch, Apps soll gar nicht unbedingt die Stadt entwickeln

    Diesen vorschlag verstehe ich nicht. In der eingangsbeschreibung zu MOGDY steht explizit, dass es darum geht, was sich bürgerInnen in einem digitalen München wünschen und dass diese wünsche nicht unbedingt von der stadt realisiert werden müssen sondern auch wünsche sein können, für die die stadt die voraussetzungen schafft - gerade eben durch bereitstellung dieser offenen datan. Die umsetzung dieser wünsche kann dann die community übernehmen. Es ist doch sehr interessant für die community, die gern apps programmieren möchte, herauszufinden, was die bürgerInnen gern hätten an apps. Warum sollen das nur programmierer wissen und entscheiden können? Hier ist input zu gewünschten apps und ihrer priorisierung durch die bürgerInnen möglich. Das ist toll und dabei sollte es auch bleiben. Hier ein entweder oder im sinne von entweder apps oder open data zu konstruieren, ist nicht zielführend und nicht in der absicht von MOGDY.

    • Einerseits muss ich Ihnen Recht geben. Der Titel dieses Vorschlages könnte um "statt APPS" gekürzt werden. Andererseits ist "statt APPS" eine Konzentration auf das Wesentliche mit einem großen Vertrauen in freie Entwickler, welches ich ausdrücklich teile. Open Governance heißt für mich eben auch, dass Zugriffe über offene Schnittstellen möglich sind. Für diese Schnittstellen muss die Stadt in Vorleistung gehen. Die Community kann nicht die Inhalte generieren, sehr wohl aber Apps und Websites.

      Meine Idealvorstellung ist, dass die Stadt einfache Schnittstellen bereitstellt und dann die Entwicklung von Open Source Lösungen anstößt und mit eigenen Programmierern voranbringt. Idealerweise profitiert davon nicht nur München, sondern auch andere Gemeinden, die diesen Weg mit einschlagen. Dann kann die Wiener Spielplatz-App auch in Berlin, Gröbenzell oder Kapstadt mit einer angepassten Serveradresse verwendet werden.

    • Stimmt - aber trotzdem gut darauf nochmal extra hinzuweisen.

      Naja, ich hab selbst in verschiedenen Gesprächen erlebt, dass Städte oft stark in Richtung eigene App Entwicklung denken. Das wäre aber meist nicht der optimale Weg...

      Insofern schadet es sicher nicht, dass dieser Punkt nochmal extra benannt wird.

      Wichtig wäre: Zuerst Schnittstellen/Daten/Informationen bereitstellen (für kommerzielle Nutzer gern auch gegen Kostenbeteiligung - warum nicht?) und die Marktentwicklung von APPs damit fördern. Wo der Markt mal einen wichtigen Bedarf nach einer App nicht erfüllt, könnte natürlich öffentlich stimuliert werden... (z.B. Wettbewerbe).

      Aber Du hast natürlich schon Recht: Interessant ist schon zu wissen, was alles für München gewünscht wird. Egal wer es dann liefert - sofern diese Idee mit beachtet wird.

  • rahelno ist dafür
    +2

    Sehr gute Idee. Auch andere Daten könnten dann von dritten (oder direkt) in OpenStreetmap integriert werden (wie das schon das genannte OpenWheelMap Projekt tut).

  • Nordwind ist dafür
    +2

    Kann die Stadt München z.B. langfristig die MVG motivieren, eine Readonly-API zu machen, mit der man von aussen auf dem Leitstellenrechner zugreifen und zu jedem Zeitpunkt den Standort aller U-Bahn-Züge abfragen kann?

    • es gibt den www.mvg-live.de Server, der Minutengau weiß, wann eine U-Bahn / Tram in den nächsten Bahnhof einfährt. Dazu gibt es auch eine API.

      Welchen UseCase hast Du? Dann kann ich Dir den Kontakt zur MVG herstellen...

      • einfach nur aus interesse: was kann die api (heute) alles?

        • Abruf der nächsten 10 Züge/Trams/Busse für eine der 1020 MVG Stationen in München mit Ankunftszeit der nächsten Verbindungen (Entspricht in etwa dem, was auf der Abfahrtstafel an einigen Haltestellen angezeigt wird, nur ganz aktuell und differenzierbarer).

          • ...gibt es zu den mvg-haltestellen aucvh die koordinaten dazu/bzw. irgendwo anders?

  • mathiasp ist dafür
    +1

    Wenn die Daten als Linked Data zur Verfügung stehen bin ich sehr dafür. Eine "API" lehne ich ab. Alles für die Interaktion notwendige steht mit RDF (und Ontologien) und http zur Verfügung.

  • dirk_s ist dafür
    +1

    Absolute Zustimmung: Bereitstellung von Daten und Informationen durch die Stadt - Entwicklung von Apps über freie Entwickler und Firmen. Sonst gibt es auch einen Interessenskonflikt für die Stadt:

    Eigene App pushen oder Drittentwickler unterstützen?

  • Ich hatte die Sache bisher so verstanden, dass genau das geplant sei.

    (die Apps sollen auf die freien API aufbauen)

  • dakoller ist dafür
    +1

    ...ich wüde noch LinkedData (RDF-Präsentation) dazuschreiben

  • friedrich ist dafür
    +1

    Die apps....

    ... will ja auch nicht die Stadt entwickeln, sondern nur rausfinden was Interesse findet und wo man also die Daten raus werfen muss! Vielleicht können sich aber hier schon ein paar Leute treffen, die an einer speziellen App-Idee interessiert sind und einen Beitrag für den MODGy-Wettbewerb (startet am 21/22 Januar) planen.

  • woba ist dafür
    +1

    Völlig einverstanden (bei meinem Vorschlag "Mietspiegel mobil (App)" bezog sich das "(App)" auch nicht auf die Geräte eines bestimmten Herstellers bzw. Betriebssystems (z.B. Apple oder Microsoft), sondern auf die Software-Kategorie "Kleines Helferlein für ein mobiles Endgerät".

    Eine Einschränkung auf eine bestimmte Gerätefamilie/ Betriebssystem/ Hersteller wäre auch völlig kontraproduktiv, da die Bürgerinnen und Bürger ja völlig unterschiedliche Geräte haben, aber der Nutzen alle Bürgern gleichermaßen zur Verfügung stehen müsste.

  1. Sie können einen Vorschlag unterstützen oder ablehnen.

  2. Und ihn in Ihre Beobachtungsliste aufnehmen.

  3. Informationen über den Vorschlag einsehen...

  4. ...Schlagworte für diesen Vorschlag hinzufügen...

  5. ...oder den Vorschlag mit anderen per Facebook, Google+ oder Twitter teilen.

  6. Kommentare können Sie nicht nur bewerten...

  7. ...sondern auch dazu verfasste Antworten einsehen...

  8. ...selbst eine Antwort zu einem Argument schreiben...

  9. ... und neue Argumente einbringen.

  10. Oder aktiv den Vorschlag mitgestalten und Alternativen einbringen.