Hallo zusammen,
auf der OSM Talk-de Liste hat Frederik Ramm die Änderungen, die die API 0.6 bringen wird, zusammengefasst:
Die Einführung ist um die Weihnachtszeit geplant und wird mit einer mehrtägigen Auszeit verbunden sein.
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.
Gruß,
Stefan