Zusammenfassung von Topics via KI-Sprachmodell

toc-rox · January 25, 2025, 3:43pm

Zusammenfassung Google Gemini 1.5

Die Diskussion im deutschsprachigen OpenStreetMap-Forum dreht sich um die korrekte Verwendung des Tags bicycle=designated bei der Kartierung von Radverkehrsanlagen. Ausgelöst wurde sie durch eine Änderung auf der deutschen OSM-Wiki-Seite zur Kartierung von Radverkehrsanlagen, bei der bicycle=designated für baulich erkennbare, aber nicht beschilderte Radwege durch bicycle=yes ersetzt wurde.

Hauptfrage: Wann ist der Tag bicycle=designated für einen Radweg anzuwenden?

Der Thread entwickelt sich zu einer ausführlichen Debatte über die Interpretation der deutschen Straßenverkehrsordnung (StVO) im Bezug auf Radwege mit und ohne Benutzungspflicht, sowie die korrekte OSM-Kartierung dieser. Es werden verschiedene Szenarien diskutiert:

Radwege mit blauer Beschilderung (Benutzungspflicht): Hier herrscht weitgehend Einigkeit über die Verwendung von bicycle=designated.
Radwege ohne blaue Beschilderung (keine Benutzungspflicht): Hier entzündet sich die Hauptdiskussion. Einige Mapper plädieren für bicycle=designated, da der Weg explizit für Radfahrer vorgesehen ist, auch wenn die Benutzung nicht verpflichtend ist. Sie argumentieren, dass die StVO verschiedene Möglichkeiten der Kennzeichnung (Zusatzschilder, Piktogramme, bauliche Gestaltung) zulässt, die alle eine Widmung des Weges für den Radverkehr darstellen. Dieser Standpunkt wird durch Verweise auf die deutsche StVO und diverse Interpretationen derselben von Rechtsexperten untermauert.
Gehwege mit Zusatzschild “Radfahrer frei”: Hier besteht Einigkeit über die Verwendung von foot=designated und bicycle=yes, da Radfahrer nur geduldet sind und Schrittgeschwindigkeit fahren müssen.
Unbeschilderte Wege: Die Einordnung dieser Wege ist besonders schwierig. Vorschläge reichen von highway=path ohne Access-Tags bis zur Verwendung von bicycle=permissive (obwohl dies als Missbrauch des Tags angesehen wird).
Nicht getrennt gemappte Wege (cycleway=track): Die Darstellung der Benutzungspflicht bei dieser Mapping-Methode stellt ein besonderes Problem dar. Die Verwendung von bicycle=use_sidepath wird diskutiert, jedoch ist ihre Anwendbarkeit auf nicht separat gemappte Wege umstritten.

Zusammenfassend gibt es drei Hauptinterpretationen von bicycle=designated:

Alle Radwege sind designated: Dieser Ansatz betont die Widmung des Weges für Radfahrer, unabhängig von der Benutzungspflicht. Die Unterscheidung zwischen Schritt- und Vollgeschwindigkeit würde durch zusätzliche Tags (z.B. maxspeed:bicycle=walk) erfolgen.
Nur blau beschilderte Radwege sind designated: Dieser Ansatz ist einfach und entspricht der bisherigen Praxis vieler Mapper (Lübecker Modell). Die Benutzungspflicht ist an den blauen Schildern erkennbar.
Nur benutzungspflichtige Radwege sind designated: Dieser Ansatz folgt der wörtlichen Interpretation von “designated” im englischen Wiki, jedoch führt er bei nicht getrennt gemappten Wegen zu Problemen bei der Darstellung der Benutzungspflicht.

Die Diskussion endet ohne endgültigen Konsens. Die Teilnehmer diskutieren die Vor- und Nachteile der verschiedenen Interpretationen von bicycle=designated im Kontext der deutschen StVO, der internationalen OSM-Standards und der Funktionalität von Routing-Software. Es wird vorgeschlagen, die Tagging-Varianten zu konkretisieren und im OSM-Wiki zur Abstimmung vorzulegen, jedoch wird der hohe Aufwand hierfür und die fehlende Erfolgsaussicht in Betracht gezogen. Ein Meinungsbild im Community Chat wird als Alternative in Erwägung gezogen. Die Problematik der unvollständigen und inkonsistenten Datenlage in OSM wird immer wieder hervorgehoben. Die Frage, wie die Benutzungspflicht von Radwegen, die nicht separat von der Straße erfasst sind, dargestellt werden soll, bleibt ungelöst.

