Feedback und Input für Parkplatz-Digitalisierungs-App

Hallo liebe Menschen im OSM-Forum :slight_smile:

falls ich mich mit dem Folgenden irgendwie furchtbar vergreife tut mir dies leid. Ich habe in den Forumsregeln keinen Abschnitt dazu gefunden, und möchte direkt um Moderation bitten, falls ihr so etwas hier gar nicht haben wollt.

tl;dr: Ich bin Student, arbeite bei Bosch an einer App zum Loggen von Parkplätzen, die gesammelten Daten sind unter OSM-Lizenz verfügbar und ich brauche Feedback erfahrener Digitalisierer und potentieller Nutzer - also von euch. Wie muss eine App aussehen und gebaut sein, damit sie euch anspricht?

Die lange Version:
Ich:
Mein Name ist Paul Schweiger, ich studiere an der TU Darmstadt Psychologie in IT im Master und arbeite bei Bosch an einer App, für die ich dringend Feedback brauche.
Angefangen hat das ganze innerhalb der Forschung von Bosch mit einem Praktikum, in dem ich am Studentenprojekt “ParKing” mitgearbeitet habe. http://parking-app.de/ ParKing war recht erfolgreich, und Bosch hatte Interesse daran, das Projekt mit mehr Blick auf Business fortzuführen. Man hat jemanden gebraucht, der Ahnung vom Projekt hatte, und ich wurde ein “PreMaster-Student”, eine Art glorifizierter Praktikant. Die App musste inwzischen in “Parkineers” umbenannt werden, und wir haben sie professioneller entwickelt.
Inzwischen ist die App seit einiger Zeit verfügbar, aber hebt überhaupt nicht ab. Das liegt unter Anderem an meiner Unerfahrenheit, aber auch an der App selbst, unglücklichen Marketing-Versuchen, geringem Budget, und einigen weiteren Gründen. Ein großer Punkt ist aber, dass wir beim Entwicklungsprozess viel aus unserem Stübchen heraus gearbeitet haben, anstatt uns mehr auf den Kontakt zu (potentiellen) Nutzern und Experten zu konzentrieren. Deshalb bin ich hier.
Ich will dabei nicht unbedingt nur wissen, wie wir die App retten können, sondern auch für mich persönlich mitnehmen, woran wir hätten denken können und müssen, was alles vergessen wurde und was wichtig geworden wäre - ich schreibe also nur teilweise aus geschäftlichem Interesse, sondern auch weil ich denke, hier noch viel lernen zu können, was mir aktuell entgangen zu sein scheint.

Die App
Bei Parkineers geht es um das Loggen von Parkplatzrestriktionen. Wir wollen dabei die Information “Mo-Fr kann man hier tagsüber kostenpflichtig parken für 50ct/Stunde, nachts ist es Anwohnerparken und am Wochenende freies Parken für alle” und nicht um “Da vorne links ist ein Parkplatz frei geworden” digital darstellen.
Dass es nicht immer ganz leicht ist, solche Daten von Städten zu bekommen, brauche ich in diesem Forum vermutlich nicht zu erwähnen. Wir haben mit einigen gesprochen, und nur sehr wenige haben digitalisierte Parkrestriktionsinformationen - viele benutzen Tuschekarten oder haben tatsächlich gar keine Kartographierung der Parkbedingungen.

In der App selbst ist es - so hoffen wir - relativ leicht, komplexe Strukturen auf einzelnen Ways abzubilden. Die Daten können in Echtzeit eingesehen und zum Beispiel zur Reiseplanung verwendet werden: Wer Freunde in Stuttgart-West besuchen will und sich nicht gut auskennt, interessiert sich vielleicht dafür, wo es kostenlose Parkplätze im Chaos aus Anwohnerparkmöglichkeiten gibt, wer nur schnell etwas erledigen will braucht kein kostenloses Parken, sondern 2 Stunden mit Pakscheibe reichen vollkommen. Wir wollen den Nutzern ermöglichen, an der richtigen Stelle nach Parkplätzen zu suchen, um Zeit und Umweltbelastung einzusparen.
Diese Funktionalität ist unterlegt mit Gamification, um neben besonders ambitionierten Altruisten und Technik-affinen Personen auch einen Grundstock an “Casuals” von der App überzeugen zu können, bzw. um es den Hardlinern nebenbei auch ein bisschen zu versüßen. Das Loggen von Daten gibt Punkte, diese Punkte können in das Planen einer virtuellen Stadt investiert werden, man denke an Sim City auf der echten Stadtkarte. :smiley:

