Erhöhte Wachsamkeit

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?

Keine regexps die Fliesstext matchen müssen auf jeden Fall :slight_smile:

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.

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.

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