Erhöhte Wachsamkeit

maxbe · 2018-09-01T08:29:36.000Z

SunCobalt:

irgendwas an dieser Geschichte ist komisch bzw ein riesen Zufall. Wenn der Vandalismus innerhalb von 2 Stunden behoben wurde, ist es schon ein großer Zufall, dass Mapbox in genau diesen 2 Stunden sein Dump gezogen hat.

Solche Zufälle passieren anderen auch. Das ist der Nachteil seltener Updates.

EinKonstanzer · 2018-09-01T10:59:42.000Z

Meiner Meinung nach ist das im Allgemeinen das größte Problem der API 0.6.

Aus ganz Jamaika ein Gewerbegebiet machen
3 Nodes auf der Welt verteilen und daraus ein Haus machen
Einfach mal ein Stück Küstenlinie umdrehen

Es gibt einfach Dinge die darf der Server nicht annehmen.
Es muss Programierbare Filter geben.
Und programmierbare Watchlisten, Feeds, … Die zum Beispiel jedes Changset mit “Hitler” auflisten… ala Blacklist

Ich halte das inzwischen nicht mehr für ein Feature für API 0.7 sondern für ein Fehler der dringend behoben werden muss.

Die Zuverlässigkeit und Qualität des Datenmaterials wird halt immer wichtiger. Früher war es eher noch die Quantität.

mmd · 2018-09-01T11:08:27.000Z

EinKonstanzer:

Ich halte das inzwischen nicht mehr für ein Feature für API 0.7 sondern für ein Fehler der dringend behoben werden muss.

Ich halte das aus diversen Gründen nicht gerade für eine gute Idee, das serverseitig lösen zu wollen. Von mir aus gerne in jedem Editor.

EinKonstanzer · 2018-09-01T11:19:22.000Z

mmd:

EinKonstanzer:

Ich halte das inzwischen nicht mehr für ein Feature für API 0.7 sondern für ein Fehler der dringend behoben werden muss.

Ich halte das aus diversen Gründen nicht gerade für eine gute Idee, das serverseitig lösen zu wollen. Von mir aus gerne in jedem Editor.

Wäre schön wenn die anderen Editoren mal eine ausgeklügelt Prüfung hätten wie JOSM… Aber auch so ein Mist kann man selbst mit JOSM machen. Serverseitig!

chazanov · 2018-09-01T11:27:46.000Z

EinKonstanzer:

Aus ganz Jamaika ein Gewerbegebiet machen

3 Nodes auf der Welt verteilen und daraus ein Haus machen

Einfach mal ein Stück Küstenlinie umdrehen

Vandalismus dieser Art wäre relativ leicht ausfilterbar. Wenn man will, könnte man das lösen.

Aber was soll man mit erfahrenen Mappern tun, die sich bewusst keine Mühe beim mappen geben? Der hier z.B. mappt immer wieder eckige Kurven; deutsche Mapper nenne ich jetzt lieber nicht

Außerdem ist es einfach zu leicht, sich immer wieder neue Konten anzulegen und damit andere Mapper zu nerven. In den USA wird z.B. kre3d regelmäßig von Vandalisten heimgesucht. Damit OSM nicht wie die Wikipedia endet, sollte man neuen Usern (z.B. < 4 Tage Alter) die Nutzung von JOSM und dem Reverter nicht gestatten.

mmd · 2018-09-01T11:32:29.000Z

EinKonstanzer:

Aber auch so ein Mist kann man selbst mit JOSM machen.

Es fängt ja schon an, dass es für viele Sachen keine vernünftige Kriterien gibt, was Mist ist und was nicht. Das Projekt wäre dann nur noch damit beschäftigt, irgendwelche Regeln zu basteln.

Das ganze serverseitig als Teil der API zu bauen, würde locker mal mehrere Hundert Tage Aufwand bedeuten, und dann ist es immer noch Murks. Und es gibt vor allem niemanden, der das machen wird und die Zeit dafür hat.

EinKonstanzer · 2018-09-01T11:47:16.000Z

mmd:

Das ganze serverseitig als Teil der API zu bauen, würde locker mal mehrere Hundert Tage Aufwand bedeuten, und dann ist es immer noch Murks. Und es gibt vor allem niemanden, der das machen wird und die Zeit dafür hat.

Sieht so aus… Oder wann ist die API 0.7 fertig?

mmd · 2018-09-01T12:06:22.000Z

Schwieriges Thema. Seit etwa 2009 erfreut sich folgende Brainstorming Seite zur API 0.7 wechselnder Beliebtheit: https://wiki.openstreetmap.org/wiki/API_v0.7. Mehr gibt’s dazu im Moment eigentlich nicht zu sagen. Anfang und Ende: vollkommen offen.

Wer sich für Änderungen am Datenmodell interessiert, mag vielleicht auch hier vorbeischauen: https://github.com/osmlab/osm-data-model. Dort geht es darum, ganz gezielt bestimmt Probleme im heutigen Modell anzugehen. Ist aber auch ein Projekt für mehrere Jahre.

dieterdreist · 2018-09-01T14:14:46.000Z

EinKonstanzer:

Früher war es eher noch die Quantität.

ach komm, als ob das jemals anders gewesen wäre, Qualität war schon immer unser Markenzeichen, Steckenpferd und Diskussionsthema. Wir haben noch nie gesagt, lieber viel als gründlich.

SunCobalt · 2018-09-01T14:16:18.000Z

Eine Studie meinte zur technischen Stagnation kürzlich "the lack of change “[…] is not because of a lack of motivation, nor technological difficulties of carrying out such changes. The technological stasis is rather rooted in the dominant position of few project members who are able to change the software design; it is their perception of the project that defines how data should be stored and what features are dispensable”

Demnach müsste man die “few project member” von der neuen API Version überzeugen.

mmd · 2018-09-01T14:49:55.000Z

Das ist dieses “OSM has hidden Gatekeepers”-Thema, das schon in einem früheren Blogpost von jemandem, der nicht mehr in der Community aktiv ist, in die Welt gesetzt wurde und seitdem von allem und jedem als die “OSM Community Meinung” herhalten muss. Ich kenne genau eine weitere Person mit gleicher Meinung (dazu gibt’s auch einen weiteren Blogpost). M.E. ist das alles ziemlicher BS, bringt aber schön Klicks und Likes auf Social Media.

Ursprünglich entstand die Frustration wohl daraus, dass das Moderations-Tool, welches seit ein paar Monaten live ist, zunächst als Studi-Projekt im Rahmen eines Google Summer of Code entstand, dann aber ein paar Jahre wg. massiven Qualitätsproblemen nicht integriert wurde (“die bösen Gatekeeper!!11!!”). Besagter Autor des Blogpost stand diesem Studenten übrigens damals als Mentor zur Seite. Erst Dank der sehr umfangreichen Anpassungsarbeit von Andy Allen ist das ganze überhaupt erst in eine Form gebracht worden, dass es für die OSM Seite nutzbar wurde.

SunCobalt · 2018-09-01T15:01:05.000Z

mmd:

M.E. ist das alles ziemlicher BS, bringt aber schön Klicks und Likes auf Social Media.

Der Autor schien vom Feedback überrascht worden zu sein und geht in einem neuen Artikel auf die Kritikpunkte ein.
Leider kenne ich den Hintergrund des Autors nicht und kann seine Ansichten nicht einordnen.

wambacher · 2018-09-01T15:18:13.000Z

mmd:

Wer sich für Änderungen am Datenmodell interessiert, mag vielleicht auch hier vorbeischauen: https://github.com/osmlab/osm-data-model. Dort geht es darum, ganz gezielt bestimmt Probleme im heutigen Modell anzugehen. Ist aber auch ein Projekt für mehrere Jahre.

Und wie ich bei einem FossGis-Treffen erfahren habe, ist genau dieses Datenmodell das größte Hindernis. Solange das nicht weggeräumt ist, passiert wohl nix mit der 0.7

Gruss
walter

SimonPoole · 2018-09-01T19:42:41.000Z

wambacher:

Und wie ich bei einem FossGis-Treffen erfahren habe, ist genau dieses Datenmodell das größte Hindernis. Solange das nicht weggeräumt ist, passiert wohl nix mit der 0.7

Ich würde eher sagen ein Area Datentyp wird es vorher nicht geben (aus naheliegenden Gründen), aber andere Sachen die tatsächlich nicht rückwärts kompatibel sind (es gibt ja laufend Änderungen an der API, sie sind nur immer so, dass es keinen Versionswechsel braucht) könnt man durchaus in eine 0.7 packen. Z.B. endlich vernünftige Fehlermeldungen von der API.

mmd · 2018-09-01T20:12:41.000Z

SimonPoole:

ndlich vernünftige Fehlermeldungen von der API.

Das hört sich vernünftig an. Gibt’s dazu schon nähere Ideen wie so etwas aussehen kann?

SimonPoole · 2018-09-01T20:24:43.000Z

mmd:

SimonPoole:

ndlich vernünftige Fehlermeldungen von der API.

Das hört sich vernünftig an. Gibt’s dazu schon nähere Ideen wie so etwas aussehen kann?

Keine regexps die Fliesstext matchen müssen auf jeden Fall

Ich hab das mal ein bisschen mit Matt besprochen, und vernünftigerweise würden wir nur ein Wert als Fehlercode verwenden (anstatt das halbe Dutzend oder so das wir jetzt haben) und den Fehler und die Ids von allfällig involvierte OSM Objekte strukturiert (XML oder JSON) zurückgeben.

mmd · 2018-09-01T21:26:36.000Z

Das mit den Error-Codes habe ich auch schon gelesen, ich glaube in irgendwelchen Slides von Matt. Für REST-Schnittstellen ist das eigentlich ziemlich verbreitet, egal ob in Amazons AWS S3, oder Google Cloud Platform Dienste, um mal ein paar Beispiele zu bemühen.

Strukturierte Fehlermeldungen: ok, das passt.

chazanov · 2018-09-01T23:09:47.000Z

“OSM has hidden Gatekeepers” hat auch was von “hinter allem stecken die Juden”. Ich würde da ganz vorsichtig sein.

ikonor · 2018-09-02T11:29:27.000Z

whb:

Nach deren Angaben markiert eine KI (*) verdächtige Bearbeitungen, ein Mensch überprüft das dann nochmals […]

(*) Ist damit OSMCha gemeint?
https://osmcha.mapbox.com/changesets/61555047/

OSMCha selbst ist zur manuellen Prüfung, die Markierungen (“Flags”) an Changesets stammen von externen Tools. Nach solchen als verdächtig markierten Changesets kann man filtern:
https://osmcha.mapbox.com/?filters=%7B%22is_suspect%22%3A%5B%7B%22label%22%3A%22Yes%22%2C%22value%22%3A%22True%22%7D%5D%7D

Eines der Tools zur automatisierten Prüfung ist osm-compare, das mit in JavaScript programmierten Prüffunktionen arbeitet:
https://github.com/mapbox/osm-compare

Eine Liste der Prüfungen mit Kurzbeschreibung gibt es hier:
https://github.com/mapbox/osm-compare/blob/master/comparators/README.md

Das OSMCha Flag “Flagged for Review by Mapbox” und die Klassifizierungen mit “Mapbox:” Präfix (Auswahl als Beispiel) stammen aus dem internen Prüfprozess bei Mapbox (mit ein paar Wochen Versatz, wie Simon schon schrieb).

Einen Vortrag dazu gab es kürzlich auf der SotM:
https://2018.stateofthemap.org/2018/T079-Can_we_validate_every_change_on_OSM_/
https://www.youtube.com/watch?v=e7VosnqXjBY&feature=youtu.be&t=47m14s

Nähere technische Details zum Prozess oder der KI gab es aber bisher nicht.

pitscheplatsch · 2018-09-05T11:48:41.000Z

A new Lummerland?
See https://www.openstreetmap.org/changeset/62287726#map=17/48.46466/-7.71751

Hab’s mal kommentiert. So auf die schnelle/ferne sieht’s aber nicht richtig aus.
Vielleicht kann es noch jemand anderes prüfen… danke.