Wir benutzen dabei OSM Karten unter der OSM-Lizenz, wodurch auch unsere generierten Daten unter OSM-Lizenz stehen, was Absicht ist. Wir haben uns eingangs mit dem Vorhandensein von Parkinformationen in OSM beschäftigt, und gesehen, dass es durchaus Ansätze gab, sie zu digitalisieren, das aber nur vereinzelt bereits getan wurde. Nach dem Einlesen in einige Tutorials erschien es mir nicht unendlich trivial, reale Parkbedingungen per Markup in OSM einzubringen, vor Allem da dies keine Aufgabe für unterwegs ist. Die Idee ist deshalb, dass unsere auf OSM basierenden gesammelten Infos recht einfach zurückspielbar sein sollten, und Parkineers sich gut eignet, um den Prozess zu vereinfachen und die Daten für alle zugänglich zu machen.
Wenn es schon nennenswerte Daten gäbe, bzw. sobald es welche gibt, stehe ich gerne als eine Kommunikationsschnittstelle für den Import zur Verfügung. Ich kann aber leider schon anmelden, dass ich selbst nicht genug Ahnung und die Menschen mit wissen keine Zeit haben werden, um sich mehr als beratend und unterstützend einzuschalten.

Die App findet ihr hier: https://parkineers.com/ und unter “Parkineers” im App Store eures Vertrauens. [Außer ihr vertraut einem AppStore, der nicht der Apple App Store oder der Google Play Store ist. In diesem Fall findet ihr die App in einem Store, dem ihr nicht vertraut. :wink: ]

Da ich die Fragen “Was will Bosch mit den Daten?” und “Was will Bosch mit der App?” absehen kann, bekommt ihr die Antwort vorweg:
Bei Bosch denken viele Leute sofort an Waschmaschinen und Akkuschrauber, einige wenige noch an Autoteile und vermutlich kaum jemand an das Image das Bosch eigentlich haben möchte: Vernetzte, smarte Lösungen die das Leben erleichtern. Ich arbeite für eine Bosch-Gruppe, die “Connected Parking” heißt, und einige coole Sachen zu Parkraummanagement macht. Das ist im Wesentlichen aber auch wieder etwas, wo Kunden eher mit der finalen Lösung als mit der dahinter liegenden Technik in Kontakt kommen.
Parkineers ist als Möglichkeit gedacht, das Parkraummanagement im Kleinen und mit Beteiligung der Menschen ein wenig zu verbessern, und dabei aufzuzeigen, dass Bosch auch an anderen Themen arbeitet als “Wie wird das hier sauber?” und “Wie bekomme ich das da in die Wand?” :smiley:

Die Frage
Also, was ich nun wirklich von euch wissen möchte, ist:

  • was haltet ihr insgesamt vom Konzept der App? Macht das Sinn? Innerhalb und außerhalb des OSM-Kontextes
  • Was für Ansprüche hättet ihr an die Log-Funktion? Was ist unbedingt wichtig, und wie kann man es euch leichter machen?
  • Seid ihr Pro Gamification, oder würdet ihr eine puristische App bevorzugen, die sich nicht mit so etwas aufhält?
  • Könnt ihr euch vorstellen, dass jemand die App benutzen würde? Würdet ihr es selbst tun, würden eure Familien es tun?

Um einige Beispiele zu nennen. Um ehrlich zu sein sauge ich freudig sämtliches Feedback auf.

Danke!
Ich weiß, dass es bei OSM auch um Unabhängigkeit von äußeren Einflüssen z.B. durch Firmen geht, hoffe aber, dass ihr dennoch gewillt seid, mir in dieser Sache zu helfen - auch aus persönlichem Interesse. Ich weiß eure Arbeit als Community sehr zu schätzen, denn um ehrlich zu sein gäbe es Parkineers ohne OSM vermutlich nicht - Bosch nutzt ungerne Google-Karten. Und ich habe im Rahmen des Projektes selbst lernen können, wie mühselig die Verarbeitung von Geoinformationen sein kann, und wie viele Gedanken darin stecken.
Ich danke allen, die bis hier hin durhgehalten haben, und freue mich auf eure Meinungen und Antworten :slight_smile:

Parken würde ich eher unter einer Navigations-App suchen. Teilweise sind ja Informationen vorhanden, die direkt vor Ort erfasst sind. Auch die Zeit und Bedingungen lassen sich mit “Parkstreifen” recht genau abbilden.