Zusammenfassung Google Gemini 2.0

Thema: Radverkehrsanlagen kartieren: Wann setzt man bicycle=designated?

Metadaten:

Titel: Radverkehrsanlagen kartieren: Wann setzt man bicycle=designated?
Erstellt von: aixbrick
Erstellungsdatum: 2022-09-03
Anzahl der Beiträge: 242
Letzter Beitrag: 2022-09-22

Kernfrage:

Die Diskussion entzündete sich an einer Änderung auf der deutschen OpenStreetMap Wiki-Seite zur Kartierung von Radverkehrsanlagen. Dort wurde die Verwendung von bicycle=designated für baulich erkennbare, aber nicht beschilderte Radwege zu bicycle=yes geändert. Das führte zu einer umfangreichen Debatte darüber, wann bicycle=designated korrekt anzuwenden ist und welche Implikationen diese Wahl für das Routing und die Abbildung der Realität hat.

Hauptdiskussionspunkte und Argumente:

Bedeutung von bicycle=designated:
- Definition: Die Diskussion drehte sich darum, ob bicycle=designated bedeutet, dass ein Weg explizit für den Radverkehr vorgesehen ist (unabhängig von einer Benutzungspflicht) oder ob es eine Benutzungspflicht impliziert (z.B. im Sinne einer Radwegpflicht).
- Unterschied zu bicycle=yes: Es wurde der Unterschied zwischen einem Weg, auf dem Radfahren nur erlaubt (bicycle=yes) ist und einem Weg, der explizit für Radfahrer gedacht ist (bicycle=designated), diskutiert. Hierbei wurde festgestellt, dass Fußwege mit „Radfahrer frei“ eher zu der ersten Kategorie gehören.
- Internationale vs. Deutsche Interpretation: Die Diskussionsteilnehmer stellten fest, dass die internationale Bedeutung von designated in Bezug auf Radwege nicht immer mit der deutschen Rechtslage übereinstimmt. In Deutschland gibt es die Besonderheit der “sonstigen Radwege” ohne explizite Beschilderung.
“Sonstige Radwege” und ihre Erkennbarkeit:
- Problem: In Deutschland existieren Radwege, die keine blaue Beschilderung aufweisen, aber dennoch durch bauliche Merkmale (z.B. rote Pflasterung, Radfurten) oder Piktogramme auf dem Boden als solche erkennbar sind. Die Frage war, ob diese auch als bicycle=designated zu taggen sind.
- Indizien: Es wurden verschiedene Indizien diskutiert, die auf einen “sonstigen Radweg” hindeuten, darunter Piktogramme, Radfurten und die farbliche/bauliche Trennung von Geh- und Radweg.
Benutzungspflicht und bicycle=use_sidepath:
- Getrennte Erfassung: Die Diskussion beleuchtete das Problem, die Benutzungspflicht bei Radwegen an Straßen zu taggen, wenn der Radweg nicht separat erfasst wurde. Hierfür wird bicycle=use_sidepath aktuell in der Praxis und im Wiki nur bei separat erfassten Radwegen an den Hauptweg geschrieben.
- Routing-Implikationen: Es wurde diskutiert, wie Router auf bicycle=use_sidepath reagieren sollten. Router ignorieren aktuell den Zusatz, wenn der Radweg direkt an der Straße liegt, was zum Teil zur Diskussion geführt hat. Die Frage ist nun, ob Router auch diese Radwege mit b=use_sidepath oder optional_sidepath berücksichtigen sollten.
- Alternative Tagging: Es wurden alternative Tags wie z.B. cycleway:right:compulsory=yes/no oder das cycleway:track:traffic_sign=DE:237/DE:240/DE:241 diskutiert, um die Benutzungspflicht zu kennzeichnen.
- Es wurde auch die Frage aufgeworfen, ob das Tag bicycle=official wiederbelebt werden sollte.
Auswirkungen auf das Routing:
- Präferenz: Eine zentrale Frage war, wie Router die Informationen von bicycle=designated und bicycle=yes interpretieren sollten. Sollte ein Radweg mit bicycle=designated gegenüber einem mit bicycle=yes bevorzugt werden oder nicht?
- Flexibilität: Es wurde betont, dass ein Router eine Option bieten sollte, die es den Benutzern ermöglicht, selbst zu entscheiden, ob sie lieber auf der Straße oder einem Radweg fahren möchten.
- Berücksichtigung von Faktoren: Einigkeit herrschte, dass Router mehr Eigenschaften als nur die Tags bicycle=* berücksichtigen sollten wie z.B. surface, smoothness, width, segregated.
Umgang mit “Fehlbeschilderung”:
- Zusatzzeichen: Die Diskussionsteilnehmer wiesen darauf hin, dass Zusatzzeichen wie “Radfahrer frei” oft nicht korrekt verwendet werden, z.B. ohne Hauptschild oder auch auf der rechten Seite. Hier wurde überlegt, wie man damit umgehen sollte.
- Ungültige Schilder: Einige sprachen sich dafür aus, “Fehlbeschilderungen” als solche zu erfassen, d.h. nicht automatisch anzunehmen, dass ein Zusatzschild ohne Hauptschild ein Radweg ist.
Die Rolle der OpenStreetMap-Wiki:
- Inkonsistenzen: Es wurde bemängelt, dass die Wiki-Seite zur Radverkehrsanlagen-Kartierung inkonsistent war und nicht immer mit der aktuellen Rechtslage oder der Praxis übereinstimmte.
- Konsensfindung: Es wurde ein Bedarf an einer konsistenten Definition und an Konsens bei den Mapping-Richtlinien festgestellt. Dazu wurde die Frage aufgeworfen, ob man dies mit einer formellen Abstimmung im Wiki angehen sollte.

