News zur kommenden API 0.6

Hallo, für die, die die Entwicklung nicht verfolgen, hier ein kurzer Abriss darüber, was mit API 0.6 kommen wird. Die Einführung ist um die Weihnachtszeit geplant und wird mit einer mehrtägigen Auszeit verbunden sein. Wenn jemand in einem Forum mitliest, in dem das interessant sein könnte, gern auch dorthin übernehmen. * Relationen geordnet - die API wird künftig die Elemente einer Relation in der Reihenfolge zurückgeben, wie man sie reingestopft hat. Dadurch wird man z.B. eine Busroute und ihre Haltestellen ordentlich abbilden können, ohne dass man als “role” sowas wie “stop_1”, “stop_2”, “stop_3” usw. nutzen muss. * Limits für die Größe von Ways und Relationen - so größenordnungsmäßig nicht mehr als 2000 Nodes pro Way und nicht mehr als 2000 Members pro Relation. Existierende, die größer sind, können noch heruntergeladen, aber nicht mehr verändert werden. Eventuell machen wir auch vorher noch eine Zerhack-Aktion, damit es keine größeren mehr gibt. * Transaktionalität im Backend - keine Diskrepanzen zwischen “current”- und “history”-Tabellen mehr, garantierte referentielle Integrität. * “optimistic locking” - Die Änderung eines Objekts wird künftig nur noch erlaubt, wenn die Anfrage sich auf die richtige Versionsnummer bezieht. Hierdurch wird das Szenario “User A lädt Daten herunter, bekommt Version 5 des Objekts, User B lädt herunter, bekommt auch Version 5, User B macht Upload (ergibt Version 6), User A macht Upload und überschreibt Arbeit von B” vermieden; User A wird künftig eine Fehlermeldung (“409 Conflict” o.ä.) erhalten. - Als kleinen für Programmierer bedeutenden Seiteneffekt bringt diese Änderung mit sich, dass alle modifizierenden API-Calls inklusive der HTTP-DELETE-Methode nun eine Nutzlast (einen Request Body) tragen müssen. Dies ist mit dem HTTP-Standard konform, aber nicht alle HTTP-Libraries unterstützen Nutzlast bei DELETE (z.B. die Standard-Java-Implementation kanns nicht). * Changesets - Änderungen müssen künftig zwangsweise in Gruppen zusammengefasst werden. Eine Änderung kann nur hochgeladen werden, wenn sie sich auf eine gültige solche Gruppe - ein “Changeset” - bezieht. Beim Erzeugen eines Changesets muss ein Kommentar (ähnlich einem Commit-Kommentar in einem Versionskontrollsystem) eingegeben werden. Changesets haben ein begrenztes Fassungsvermögen und eine begrenzte Lebensdauer. Datenbank-intern wird für ein Changeset mitprotokolliert, welches Rechteck auf der Karte von diesem Changeset insgesamt betroffen ist. Abfragefunktionen ermöglichen es später, eine Liste aller Changesets für ein bestimmtes Gebiet abzurufen. Datenbank-intern wandern auch einige Dinge, die bislang pro Objekt gespeichert wurden - Username und “created_by” - in die Changeset-Tabelle (Changesets können beliebige Tags haben). Changesets sind nicht atomar/transaktional. * Diff-Upload - das bereits verbreitete “osmdiff”-Format, in dem auch die täglichen diffs generiert werden und das von Osmosis unterstützt wird, kann nun auch für Uploads an den Server benutzt werden, d.h. man kann eine größere Menge Änderungen in einem diff-File zusammenstellen und dieses dann in einem einzigen Vorgang hochladen. Diff-Uploads sind transaktional, d.h. wenn eine einzige Änderung im Upload schiefgeht, wird keine aktiv. Alles in allem wird das ein Riesenschritt vorwärts. Leider ist noch nicht ganz klar, ob performancemäßig alles so läuft, wie wir das erwarten, hier müssen noch Tests geschrieben und durchgeführt werden, das Cloudmade-Team (Andy Allan, Shaun McDonald, Matt Amos) arbeitet daran. Mit API 0.6 würden die lezten verbliebenen MyISAM-Tabellen rausgeworfen und komplett auf InnoDB gesetzt; MySQL-Experten wissen, was das bedeutet. Durch die Changesets wird viel für Rollback und Anti-Vandalismus vorbereitet, allerdings unterstützt die API selber keinen Rollback-Mechanismus. Es wird also der Programmierer-Community zufallen, hier Software zu schreiben, die es dem User erlaubt, relevante Changesets herunterzuladen und zu inspizieren und dann auf eins zu klicken und zu sagen “dies will ich rückgängig machen”, dann ein geeignetes “diff” zu erzeugen und dies an die Datenbank zu senden. Im simpelsten Fall ist so ein diff wirklich einfach das “Changeset rückwärts”, aber kompliziert wird es, wenn einige Dinge in der Zwischenzeit von anderen verändert wurden. Hier wird es sicherlich eine lange Entwicklung geben, bis wir da richtig gute Tools bekommen. Parallel und weithin unbemerkt ist der Ruby-Code auch von sämtlichen MySQL-Spezialfällen bereinigt worden, so dass die API nun zumindest theoretisch auch auf PostgreSQL läuft (zunächst ohne PostGIS-Extensions). Wer Spass daran hat, kann sich den aktuellen Code aus dem SVN ziehen und damit spielen (Bugreports zu Postgres an Andy Allan). Es ist nicht geplant, bei der Umstellung auf API 0.6 auch gleich auf PostgreSQL zu gehen, aber die Sache wird weiter verfolgt, vorallem auch, um was in der Hinterhand zu haben, falls die MySQL-Performance nicht akzeptabel ist. Und abschliessend: Ich bin nur der Überbringer dieser Botschaft, ich habe selbst nur ein paar kleine Sachen zu 0.6 beigetragen; Lob oder Tadel also nicht an mich, ausser ihr wollt danke sagen, dass jemand mal alles zusammengeschrieben hat oder meinen Duktus kritisieren :wink: Bye Frederik Nur zur allgemeinen Info! Georg

