…
die grüne Tonne für Nodes?
Halte ich für nicht gut. Warum?
Wenn die ID-Zahl ein Problem wäre, würden die Admins einen Bot laufen lassen und so freien Raum nach oben schaffen.
Wenn ich es richtig verstehe legst du dir eine DB an mit Node-IDs, die du irgendwann mal erstellt hast und dann wieder gelöscht hast. Irgendwann in der Zukunft erstellst du wieder einen neuen Node und dann nimmt josm erstmal eine ID aus deinem Speicher. Doch was ist, wenn schon ein anderer mit dieser ID etwas angestellt hat?
Es erschwert das Nachvollziehen der Änderungen.
Daher meine Frage: Worin siehst du den Vorteil des Recyclings?
…
Hallo,
gelöschte Knoten sind in den Daten tatsächlich gelöscht und deren IDs wären wieder frei. Lediglich in den Changesets sind sie noch vorhanden. Wenn solche IDs wiederverwendet werden, ließe sich das Changeset nicht mehr 1:1 rückgängig machen. Einen Vorteil für die Datenmenge bringt eine Wiederverwendung nicht, erschwert aber die Vergabe freier IDs (es müssten der Planet UND sämtliche Changesets herangezogen werden - es ist also besser, einfach nach der bisher höchsten ID weiter zu machen. Und bei der Länge der IDs zu sparen bringt weniger als man denkt: Mit jeder weiteren Dezimal-Stelle für die ID ließe sich nur ein Zehntel in der vorhergehenden unterbringen, wenn sie denn sogar alle frei werden würden. Beispiel: Aktuelle ID ist bei 80000 (man benötigt 5 Stellen), aber vorher würden 8000 (man brauchte bis dahin 4 Stellen) frei werden, wäre man aktuell bei 72000, man braucht immer noch 5 Stellen.
Grüße
Mario
Edit: Hinzu kommt noch, dass nicht JOSM die IDs vergibt, sondern der Server wenn die Daten hochgeladen werden. Man hat auch mittels Plugin keinen Einfluss darauf.
@Garmin-User:
Nö…ID’s werden automatisch nicht neu vergeben. Auch werden gelöschte Objekte nicht wirklich gelöscht, sondern nur als unsichtbar gekennzeichnet. Diese unsichtbaren Objekte sind aber nicht in den normalen Extrakten enthalten.
Ebenso vergibt die API nur dann eine ID, wenn man ihr eine negative ID unterjubelt.
die id ist das einzige merkmal, anhand dessen sich ein datensatz eindeutig und zweifelsfrei identifizieren lässt. wenn du alte id’s für neue datensätze benutzt, geht die eindeutigkeit verloren. da kommst du bei verknüpften datensätzen ganz schnell in teufels küche.
edit: typos
Hallo Henning,
es ließe sich also am Planet sparen, nicht aber an den Extrakten. Soviel ich weiß, kümmert sich z.B. Osmosis bei der normalen Verarbeitung nicht um solche Tags wie “visible=true/false” (ich habe in JOSM damit gespielt und selbst da keine Auswirkung erkannt) oder “action=“delete””. Das hätte doch auffallen müssen, so wie wenn man in JOSM was löscht und bei der Weiterverarbeitung ist es immer noch da. Jedenfalls könnte man Osmosis dann nicht auf den “Full-Planet” ansetzen.
“Ebenso vergibt die API nur dann eine ID, wenn man ihr eine negative ID unterjubelt.”
Genau, so macht es JOSM bei neu erstellten Objekten. Aber es darf nicht sein, dass man die IDs eben wegen obengenannter Gründe vor dem Upload patchen kann.
Grüße
Mario
Mal als Abschätzung: OSM hat derzeit 1,41 G “sichtbare” Knoten, höchste ID ist 1,69 G. Mithin sind insgesamt 280 M Knoten “gelöscht”. 512 Byte pro leeren Knoten kommen mir arg viel (und beliebig aus der Luft gegriffen) vor. Ich weiß nicht, wie es in der Datenbank gelöst ist, aber im Prinzip paßt die Information (mit einiger Redundanz) eher in 72 Byte (ID, Version, zwei Koordinaten, flags-Bitset (visible&clean), changeset, uid, timestamp, plus ein Zeiger auf den leeren Tag-Vektor je 8 Byte). Nehmen wir dennoch großzügig 512 Byte an. Hätte man bei OSM von Anfang an sämtliche IDs recycelt, hätte man damit 140 GB gespart. Bei 2’500 GB Gesamtgröße der Datenbank ist das kein ganz großer Wurf.
Die mit dem Vorschlag einsparbare Datenmenge ist sogar noch einmal deutlich kleiner, weil Du ja nur Knoten recyceln willst, die Du ausschließlich selbst erstellt und bearbeitet hast und bei denen Du daher davon ausgehst, daß kein Revert der Löschung nötig wird, welcher durch erneut vergebene IDs erschwert würde. Und das ganze passiert dann auch nur bei Nutzern des entsprechenden JOSM-Plugins.
Ich hatte die Idee auch schon mal, aber obige Überlegung sollte klar machen, daß sie nicht viel bringt.
In der OSM-DB spart man nichts, da dort auch gelöschte Objekte weiter vorhanden sind und die IDs immer gleich viel Speicherplatz benötigen. Eine Zahl in Int64 oder long oder was auch immer dafür verwendet wird ist immer gleich groß. Wo man sparen würde wären alle DB-Extrakte, da hier kleinere IDs genutzt werden können. In xml bei UTF-8 kommt man pro Zeichen auf 4 Byte. Wenn man nun bei 280M Nodes 4 Zeichen einsparen kann, spart man 4,5gb wenn diese Nodes alle in einem Weg referenziert sind nochmal 4,5gb. Ist jetzt nicht so der Kracher, oder?
Doch, denn statt der Löschung eines alten Knotens (d.h. Erstellen einer neuen Version desselben) und dem Anlegen eines neuen Knotens würde nur eine neue Version des bestehenden Knotens erstellt. Mögliche Ersparnis - sehr großzügig geschätzt - siehe oben.
Aber nur, wenn es innerhalb eines Changesets passiert. Das dürfte aber nicht immer der Fall sein. Anonsten hätte man eine Inkonsistenz drin.
…
Ein revert ist immer nur solange sinnvoll, bis mit den Objekten etwas anderes angestellt wurde. In der Praxis würde man dann wohl einem Objekt eine gewisse “Grabesruhe” verordnen, in der man das Löschen noch reverten kann. Danach wäre dann Sense. Das ist aber meiner Meinung nach nicht erstrebenswert.
Zu den Einsparungen: die 4,5 oder 9gb beziehen sich auf ein planet.osm als xml. Das hat eine Größe von ~250gb (hochgerechnet aus germany.osm, germany.pbf und planet.pbf). Das ist im optimistischsten Fall ein 25stel, was man einspart.
Ich möchte dazu mal einwerfen, dass darüber diskutiert wurde, im Rahmen des Lizenzwechsels, weil dabei sowieso viel umhergewirbelt wird, es doch auch möglich wäre a)‘den ID-Space zu verdichten’ ergo IDs wiederzuverwenden und b)Objekte und Objektversionen, die mit dem Lizenzwechsel wegfallen komplett aus der Datenbank zu nehmen. Obwohl die Einsparungen dadurch sicherlich nicht völlig vernachlässigbar wären (weil sie eben weit über das hier diskutierte hinausgehen und alles rausholen könnten, was nur möglich ist), wurde stattdessen entschieden, mit dem Lizenzwechsel das Datenvolumen noch zu vergrößern (zusätzliche Sichtbarkeitsflags, neue Versionen), da man der Meinung war, dass angesichts des enormen Wachstums der Datenbank der Effekt trotzdem nur ein Tropfen auf dem heißen Stein wäre und den Aufwand nicht rechtfertigt. Insofern würde ich mir keine Gedanken um sowas machen. Wenn es wirklich mal problematisch werden sollte, geht es um ganz andere Maßstäbe und dann muss man sich sowieso ‘von oben’, also von OSMF-Seite, darum kümmern.
Bitte macht das auf keinen Fall. Das nuetzt niemandem, das gibt nur Komplikationen.
Eine Node-ID ist fuer einen bestimmten Node und identifiziert den auch “ueber den Tod hinaus”. Wenn Du die wiederverwendest, entstehen bei einer History-Betrachtung ganz seltsame Dinge (“Node wurde geloescht und dann 200km weiter entfernt wiederhergestellt”). Das ist gar keine gute Idee. Ich hatte da schonmal so einen Experten, der mit so einem Verfharen Nodes zwischen Kontinenten herumgeschoben hat, das war gar nicht lustig.
Bye
Frederik