Zusammenfassende Positionen:

bicycle=designated für alle Radwege: Eine Position war, bicycle=designated für alle Radwege zu verwenden, die als solche erkennbar sind (egal ob mit oder ohne Schild) und nur für freigegebene Gehwege (bicycle=yes) zu verwenden, weil die ja eine andere Rechtsgrundlage haben. Sie argumentierten, dass dies die rechtliche Realität in Deutschland besser abbildet.
bicycle=designated nur für beschilderte Radwege: Eine andere Position war, die Anwendung von bicycle=designated nur auf blau beschilderte Radwege zu beschränken. Es wurde argumentiert, dass diese Vorgehensweise einfacher sei und dem internationalen Gebrauch von designated entsprechen würde.
Trennung von Wegtyp und Benutzungspflicht: Es wurde die Notwendigkeit betont, die Kennzeichnung des Wegtyps (highway=cycleway/path) und der Benutzungspflicht (mit bicycle=use_sidepath oder einem neuen Tag) separat zu betrachten.
Datenqualität vor Details: Einige Teilnehmende betonten, dass die Datenqualität (insbesondere die Erfassung von Radwegen) vor der Diskussion von Detailfragen verbessert werden sollte.
Keine Sonderrolle für Deutschland: Eine Position war, dass wir keine “deutsche Sonderlösung” anstreben sollten.

Ergebnis und Ausblick:

Die Diskussion brachte keine abschließende Einigung über die korrekte Verwendung von bicycle=designated. Die Teilnehmenden waren sich jedoch einig, dass die bestehenden Wiki-Seiten inkonsistent sind und eine bessere Dokumentation sowie die Entwicklung einer konsistenten Tagging-Methode erforderlich ist.

Es wurde deutlich, dass es nicht nur darum geht, wie ein Tag verwendet wird, sondern auch, wie die Informationen in der Realität interpretiert werden und welche Auswirkungen dies auf das Routing hat.

Am Ende kristallisierten sich drei Positionen heraus:

Radwege werden allgemein als bicycle=designated erfasst.
Nur mit Verkehrszeichen beschilderte Radwege sind bicycle=designated, alle anderen werden mit bicycle=yes erfasst.
Nur die Radwege, bei denen eine Benutzungspflicht über die Radverkehrsanlage herrscht, sind bicycle=designated, alle anderen mit bicycle=yes.

Es wurde beschlossen, die Diskussion und die Optionen formal im Wiki festzuhalten, um später eine Abstimmung durchführen zu können. Zudem wurde vorgeschlagen, die Ergebnisse der Diskussion in einer Umfrage im neuen Community-Chat zu erheben.

@Langlaeufer: Vielleicht kannst du beide Zusammenfassungen mal bewerten.

Langlaeufer · January 25, 2025, 3:55pm

Bin dann doch von der Qualität beider Zusammenfassungen sehr positiv überrascht. Das könnte daran liegen, dass bereits ein paar User-generierte zwischen-zusammenfassungen im Faden enthalten sind.