Hat das nun für den Otto-Normal-Mapper weitergehende Auswirkungen? (Außer den wohl mehrtägigen Ausfall)

Sieht so aus, ja. Wie ichs verstanden habe, musst du nun bei jeder Änderung die du Hochlädst ein Kommentar mit dazu schreiben was geändert wurde. Und der Upload von Änderungen wird verweigert wenn sich in dem Bereich den du bearbeitet hast, seit deinem letzten Download etwas verändert hat. Und Relationen sind jetzt wohl einfacher zu handhaben (hab noch nie welche gemacht bisher, daher weiss ich jetzt auch nicht so 100% was die Änderung dort wirklich bedeutet) Danke dass dus gepostet hast Hobby Navigator :slight_smile:

Und was genau passiert dann? Alle Änderungen für die Katz weil gerade mal jemand im potlatch rumgespielt und versehentlich einen Node leicht verschoben hat? Wie wirkt sich die Änderung auf das Online-Editieren mit potlatch aus?

Das solltest Du dem Programmierer des Edtiors fragen (und dann hier berichten :slight_smile: ). Ich vermute es wird, wie jetzt auch schon in JOSM, eine Konfliktwarnung geben, dass es 2 konkurierende aktuelle Versionen eines nodes / ways gibt und der User muss entscheiden, welche Version die finale werden soll.

Fragen stellt bitte an den Programmierer so wie es PHerison schon empfohlen hat. Frederik Ramm ist ebenfalls nur der Ãœbermittler in der Mailingliste gewesen, ich denke jedoch dass er die eine oder andere Frage beantworten kann. Wollte den Tread nur bekannt machen, da ich gelegentlich :slight_smile: auch in der Mailingliste mitlese… duck und weg :slight_smile: Georg

Also reiner Anwender werde ich wie empfohlen einfach mal abwarten, wie die Editoren das implementieren. Wenn JOSM jetzt schon solche Konfliktwarnungen gibt, dann ist das Ganze aus Anwendersicht ja nichts Neues. Gruß, dgdg