OPENER-next ungenaue Kartierung von POIs mittels fixme Tag

Hallo liebe OSM-Community,
wir von der TU Chemnitz arbeiten im Projekt OPENER next (https://www.openernext.de/) an einer Cross-Plattform-App, die dazu dienen soll, deutschlandweit Daten an Haltestellen vor allem bzgl. der Barrierefreiheit zu erfassen. (siehe Forum Eintrag “OPENER-next Vorstellung”)

Aktuell überlegen wir, ob wir dem Nutzer unserer App beim Erstellen von POIs die Möglichkeit bieten, Objekte anzulegen ohne die genaue Position anzugeben.
Die Position für einen Fahrkartenautomat würde z.B. vorerst auf die Plattform oder in die Nähe der Haltestelle gesetzt und mit einem „fixme“ Tag versehen werden. Hintergrund ist, dass so die Schwelle für das Erfassen von Daten reduziert wird und trotzdem ein anderer Nutzer die Position sowohl in unserer App als auch über andere Editoren korrigieren kann.

Haltet ihr diesen Ansatz für sinnvoll?

Jain.

Fixme sollte eine Ausnahme bleiben und nicht zur Regel werden. In so einem Fall wäre es sinnvoller, den Haltestellen-Datensatz mit einem Tag zu kennzeichnen, dass ein Fahrscheinautomat vorhanden ist.

Grüße
Joachim

Das “fixme” ist aus meiner Sicht überflüssig. Und das aus mindesten 3 Gründen.

  1. Wenn ein Mapper vor Ort einen Fehler o.ä. sieht, wird er diesen korrigeren.
  2. Der Tag ist in den mir bekannten Editoren i.d.R. optisch kaum zu erkennen.
  3. Wenn man dann doch mal mit einem QS-Tool danach sucht, bekommt man selbst bei kleinem Maßstab so viele angezeigt, dass man sich umgehend um etwas anderes kümmern will als die Beseitigung von fixme Tags. :roll_eyes:

Ich benutze bei erkannt Fehlern oder nötigen Ergänzugen, die ich nicht sofort beseitigen kann, lieber den “Hinweis”. Der ist auch einfacher zu handhaben. Und wird optisch besser präsentiert.

.

Das kann ich nur voll bestätigen. :frowning:

Wenn ich die zwei drei von @OPENER next gestarteten Threads lese, habe ich den Eindruck, dass das am Ende wieder, darauf hinausläuft, dass wieder auf die OSM-Mitwirkenden mehr Arbeit zukommt, um Daten in der Datenbank, die aus etwas Unausgegorenem zustande gekommen sind, zu reparieren. Das wäre IMHO kein Mehrwert für dieses Projekt.

@OPENER next: Ich würde Euch empfehlen, bevor Ihr irgendetwas in Angriff nehmt, eine umfassende IST-ZUstandsanlayse zu machen, wie das bei einer seriösen, wissenschaftlichen Arbeit die übliche Verfahrensweise ist. Dann würde ich Euch empfehlen, Euch mit der üblichen Verfahrensweise bei der Einführung neuer Keys bzw. Taggingschemas in OSM vertraut zu machen. Und weiterhin wäre umfangreiches Quellenstudium zum PTV1 und PTV2-Taggingschema für Euch sicherlich auch interessant.

Es wäre auch interessant, zu wissen, was bzw. wer Euch dazu gebracht hat, Euch insbesondere mit diesem Thema zu beschäftigen. Ergänzung: Die Frage hat sich mit diesem Post erübrigt

Hi, nur um das kurz zu erklären, damit das nicht falsch verstanden wird, wir arbeiten nicht mit OPENER next zusammen. Wir haben nur zufällig mit den DELFI Attributen das gleiche Thema und wurden vor ein paar Tagen von OPENER next kontaktiert. Ich finde es auch gut, wenn sich hier abgesprochen wird! Schließlich kommt das Thema Barrierefreiheit im ÖPNV in Deutschland jetzt überall auf und wird bestimmt noch in vielen Projekten angegangen. Und da sollten ja die Ansätze für OSM nicht in völlig verschiedene Richtungen laufen.

Ja, bitte so vorgehen und keine fixme-Tags streuen. Das wird sonst viel zu unübersichtlich.