Inhaltlich finde ich hier - im Gegensatz zur Zusammenfassung von ChatGPT 4o - beides überzeugend . Die Zusammenfassung von Gemeni 2.0 finde ich eher schon zu lang - aber das ließe sich ja sicherlich noch per Prompt steuern.

Langlaeufer · January 25, 2025, 4:34pm

siehe letzte Beiträge, da wurde das erklärt

Langlaeufer · January 25, 2025, 4:38pm

Mast du es auch mal mit einem engl. Thread versuchen?

Die Zusammenfassungen die ich Gemeni abgerungen haben überzeugen mich nicht so sehr. wobei 1.5 noch besser abgeschlossen hat als 2.0

OSM_RogerWilco · January 25, 2025, 5:08pm

Werden dabei eigentlich auch Reaktionen auf die Beiträge mit ausgewertet?

toc-rox · January 25, 2025, 5:12pm

Ich kann es mal versuchen. In welcher Sprache soll die Zusammenfassung erstellt werden?

Langlaeufer · January 25, 2025, 5:21pm

Ich hatte es auf deutsch versucht. Mach einfach mal mit dem gleichen prompt wie zuvor.

toc-rox · January 25, 2025, 5:23pm

Ob und wie das KI-Sprachmodell die Reaktionen (+1, -1, …) auswertet, weiß ich natürlich nicht. Ich halte sie für wichtig, weshalb sie auch explizit an das Sprachmodell übergeben werden. Siehe hierzu auch Post #9. Vermutlich läßt sich die Gewichtung auch noch über den (Abfrage-) Prompt beeinflussen.

toc-rox · January 25, 2025, 5:37pm

Zusammenfassung mit Google Gemini 2.0

Metadaten des Themas:

Titel: “[RFC] Feature Proposal - One-way for pedestrians”
Ersteller: osmuser63783
Erstellungsdatum: 2024-09-01
Anzahl der Beiträge: 216
Letzter Beitrag: 2025-01-24

Zusammenfassung der Diskussion:

Die Diskussion dreht sich um die Frage, wie man Einbahnstraßen für Fußgänger in OpenStreetMap (OSM) korrekt taggt, insbesondere auf Wegen wie Fußwegen und Pfaden (highway=footway und highway=path). Es gab eine vorherige Diskussion im Forum zu diesem Thema, die keinen Konsens brachte. Der initiale Vorschlag (RFC) war wie folgt:

Formalisierung: Den Schlüssel oneway:foot=* für Wege formalisieren.
Deprecation: Die Verwendung von oneway=* auf highway=footway und highway=path zugunsten von spezifischeren Schlüsseln wie oneway:foot=* und oneway:bicycle=* verwerfen.
Keine Änderung: Die Verwendung von oneway=* auf Straßen und Radwegen soll unverändert bleiben.

Hauptargumente und Standpunkte:

osmuser63783 (Ersteller): Ziel war es, einen Kompromiss zwischen zwei gegensätzlichen Ansichten zu finden:
- oneway=* gilt nur für Fahrzeuge und nicht für Fußgänger.
- oneway=* gilt auch für Fußgänger auf Wegen.
- Schlägt vor, oneway:foot zu verwenden und bestehende oneway=* bei footways und paths zu deprecated um die Mehrdeutigkeit des oneway=* zu lösen.
- Möchte den Weg für die zukünftige Tagging und Nutzung (Rendering und Routing) mit eindeutigeren Schlüsseln ebnen.
- Bietet einen Pull Request für das iD-Tagging-Schema an, um die vorgeschlagenen Änderungen umzusetzen.
- Ändert später seinen Vorschlag nach Diskussionen: Deprecation von oneway=yes auf highway=path wird zurückgenommen.
Befürworter der Deprecation von oneway=*:
- Argumentieren, dass oneway=* auf Fußwegen und Pfaden mehrdeutig ist und unklare Ergebnisse für die Routenplanung erzeugt.
- Befürworten die explizite Verwendung von oneway:foot=* und oneway:bicycle=* für mehr Klarheit.
- Manche bevorzugen auch foot:backward=no zur Beschreibung des Problems, da es semantisch schöner ist.
- Es gibt die Befürchtung dass die Information, ob ein Weg für Fußgänger einbahnstraße ist oder nicht, fehlt.
- Sie argumentieren mit der Richtigkeit einer “sauberen Datenmodell” und “klaren Definitionen” und halten den Status Quo für mangelhaft, da dieser nicht die Datenmodell-Logik widerspiegelt.
Gegner der Deprecation von oneway=*:
- Argumentieren, dass oneway=* auf Fußwegen und Pfaden (mit Fahrradfreigabe) sich klar auf Fahrzeuge (z.B. Fahrräder) bezieht und nicht Fußgänger.
- Sehen keine Notwendigkeit, die bestehende Verwendung von oneway=* auf Fußwegen und Pfaden zu verwerfen.
- Argumentieren dass diese Interpretation und Nutzung von oneway=* in Deutschland üblich und die beste Lösung ist.
- Sie befürworten das beibehalten von oneway=yes auf allen Wegen, wobei bei Bedarf oneway:foot=yes/no explizit spezifiziert werden sollte.
- Manche argumentieren, dass eine neue Eigenschaft oneway:foot eigentlich foot:forward=no bedeutet und eher ein Verbot ist als eine wirkliche Einbahnstrasse, da es nicht immer bedeutet, dass man nicht zurückgehen darf, sondern nur nicht eintreten darf.
- Es wird kritisiert dass der Vorschlag oneway anders behandelt (also nur für Fahrzeuge) auf Strassen und Radwegen aber nicht für die Fußwege, Stufen, Korridore.
Weitere Argumente und Standpunkte:
- Unklarheit der Daten: Die aktuelle Datenlage ist uneinheitlich, viele Wege wurden möglicherweise falsch getaggt oder implizit anders gemeint. Es wird gefordert dass man die Daten korrigiert bevor man die Tags korrigiert (Wikifiddling)
- Reale Beispiele: In der Diskussion werden viele konkrete Beispiele von Einbahnwegen für Fußgänger genannt, zum Beispiel in Metrostationen, bei Sicherheitskontrollen, auf Wanderwegen, Warteschlangen.
- Bedeutung von oneway : Es wurde argumentiert, dass oneway immer nur für Fahrzeuge gilt (und nur in den wenigen Ausnahmefällen für Fußgänger, die Fahrzeuge schieben). Fußgänger sollten eine Richtung vorgeben, aber dies nicht mit einer Einbahnstraße verwechseln.
- Anwendung auf Wanderwege: Einige argumentieren das der tag “oneway” nur für die Richtung gilt und man kann innerhalb einer Einbahnstrasse zurückgehen als Wanderer.
- Probleme mit Routenplanern: Es wurde mehrmals kritisiert, dass einige Software die Tags unterschiedlich interpretieren oder z.B. oneway=yes auf Fußwegen ignorieren.
- Bedeutung der Präzision: Manche meinen es sei besser, wenn oneway:foot nur verwendet wird, wenn man wirklich eine Fußgänger-Einbahnstrasse beschreiben will.
- Bedeutung der Benutzerfreundlichkeit: Es wurde argumentiert, dass neue Nutzer intuitiv oneway=yes auch für Fußgänger verwenden würden.
- Bedeutung der Rechtmäßigkeit: Es wurde argumentiert, dass oneway:foot=yes auf Wegen oft ein No-Entry ist, und nicht eine echte Einschränkung in einer Richtung. Es gibt keine Verbotsschilder, die das Umkehren verbieten.
- Problem mit Dual-Carriageway: Es wurde argumentiert, dass auf einem dual-carriageway die oneway=yes tag sowohl die Straße als auch die Fußgängerseite meint.
- Es wurde angemerkt, dass viele Anwendungen noch nicht das tagging für oneway:vehicle unterstützen, dies aber eine nützliche Extrapolation wäre.

Schlüsselmomente der Diskussion:

Kritik an der Deprecation: Mehrere Benutzer äußern Bedenken bezüglich der Deprecation von oneway=* auf Fußwegen und Pfaden.
Vorschlag zur Präzisierung: Es wurde der Vorschlag gebracht, dass man oneway:foot=yes/no immer mit angeben soll, wenn man oneway=* auf Fußwegen verwendet und wenn man Fußgänger einschränken will.
Diskussion über die Rolle der Data-Consumer: Die Diskussion verlagert sich auf die Frage, wie Routing-Anwendungen mit diesen Tags umgehen sollten und ob sie die gängige Meinung der Mapper berücksichtigen sollten oder ob es dem Projekt dient die Daten der User zu korrigieren.
Suche nach einer Kompromisslösung: Es wird versucht eine Lösung zu finden, die den verschiedenen Standpunkten gerecht wird.
Bedeutung der korrekten Interpretation: Es wird festgestellt, dass es wichtig ist, sowohl für die Mapper als auch für die Datenkonsumenten klarzustellen, was die Tags bedeuten.
Zweifel an einer eindeutigen Interpretation: Manche zweifeln daran, dass es eine allgemein akzeptierte Interpretation von oneway=* gibt, die alle Fälle korrekt abdeckt und argumentieren mit dem “Prinzip der geringsten Überraschung”.
Idee des “oneway:type”: Es wird vorgeschlagen die Tags oneway:signed und oneway:type einzuführen, um mehr Klarheit zu schaffen.

