Erhöhte Wachsamkeit

Wieso meinst du wohl das wir da nachgefragt haben? Aber da der Edit im nirgendwo stattfand, wäre es vielleicht möglich gewesen rauszufinden was der Editor effektiv wollte (siehe Text Changeset Kommentar).

So wies es aussieht funktioniert das Zeugs nicht schlecht, ist aber gleichzeitig für unsere Zwecke völlig unbrauchbar, da ihre Daten erst ein paar Wochen nach den Edits zur Verfügung stehen. Sprich zu einem Zeitpunk wo “high profile” Vandalismus schon längstens behoben ist (wie in diesem Fall).

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. Das letzte was ich gehört hatte, war, dass Mapbox nicht für seine häufgen Updates bekannt war.

Zufall sicher und “Pech”, aber es ist die naheliegende Erklärung.

hier sieht man wahrscheinlich den Unterschied zwischen paid mapping und Leuten, die aus Leidenschaft mappen. Wer eine Namensänderung für NYC durchgehen lässt macht auch einen Haken an alles andere :wink:

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

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
  1. Es gibt einfach Dinge die darf der Server nicht annehmen.
  2. Es muss Programierbare Filter geben.
  3. 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.

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!

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 :smiley:

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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