Es gibt immer mehr lokale Initiativen und Gruppen, die mit dem OBS aktiv sind.
Wollen wir diese auf einer Seite/Karte darzustellen, damit Interessierte niederschwelliger Ansprechpartner in der Nähe finden können (wenn sie möchten)? MIt Projektseite (wenn vorhanden bei ADFC o.ä.), Direktlink zum Forum, Kontaktmöglichkeit…
Der Vorschlag kam von Sophie 
Die Idee hatte ich auch schon Mal für unsere Webseite. Eine Deutschland-Karte mit Punkten auf Orte/Regionen, wo OBSen unterwegs sind - mit Kontakten zu Gruppen, Initiativen oder Personen.
Das klingt für mich sehr gut. Bin dafür 
Da es keine negativen Anmerkungen gab, würde ich mich um das Projekt gerne kümmern wollen.
Beim Radentscheid Essen haben wir mit umap gearbeitet. Spricht etwas dagegen umap auch für die OBS zu verwenden? Und auf welche Art und Weise können die Daten der Initiativen gespeichert werden?
Hallo Sophie,
die Webseite wird mit Hugo gebaut, d.h. wir sollten ein Map-Plugin verwenden, welches mit Hugo kompatibel ist. Ich denke, dass dann das Plugin das Datenformat vorgibt. Es wird sicher eine statische Datei (JSON, CSV) sein, da Hugo am Ende auch nur eine statische Seiten generiert.
Das hier ist das Repository, welches unserer Webseite abbildet:
Mache gerne Vorschläge, gerne gleich als Pull Request. Wir freuen uns über jeden Beitrag aus der Community.
Hallo @Sophie,
ich find’s toll, wenn du da was machst. Du kannst dann gerne den Landkreis Darmstadt-Dieburg einschließlich der Stadt Darmstadt als „OBS besetztes Gebiet“ mit aktuell 23 Sensoren einfärben.
Sollen da Gruppen drauf, die den Sensor bauen oder generell Menschen, die damit fahren. Letzteres wäre möglicherweise für Menschen interessant, die aus dem Bereich kommen und sich das mal persönlich anschauen möchten oder jemanden suchen.
Na ja, wenn man mit Karten arbeitet, ließe sich das ja unterschiedlich einfärben, oder in unterschiedliche Layer packen. Wir haben das mal für eine Kampagne gemacht, k.A. mit welchem Tool.
Ich weiß allerdings nicht, was umap oder andere Tools da leisten.
Mit umap geht ne ganze Menge. Einfärben, verschiedene Symbole, Infofensterchen, verschiedene Ebenen. 
Mir wäre umap ehrlich gesagt auch lieber, weil ich das Tool schon kenne. Ich weiß allerdings nicht, wie sich das so einfach in die statische OBS-Homepage einbinden lässt. Das bekomme ich aber noch raus.
In der Zwischenzeit kann gerne eine Person eine Tabelle aufsetzen. Gerne auch mit 2 Tabellenblättern für die beiden unterschiedlichen Inhalte (Initiative und Anzahl der Fahrer*innen in den Städten). Ich würde es auch machen, wenn ich wüsste, welches Kollaborations-Office-Tool gewünscht ist.
Ich weiß nicht, ob das jetzt ein offizielles Tool ist, aber es ist zumindest in einem „Termine“ Post verlinkt und man kann sich da mit dem OpenBikeSensor-Zugang einloggen:
Keine Ahnung, ob das passt, ich hab mal ne MD Notiz erstellt. Da packe ich auch rein, was man technisch braucht, um das in die Webseite einzubinden.
Ich halte es für sinnvoll, die Daten, die angezeigt werden sollen, als JSON oder so ins Repo zu legen – dann ist eine Erweiterung („ich möchte in die Karte aufgenommen werden“) genau wie eine inhaltliche Erweiterung der Website abzuhandeln und es muss nicht immer eine Person die halt irgendwo einen Account hat angestupst werden. Statisches JSON laden und mit JS auf einer Karte anzuzeigen ist nicht so schwer, leaflet oder openlayers oder maplibre-gl kommen dafür auch in Frage – außer natürlich uMap kann aus einer externen Quelle (also von einer URL) Daten laden, das wäre sicher noch einfacher.
Wenn die json im Repo liegen würde, wäre das dann nicht schwierig wegen Datenschutz, falls sich nach x Zeit jemand entscheiden würde, dort nicht mehr gelistet werden zu wollen? Der ist ja dann für immer in der git History drin.
Ne json-Datei kann ich gerne zur Verfügung stellen. Ich stimme @natenom aber zu, was die Ablage der Datei im repository angeht. Bei umap gäbe es die Möglichkeit, dass mehrere Bearbeiter Änderungen durchführen können. Bei ner json ist mein Verständnis, dass immer nur einzelne die Änderungen durchführen können. Das halte ich für unpraktischer.
Wenn es aber heißt: wir arbeiten mit dem repository, dann versuche ich mich damit anfreunden und einarbeiten.
Es ist genau umgekehrt, das Repository können alle gemeinsam bearbeiten (via git), es ist dann wie Quelltext, öffentlich und forkbar, unter offener Lizenz. Ein System wie umap wäre immer irgendwie versteckt, und wenn die Admins nicht mehr erreichbar sind kann niemand mehr damit etwas anfangen. Das ist eine Art von „Bus-Faktor“. Außerdem erfordet so ein Service noch mehr Accounts, und wer mitmachen möchte muss den AGB zustimmen und seine:ihre Daten diesem Service anvertrauen.
Das Problem mit der git-Historie stimmt, halte ich aber für irrelevant. Was einmal im Internet ist, ist für immer öffentlich – wer also zustimmt, dass seine:ihre Daten in der Website landen, muss sich bewusst sein, dass es kein Zurück gibt. So oder so, ob das über git läuft oder irgendwie anders veröffentlicht wird, am Ende landet es eh alles im Archiv
Mit der Pflege der Daten im Repository finde ich, dass wir es uns einfacher machen. Wir haben bereits die Prozesse, um diese Daten gemeinschaftlich zu pflegen. Und noch dazu haben wir mehr Kontrolle darüber, als wenn wir uns in die Abhängigkeit eines Dritten Diensteanbieters begeben. Darum bin ich stark dafür, das ohne solche Dienste zu lösen, sofern irgendwie möglich.
Alles klar, dann gehe ich von einer json Datei aus, sofern ich nichts weiter gegenteiliges lese.
Für mich wäre nur noch die Frage offen, wie man die anderen Initiativen dazu bringt, sich in die Liste von natenom einzutragen.
Das mit „einmal im Netz, immer im Netz“ ist richtig. Da wären dann aber noch Datenschutzbestimmungen, an die man dann als Webseitenbetreiber aber halten müsste, falls jemand da aktuell nicht mehr angezeigt werden möchte.
Von der Webseite würde das natürlich dann auf Anfrage verschwinden, wäre aber weiterhin übers „Archiv“ verfügbar, welches auf der Webseite verlinkt ist. Schwierig.
uMap könnte Daten per overpass aus OSM holen oder importieren (auch von URL):
GeojSON
Alle Merkmale wurden importiert.
GPX
Importierte Merkmale:name, desc
KML
Importierte Merkmale:name, description
CSV
Komma-, tabulator-, oder semikolongetrennte Werte. SRS WGS84 ist impliziert. Nur Punktgeometrien werden importiert. Beim Import wird nach Spaltenüberschriften mit jeder Nennung von „lat“ und „lon“ am Anfang der Überschrift gesucht (ohne Beachtung von Groß-/Kleinschreibung). Alle anderen Spalten werden als Merkmale importiert.
uMap
Importiert alle uMap-Daten inklusive Ebenen und Einstellungen
und als Layer darstellen (mit eigenen styles).
Die Karte könnte dann als iframe eingebettet werden.
Bearbeitung geht über Admin-Link.
Sinnvoller fände ich, wenn die Nutzer:innen sich optional selbst eintragen könnten über das Portal ähnlich wie bei wechange.de/map/. Möglichst einfach, dort sind sie eh schon (nur schwierig bei mehreren Instanzen…). Die Lokalgruppen dann separat verwalten oder auch im Portal. Auf WE gibt es dafür „Projekte“ und „Gruppen“ (übergeordnet, können mehrere Projekte zusammenfassen).
Wie am Montag beim Community-Treffen besprochen, habe ich mal einen ersten sehr groben Entwurf für die Initiativen-Karte gemacht. In Ermangelung von Initiativen und deren Kontaktmöglichkeiten habe ich mich auf das Ruhrgebiet beschränlt, Ziel sollte natürlich sein, ganz Deutschland mit Initiativen zu füllen. Über die Inhalte wollen wir ja nochmal gesondert diskutieren.
Schaut gerne schon mal drauf: OpenBikeSensor-Initiativen - uMap