Ergebnis des RFC:

Die Abstimmung über den Vorschlag scheiterte, da keine 75%-Mehrheit erreicht wurde (35 Stimmen dafür, 19 dagegen, 5 Enthaltungen).
Dennoch hat die Diskussion dazu beigetragen, das Problembewusstsein zu schärfen und verschiedene Perspektiven auf die Tagging-Problematik deutlich zu machen. Es wurde eine große Menge an Daten über die Prävalenz und das Problem der tag Nutzung analysiert und präsentiert.
Die Diskussion hat auch gezeigt, dass eine einheitliche Interpretation von oneway=* auf Fußwegen und Pfaden nicht existiert und dass spezifischere Tags erforderlich sind.
Es wurde deutlich, dass es schwer ist zu entscheiden ob oneway=yes nun ein Verbot oder eine Empfehlung ist.
Es gibt den Wunsch in der Community, dass in editoren die Nutzer besser angeleitet werden müssen die richtige Tags zu vergeben.

Fazit:

Die Diskussion zeigt die Komplexität des Themas und die Notwendigkeit, eine konsistente und eindeutige Methode zur Kennzeichnung von Einbahnstraßen für Fußgänger in OSM zu finden. Es wurde deutlich dass der aktuelle Zustand keine zufriedenstellende Lösung bietet und das ein Eingriff nötig ist. Das ergebnis der Diskussion ist, dass wahrscheinlich ein mehr spezifisches tag system eingeführt werden sollte, wo man genauer spezifiziert, auf welche Nutzer sich das Einbahnstrasse bezieht. Es ist noch unklar wie man das umsetzten wird. Die Diskussion ist wichtig, um eine zukünftige Lösung zu finden, die von der Community akzeptiert wird und die Datenqualität verbessert. Es wird wohl weitere Diskussionen geben.

Zusammenfassung mit Google Gemini 1.5

Die bereitgestellten Daten dokumentieren einen ausführlichen Diskussionsverlauf (216 Beiträge) im deutschsprachigen OpenStreetMap-Forum (Discourse-basiert) über die Tagging-Konventionen für Einbahnstraßen für Fußgänger.

Topic-Metadaten:

Titel: [RFC] Feature Proposal - One-way for pedestrians
Ersteller: osmuser63783
Erstellungsdatum: 2024-09-01
Beiträge: 216
Letzter Beitrag: 2025-01-24

Diskussionsverlaufszusammenfassung:

Der Hauptkonfliktpunkt der Diskussion dreht sich um die Interpretation des Tags oneway=yes auf Wegen, die primär für Fußgänger gedacht sind (highway=footway, highway=path). Zwei gegensätzliche Auffassungen stehen sich gegenüber:

Gruppe 1 (vorwiegend aus den USA): oneway=yes auf Fußwegen bedeutet, dass der Weg in eine Richtung für Fußgänger gesperrt ist. Die Bedeutung des Tags ist kontextbezogen und gilt für alle Verkehrsteilnehmer auf dem jeweiligen Wegtyp.
Gruppe 2 (vorwiegend aus Deutschland): oneway=yes auf Fußwegen bezieht sich ausschließlich auf den Fahrzeugverkehr (einschließlich Fahrräder). Fußgänger sind von solchen Einbahnstraßenregelungen ausgenommen. Der Tag oneway=yes sollte daher nur auf Wegen verwendet werden, die auch für Fahrzeuge freigegeben sind. Alternativ wird foot:backward=no als präzisere Kennzeichnung für Fußgänger-Einbahnstraßen vorgeschlagen.

Der Vorschlag (osmuser63783):