Dem erfassen von Daten über eine APP - wie auch StreetComplete oder MapsMe - sehe ich kritisch, da dort vielleicht Eintragungen in die Daten kommen wie " Hier ist kein Parkplatz" oder “unbekannte Nutzungsart”. Das ist m.E. sinnlos.

Aber das wirst du ja sicher alles im WIKI gesehen haben. Die App habe ich bis jetzt nicht angesehen.

Ich tu’ mich schwer mit Gamification und auch hier wurde ich bestätigt.
Installiert, gestartet, angemeldet, erste Parksituation eingetragen. Dann sollte ich “einen Sektor kaufen”. Da tat sich aber nichts, egal wo ich hingetappt habe.
Ergebnis: Drei Minuten nach der Installation wieder deinstalliert.

Wenn ich SimCity spielen will, dann installiere ich SimCity.

“Release early. Release often. And listen to your customers.”

Sind eh nur alles Zwischenlösungen, bis SmartParking Systeme (wie z.b. http://park-here.eu) ausgereift sind, San Francisco hat’s ja schon einmal vorgemacht, auch wenn der erste Versuch gescheitert ist.

Muss den anderen zustimmen, für die Parkplatzsuche nehme ich die Naviapp, ansonsten ist ein Parkleitsystem oder Schilder vor Ort meistens am hilfreichsten.

Die Parkplätze in OSM sind sehr oft private Parkplätze.

Eine Nische kann deshalb nur sein, wenn die App viele Detailinformationen zu den Parkplätzen hätte.
Die sind aber zum Teil noch nicht in OSM und müssten auch durch die App erst in OSM einfliesen bevor ein richtiger Nutzen entstehen könnte.
Andere Daten wie freie Parkplätze sind aktuell wohl nur sehr schwer zu bekommen… usw.

Bei vielen gibt es eine Website, mit Informationen - Beispiel Dresden - die in den Daten sein sollte:
http://www.openstreetmap.org/way/482285132#map=18/51.05284/13.71934
http://www.openstreetmap.org/way/16187010#map=17/51.04395/13.73361

Hallo ihr alle,

danke für das Feedback und die Diskussion so weit :slight_smile:

Ich habe mehrfach gelesen, dass ihr diese Funktionalität eher in einer der bekannten Navigations-Apps verwenden und suchen würdet, und weniger in einer weiteren App auf dem Handy - was ich verstehen kann, und was auch ein Punkt ist, den wir bedacht haben. In der aktuellen Version gibt es die Möglichkeit, eine Parkmöglichkeit zu betrachten und die GPS-Koordinaten direkt in der Standard Navi-App des Gerätes zu öffnen - man kann ich in Parkineers informieren und die Navigation dann andernorts durchführen.
Meines Wissens gibt es viele Infos zu offiziellen Parkplätzen und -häusern in existierenden Navis, aber weniger zu On-Street-Parkplätzen, was der Fokus unserer Anwendung ist.

Meinst du damit die Gefahr, dass absichtlich Falschangaben gemacht werden, oder meinst du den Fall, dass bei einem Import in die OSM-Daten jegliche Lücken im App-Datensatz nicht eindeutig interpretiert werden können, und Lücken so zu eventuell fehlgedeuteten Daten führen?

Schritt 1 ist gelaufen, Schritt 2 organisatorisch schwer, aber zumindest an Schritt 3 bin ich hier und andernorts dran. :smiley:

Großartig, das ist mir nun natürlich peinlich :smiley:
Darf ich dein Gerät und die Betiebssystemversion erfragen? Wir wissen von diesem Bug innerhalb der kommenden iOS-Beta, aber mehr Details helfen beim Eingrenzen.
Deine Grundhaltung gegenüber Gamification kann ich hier natürlich nicht ändern - es ist absolut nicht jedermanns Sache, und oftmals auch nicht perfekt umgesetzt, was ich in unserem Fall nicht ausschließen möchte. Unter diesem Blickwinkel will ich noch Mal besonders für den Download der App danken! Du hast ihr eine Chance gegeben :slight_smile:
Unter dem Blickpunkt, dass das Entfernen aller Gamification-Elemente keine Option ist: Wie könnten wir sie auf eine Art einbetten, die dich nicht stört, es zugleich aber Anderen ermöglicht, weiterhin schnell Zugang zu finden?

@R0bst3r: An den Detailinformationen zu Parkplätzen wollen wir ja eben arbeiten :slight_smile:
Wie oben schon beschrieben geht es uns dabei aber nicht wie in geri-ocs Links um richtige Parkplätze, sondern eher um Parkmöglichkeiten am Straßenrand - und die sind glaube ich häufig nicht abgebildet.

Ja klar. Samsung Galaxy S7 (SM-G390F), Android 7.0, kein root.

Das sie nicht abgebildet werden ist aber kein Datenproblem. Das wäre z.B. so ein Fall:
http://www.openstreetmap.org/way/469714508

EDIT: Beispiel für links Parken: http://overpass-turbo.eu/s/y6z

Wie soll dort die Erfassung mit der APP erfolgen - https://wiki.openstreetmap.org/wiki/DE:Key:parking:lane?

Nicht absichtlich, aber wenn z.B. an einer Straße keine Parkplätze sind, braucht auch nicht eingetragen werden “Keine Parkplätze”.

MapsMe oder Streetcomplete machen auch solche Abfragen. Dann wird z.B. ein Notes an einer Garage erstellt: “Dieses Haus hat keine Addresse” oder “cycleway:both=no” an einem hw.

Wer Daten in OpenStreetMap beitragen möchte kann dies über Editoren machen. Durch externe Importe (Wheelmap, Streetcomplete, …) wird schnell zu Fehlern verleitet, da dort nur geringe Auswahlmöglichkeiten mit ja/nein beantwortet werden, ohne sich um Schlüssel und Werte zu kümmern.

Ich wusste, dass es durchaus vorhandene Parkinformationen auf Straßenabschnitten in OSM gibt, allerdings sind diese nicht flächendeckend.
In der App haben wir die Möglichkeit, zwischen Parkplätzen auf der linken und rechten Straßenseite zu unterscheiden, oder gleiche Daten für beide Seiten einzugeben. Man wählt einen Way, kann dann eine Richtung (und damit die Straßenseite) oder beide Richtungen wählen, und die entsprechende Parkbedingung abbilden.

Ich glaube, ich verstehe jetzt, was dein Punkt ist, und muss dir da Recht geben:
Unsere ursprüngliche Idee war es, dass ein Rückspielen der Daten in OSM eine allseits willkommene Möglichkeit ist, schnell mehr Daten zu bekommen. Je mehr ich aber hier und im Wiki über Importe lese, desto mehr wird mir bewusst, dass meine Einschätzung als Außenstehender, man würde sich über jede Form von Daten freuen, wenn sie halbwegs korrekt sind, so einfach nicht stimmt. Wichtig für euch und OSM als Ganzes sind qualitative Informationen, und keine Büchse der Pandora, in der sich irgendwie plausible, aber schlecht prüfbare Daten befinden. Auch weil unsere App einige Keys nicht abbildet, die in der Park-Datenstruktur aber wichtig sind: wir haben die Ausrichtung der Parkplätze (senkrecht/entlang der Straße) zum Beispiel entfernt, und auch die genaue Anzahl der Parkplätze.

Dürfte ich fragen, wie denn der Arbeitsprozess aussehen würde, wenn jemand wirklich direkt in OSM die Straßenparkplätze in seiner Gegend digitalisieren wollen würde? Hätte die App vielleicht Platz als Tool zum Mitschreiben, um die neuen Erkenntnisse zu Hause dann per Hand und korrekt in OSM einzupflegen? Oder macht man das auch direkt unterwegs?

Danke für die Diskussion, geri-oc :slight_smile:

Danke sehr :slight_smile:

APP: Anzeige vorhandener Parkplätze in OSM - (auch lanes) und Erfassungs mit gps, vorgefundenen Bedingungen (Foto?) und dann mit JOSM (und Vorlage parking_lane und Parkplätze) eintragen (allerdings auch wichtig: Halteverbot, Parkverbot):

  1. wird angezeigt, ob die Daten eventuell vorhanden sind → korrigieren und ergänzen
  2. wenn nicht vorhanden → neue Daten einfügen
  3. Validator zeigt eventuell einige Fehler an - eventuell korrigieren - zumindest, wenn es eigene Fehler sind
  4. Hochladen

Dann müsste die APP z.B. in der Lage sein, die Straße entsprechend der Bedingungen zu teilen, ohne Relationen oder Schlüssel zu zerstören. M.E aber nicht: “An der Straße gibt es keine Parkplätze”.

Das ist aber wieder ein Anzeigeproblem. Ich finde aber auch (günstige) Parkplätze in anderen Gegenden - genau so wie ich solche auch hier eintrage.
Wichtig fände ich einen Schlüssel “nicht ausgewiesener Parklatz”, da an manchen das blaue “P” nicht ausgewiesen wird.

Durch das neue Rendering in der OSM Carto könnte der Schlüssel amenity=parking_space einen neuen Aufwind erfahren. Der Schlüssel kann auch sehr gut genutzt werden, um freie kurze Parkstreifen an den Straßenrändern, sogar als Fläche, zu kennzeichnen. Wenn diese Flächen auch etwas länger sind, aber nicht unbedingt markiert (…ich trage auch 5-10 Meter Parkstreifen als amenity=parking_space ein), so gibt es gerade für Kurzparker, LKW, Techniker und Anlieferer dann eine wesentlich bessere Auswahl an Parkmöglichkeiten. Hier mal eine Abfrage. Diese könnte wesentlich umfangreicher ausfallen, nur gab es bislang kein Rendering, das dann durch Ignoranz oder der (vielleichten) Eintragung der abstrakten Version der Parkmöglichkeiten durch den Mapper erfasst wurde oder oft nicht.

P.S. Allerdings würde das amenity=parking_space an Strassenrändern optimal an das a:h Taggingschema passen, was ja leider in der letzten Zeit kaum noch diskutiert wird. Beispiel

M.E. ist amenity=parking_space eine Stellfläche. Ein Parkplatz der aus mehreren Stellflächen besteht ist amenity=parking. Wenn es einzelne “Stellflächen” sind (Eltern, Rollstuhl, …) würde ich sie auch als amenity=parking_space erstellen. Wobei ich mehrere dann schon wieder als amenity=parking mit capacity=* sehe

Vor einiger Zeit wurde kritisiert solche Parkstreifen als amenity=parking einzutragen, da es dafür parking_lane gibt. Warum jetzt amenity=parking_space dafür verwenden?

Im Flächenmapping würde ich es eventuell (amenity gefällt mir hier weniger) verwenden: https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area

Das Wiki sieht das genauso:

Ich dachte erst ihr hättet mich verloren :smiley:
Inhaltlich kann ich euch aber sogar noch folgen, nur sind wir fern ab dessen, was die App bieten kann und soll - ich habe aber einen Einblick bekommen, warum die Kartografierung von Parkplätzen wirklich nicht leicht ist, und warum das mit dem Import wohl nichts werden wird - danke dafür! :slight_smile:

Ich werde einen Teufel tun und unterschiedlich in der Parklänge an Seitenstreifen (unterbrochen z.B. durch Bäume), diese als amenity=parking taggen. Dies ist allenfalls markierbar durch z.B. parking:lane:both=marked, aber nur grob und abstrakt.
Nur die Fläche kann natürlich gemappt werden, aber nicht als Parkplatz, da ja ein LKW eine andere Fläche braucht als ein Smart, sondern als amenity=parking_space. Das ist natürlich auch als Parkplatzraum im a:h tagging vorgesehen.

Ich muss deiner Einsicht zustimmen. Einfach wären offizielle Parkplätze, egal mit welchen zeitlichen Einschränkungen oder gebührenpflichtige. Selbst dies wird in OSM nur sehr zögernd umgesetzt. Schwierig wird es schon mit meinem fast ländlichen Beispiel. Hier sind abstraktes Tagging und moderne, aber nicht anerkannte Formen kombiniert.
Ganz schwierig wird es im urbanen Raum, wo es entlang den Wohnstraßen immer Parkmöglichkeiten gibt, allerdings meißt gebührenpflichtig oder Anwohnerparkplätze sind. Diese Kombination kann auch sehr vielfältig varriiert werden und ist kaum ohne Flächentagging zu erfassen.
Ich als Techniker in der Stadt Köln unterwegs kann ein Lied davon singen, aber man findet meißtens eine “Nische” - dann gebührenpflichtig.

Wie gesagt das amenity=parking_space halte ich fürs Flächentagging falsch, dort sollte area:highway=parking_space besser passen. So gibt es für unterschiedliche Anwendungen einen Schlüssel.

Das lässt sich besser durch parking _lane=* lösen, dann brauchen auch keine “Bäume weichen”.

parking:lane:both=marked sollte aber präzisiert werden. Auch wenn fee=no …
parking:lane:hgv=on_street ?