Der ursprüngliche Vorschlag von osmuser63783 zielte darauf ab, den bestehenden Tag oneway:foot=* zu formalisieren und die Verwendung von oneway=* auf highway=footway und highway=path zugunsten spezifischerer Tags (insbesondere oneway:foot=* und oneway:bicycle=*) zu reduzieren oder ganz abzuschaffen. Dieser Kompromissversuch sollte die widersprüchlichen Interpretationen beheben.

Diskussionsentwicklung:

Die Diskussion zeigt eine starke Uneinigkeit, wobei die Vorschläge im Laufe der Zeit modifiziert wurden:

Deprecation von oneway: Die Idee, oneway auf highway=footway und highway=path abzuschaffen, wurde kontrovers diskutiert. Schließlich wurde die Deprecation von oneway auf highway=footway verworfen, jedoch bei highway=path beibehalten, wobei der Tag hier nur für Fahrzeuge gelten sollte.
oneway:foot=* vs. foot:backward=no: Die Vor- und Nachteile von oneway:foot=* und foot:backward=no zur Kennzeichnung von Fußgänger-Einbahnstraßen wurden intensiv debattiert. oneway:foot=* wurde aufgrund seiner besseren Verständlichkeit bevorzugt.
Kontext und “Härte” der Einbahnstraßen: Die Diskussion umfasste die Frage nach der “Härte” von Fußgänger-Einbahnstraßenregelungen (z. B. physische Barrieren vs. Empfehlungen). Die Bedeutung des Tags sollte den tatsächlichen Gegebenheiten vor Ort entsprechen.
Rollen von Routern und Renderern: Die unterschiedliche Interpretation von oneway=* durch verschiedene Routing-Engines und Renderer wurde hervorgehoben. Die Notwendigkeit einer eindeutigen Tagging-Konvention für eine korrekte Darstellung und Routenplanung wurde betont.
Lösungsansätze: Verschiedene Lösungsansätze wurden diskutiert, darunter die explizite Verwendung von oneway:foot=*, die Verwendung von oneway:vehicle=* und oneway:foot=* für Wege mit gemischten Nutzergruppen und die Implementierung von Validierungsregeln und Editor-Presets, um präzisere Tagging zu fördern. Die Problematik von impliziten Annahmen und der Notwendigkeit einer eindeutigen Interpretation der Tags wurde betont.

Ergebnis:

Die Abstimmung über den Vorschlag endete mit 35 Ja-Stimmen, 19 Nein-Stimmen und 5 Enthaltungen (65% Zustimmung, weniger als die benötigten 75%). Obwohl der Vorschlag nicht angenommen wurde, führte die Diskussion zu einer erhöhten Sensibilisierung für das Problem der uneinheitlichen Tagging-Praxis und der unterschiedlichen Interpretationen durch Routing-Engines und Renderer. Die Diskussion betonte die Notwendigkeit, die Tagging-Konventionen zu verbessern und für mehr Klarheit zu sorgen. Der Fokus sollte auf der Verbesserung der Editor-Presets und der Implementierung von Validierungsregeln liegen.

toc-rox · January 25, 2025, 5:48pm

Ich werde in Kürze mal erläutern wie die Topic-Daten bei meinen Versuchen aufbereitet werden. Damit kann jeder dann schon mal eigene Versuche über z.B. KI-Browser-Interfaces (oder ähnliches) anstellen. BTW: Auch die Aufbereitung der Daten kann beeinflußt werden.

Insgesamt sehe ich in ‘qualifizierten Zusammenfassungen’ einiges an Potential. Sei es für die Ergebnissicherung, oder auch nur für die Sichtung von Topics. Aber dieses Thema sollten wir getrennt diskutieren. Zunächst muss es erstmal gelingen zu ‘qualifizierten und allgemein akzeptierten Zusammenfassungen’ zu kommen.

dieterdreist · January 25, 2025, 7:57pm

BTW: Das Topic “Kleine Fragen” wurde leider gesperrt. Kennt jemand den Grund dafür?

der Grund war, daß es ohne sinnvolle Überschrift nicht möglich ist, die Dinge einfach zu finden, die behandelt wurden. Eine kleine Frage kann man genauso einfach in einem neuen Thema behandeln, und wenn sie wirklich klein ist, dann wird der Thread halt kurz. Zumindest hatte ich das so verstanden.

toc-rox · January 26, 2025, 8:42am

Hier mein aktuelles Vorgehensmodell zur Nutzung der Daten eines Topics im Kontext eines KI-Sprachmodells:

Download aller Diskussionsbeiträge eines Topics.
Extraktion der relevanten Daten.
Upload der relevanten Daten an ein KI-Sprachmodell.
Datenbezogene Anfragen an das KI-Sprachmodell.

Download aller Diskussionsbeiträge zu einem Topic:

Dies ist über das CLI-Programm “discourse-reader” möglich.
Erforderlich:
- Einmalige Beantragung eines User-API-Keys.
- Berechtigung des API-Keys in den (Forums-) User-Einstellungen.

Einmalige Beantragung eines User-API-Key:

Dies ist über das CLI-Programm “discourse-user-api-key” möglich.
Der genaue Workflow ist in der Programmhilfe beschrieben.

Der Downloads eines Topics führt zu einer komplexen JSON-Datei:

{
  "meta_data": ...,
  "post_data": [ ... ]
}

Beispiel:

# download topic from forum
discourse-reader -forum="community.openstreetmap.org" -topic=124279 -output="124279.json" -userapikey="ca17daaabbbccc8888000777aaafff88"

Extraktion der relevanten Daten:

Dies ist über das CLI-Programm “jq” möglich.
Auch Änderungen der JSON-Daten sind möglich.

Beispiel:

# filter out unnecessary data
# meta data
jq '.meta_data | {title, created_by:.details.created_by.username, created_at, id, posts_count, last_posted_at}' 124279.json > 124279.compact.json
# post data
jq '.post_data[] | .post_stream.posts[] | {post_number, username, created_at, reply_to_post_number, post:.cooked, reactions, accepted_answer}' 124279.json >> 124279.compact.json

Upload der relevanten Daten an ein KI-Sprachmodell:
Datenbezogene Anfragen an das KI-Sprachmodell:

Hierzu soll n Kürze ein einfaches CLI-Programm entstehen.
Zunächst kann das Browser-Interface eines KI-Sprachmodells genutzt werden.

Die erwähnten Programme finden sich auf GitHub.

BTW: Die datenbezogenen Anfragen (Prompt) an das KI-Sprachmodell können vielschichtig sein:

Fasse die Diskussion zusammen.
Wieviele Posts hat der User “xyz” erstellt?
Welche Meinung vertritt der User “abc”?
…

toc-rox · February 18, 2025, 5:44pm

Das Programm (macOS, Linux, Windows) wird in Kürze für erste Tests verfügbar sein. Es interagiert mit der ‘Google Gemini KI’ und ist Open-Source. Benötigt wird ein persönlicher (kostenfreier) API-Key für Google-Gemini. Wer interessiert ist zu testen … möge sich melden.

PS: In der Vorbemerkung zum Programm steht dies:

Künstliche Intelligenz (KI) verändert unsere Strategie der Informationsbeschaffung und -verarbeitung. Gänzlich neu ist die Möglichkeit eigene Dokumente an die KI hochzuladen. Anschließende Abfragen beziehen sich dann auf den Kontext der hochgeladenen Dokumente. Qualifizierte und strukturierte Antworten sind oft über einen längeren Zeitraum wertvoll. Sie erfordern ein Konzept zur Archivierung. Auch die Anreicherung mit weiteren Information und eigenen Bewertungen kann sinnvoll sein. Dies alles erfordert ein anderes Vorgehensmodell als wie bisher bei klassischen Internet-Recherchen üblich. Die Nutzung von KI muss sich nahtlos in die eigene Arbeitumgebung und das eigene Arbeitsmodell integrieren.

toc-rox · February 27, 2025, 6:15am

Das oben erwähnte Programm steht unter dem Namen “gemini-prompt” auf Github zur Verfügung.

toc-rox · February 27, 2025, 6:23am

Zum Thema “Zusammenfassung” wären folgende Aspekte erwähnenswert:

Es gibt ein PlugIn für diese Forumssoftware (Discourse), mit dem die Zusammenfassung eines Threads standardmäßig möglich ist. Ausprobieren kann man dieses Feature im Meta-Discourse-Forum (Summerize-Button): https://meta.discourse.org/

Interessante finde ich auch die Möglichkeit den Titel des Thread (oftmals nur bedingt aussagekräftig) durch eine kompakte Zusammenfassung zu ergänzen. Das sieht dann z.B. so aus:

Langlaeufer · February 27, 2025, 3:37pm

Ich kann es nicht finden. Magst du nicht einen Link geben?