überflüssige Tags entfernen

Nahmd,

Das gilt für automatisches Tilgen durch Software an Objekten, die ansonsten unverändert blieben.
Wenn ich ein Objekt ändere (und es Bestandteil eines Changesets wird, das eine Art created_by enthält), darf ich das “created_by” tilgen.
Das erledigt der JOSM aber ohnehin.

Gruß Wolf

Eventuell ist diese Seite auch schon etwas betagt, denn unter http://wiki.openstreetmap.org/wiki/DE:Map_Features kann man lesen:

Du verwechselst jetzt die Versionsnummer (welche außer Frage steht) mit dem davon unabhängigen und veralteten “created_by”-Tag welcher in aktuellen Versionen von Potlach und JOSM sowieso nicht mehr geschrieben wird. :wink:

Oli-Wan ging es darum, dass wenn du jetzt ein created-by-Tagg löscht, du dann eine neue Version des Objekts anlegst. Du willst Datenvolumen sparen, erzeugst dadurch aber massenhaft mehr Datenvolumen.
So ein Löschprozess muss außerhalb der api stattfinden oder so wie bisher, wenn ohnehin eine neue Version des Objektes angelegt werden muss.

O.k. Henning, hatte ich wohl dann mißverstanden.
Wie man’s am resourcenschonensten löschen kann weiß ich auch nicht, aber auf jeden Fall ist’s überflüssig.
Es wurden schon viele solcher überflüssigen Sachen in der Vergangenheit per Bot gelöscht und so sollte es nur mal eine Anregung sein.

mfG Michael

Könnte man, ja. Du kannst ja die Diskussion auf der rebuild-Mailingliste verfolgen, da wird das diskutiert (und findet momentan wenig Zuspruch).

Die Datenbank der Geodaten an sich wird doch dadurch kleiner, oder täusche ich mich da.

Nahmd,

Wenn Du ein geändertes Objekt hochlädst, wir eine neue Version des Objektes angelegt und das alte bleibt erhalten. Sonst würde z.B. die History nicht funktionieren.

Sagen wir mal Du hast ein Objekt mit 4 Tags, eines davon ein “created_by”. Wenn Du nur das created_by löschst und dann das Objekt speicherst, hast Du danach in der Key/Val-Tabelle drei Einträge mehr. Wenn Du oder ein anderer irgendwas ändert und wieder speicherst, kommen noch mal drei Key/Val dazu. Sind zusammen jetzt 6.

Wenn Du aber ohnehin das Objekt änderst und es ohnehin speichern musst, dann kannst Du im gleichen Aufwasch auch das created_by löschen (bzw. der JOSM macht das für Dich). Dann kommen drei Key/Val dazu. Besser als die 6 oben. :slight_smile:

Vereinfacht gesagt: die Datenbank macht keine Deletes, aber viele Inserts.

Gruß Wolf

Irgendwie muss ich da gerade an Facebook denken :wink:
Gruss
Walter

Moins,

feix

.oO( CREATE RULE “facebookdefault” AS ON DELETE TO “wasauchimmer” DO INSTEAD UPDATE “wasauchimmer” SET “deleted” = TRUE; )

Gruß Offtopic–Wolf

Ich sehe, um mitzureden, muss ich endlich auch das Programmieren lernen … :wink:

wobei das ganze Thema nicht ganz so einfach ist, wie es hier dargestellt wird. Es stimmt wohl, dass die DB durch das Entfernen unnützer Tags aufgebläht wird. Das trifft aber nur auf die OSM Datenbank zu und auf einige wenige, die mit Full-History DBs arbeiten. Alle anderen -die weit überwiegende Mehrheit-, also jeder der sich mal ein Extrakt runterlädt oder eine normale DB führt, hat ein Nachteil durch die nicht benötigten Tags. Ohne diese, würde sich seine Datenmenge verringern.

Jeder andere kann aber auch beim Import in die eigene Datenbank alles ausfiltern, was ihn nicht interessiert. Ein reiner Anwender könnte etwa created_by, source(:.)?, note, fixme, tiger:., 3dshapes:., AND_. u.v.m. verwerfen.

In der Tat ist die Sache vielschichtiger, selbst wenn man nur die OSM-Server betrachtet: die volle DB wächst durch eine created_by-Putzaktion, das vielfach heruntergeladene Planetfile schrumpft hingegen - wodurch die Netzwerkanbindung zukünftig marginal weniger belastet wird. (Zur Orientierung: created_by klebt an etwa zwei Prozent aller Objekte, und macht je nach Objekt teils nur einen sehr kleinen Bruchteil der Datenmenge aus.) Andererseits werden erstmal jede Menge große Diffs rausgehauen, um die Änderung created_by weiterzugeben - was wiederum jetzt Bandbreite frißt. Bandbreite wird aber tendentiell immer billiger - das spricht wieder dafür, created_by einfach wie bisher langsam aussterben zu lassen statt jetzt auf einen Schlag auszurotten, sprich lieber (relativ) billige zukünftige Bandbreite (und Speicherplatz) zu verschwenden als teure heutige Bandbreite.

Ein wenig:

Die “grosse” DB auf den Servern in UK und der Full-Planet mit History wird dadurch grösser. Das hat Netzwolf ja schon erklärt.

Die Planet-Exports von planet.openstreetmap.org und die Extrakte der geofabrik werden allerdings kleiner, da sie ja nur den aktuellen Stand enthalten.
Dadurch werden auch die lokalen Datenbanken (z.B mit osm2pgsql neu aufgebauten) kleiner.
Ich glaube, dass auch die Diff-Files (täglich/stündlich/minütlich) kleiner werden, da sie ja auch immer die geänderten Objekte komplett enthalten und diese ja kleiner geworden sind.

Frage: Wie wird denn der Abgleich der “neuen” ODbL-DB mit den bestehenden lokalen Kopien erfolgen?
Ein neues Planet-File mit den aktuellen Objekten ist klar, ebenso passende Exporte; aber wird es auch diff/change-Files geben, die aus “alt” “neu” machen?
Ansonsten müsste man ja die lokale DB neu aufsetzen (was bei mir schlappe 6 Tage Realtime dauert)

Gruss
Walter

Das trifft aber auch auf Plattenplatz zu (wenns nicht gerade ne Flut in Thailand gibt). Die Extrakte wachsen eh immer mehr und werden immer unhandlicher. Tausende müssen mit unnötig großen Extrakten arbeiten damit einige wenige mit Full History DBs nicht mehr Plattenplatz brauchen. Und der 0815 Nutzer, der sich ne Garmin-Karte mit dem Map Composer erstellt, ist vermutlich mit dem Filtern überfordert.
Eine Lösung wären natürlich auch gefilterte Extrakte, wo bspw die von Dir erwähnten Tags nicht mehr enthalten wären.
Interessant wäre es mal zu wissen, wie groß das Problem eigentlich ist. Also wie würde sich die Datenmenge verringert wenn man die ganzen created_by, note, fixme, source* etc, die man meist eh nicht braucht, rauswirft

Richtig, die Diskussion ist bislang etwas freischwebend.
Ich habe gerade mal Hessen [1] als osm.bz2 von der Geofabrik runtergeladen, entpackt, mit grep die Tags created_by, note, fixme [2] ausgefiltert, wieder komprimiert. Zum Vergleich dasselbe nochmal ohne Ausfiltern (um einheitliche Kompressionseinstellungen zu verwenden, die Geofabrik verwendet bzip2 mit anderen Optionen). Ergebnis:


130041791 ungefiltert
129746290   gefiltert
129600889   gefiltert2 [3]

Macht eine Reduktion des Datenvolumens um etwa 0.3 Prozent. Zum Vergleich: das komprimierte Planetfile wächst wöchentlich um etwa 0.5 Prozent.
Klarerweise lassen sich die Zahlen nicht direkt auf den Platzbedarf einer Datenbank übertragen, u.a. wegen des großen Overhead der XML-Daten, die ich verglichen habe. Aber die Größenordnung dürfte ähnlich sein.

[1] DE hätte mir zulange gedauert, die Zwergstaaten sind möglicherweise nicht repräsentativ. Deswegen habe ich ein mittelgroßes Bundesland genommen - ansonsten kein tieferer Grund für Hessen.
[2] Präziser: ‘<tag k="(created_by|note|fixme)’. Also auch note:de, note2 usw.; ferner ohne Rücksicht auf Groß- und Kleinschreibung, also auch FIXME.
[3] auch noch source weg – ‘<tag k="(created_by|note|fixme|source)’

Danke Oli-Wan. Ich glaube zwar, dass der Anteil im Ausland höher ist, da dort die Daten seltener angefasst werden, durchschnittlich älter sind und daher mehr created_by Tags haben, aber Dein Test zeigt, dass es sich nicht lohnt, das Thema mit Mühe und Schweiß anzugehen.

Ich denke, bei created_by sind die Unterschiede nicht so groß. Deine Vermutung mag zutreffen, andererseits gibt es gegenläufige Effekte. So ist OSM in DE relativ früh gestartet, in manchen anderen Ländern dagegen erst später in die Hufe gekommen - als die Editoren gar kein created_by mehr gesetzt haben. source hatte ich in der Auswertung noch vergessen, aber das wird den Altkanzler auch nicht schlank machen. oben ergänzt

Bei den sonstigen Tags gibt es länderspezifische Unterschiede. In NL etwa stammen die landuse-Daten und Gebäude größtenteils aus dem 3dShapes-Import und tragen massig Tags wie source=3dShapes, 3dshapes:ggmodelk=. Die Straßen hingegen stammen aus dem AND-Import und tragen AND:importance_level=, AND_nosr_r=* und gelegentlich noch anderen Mist. Wer also eine NL-Datenbank zum Rendern aufsetzen will, könnte evtl. in der lokalen Datenbank noch ein paar Prozent mehr Reduktion erreichen. Ähnlich dürfte es in anderen importgeplagten Ländern (FR/cadastre, USA/TIGER, CDN/kann weg, JPN/argrath, AUS/ABS2006, …), aussehen. Aber wie schon angedeutet, würde eine solche Filterung das stetige Wachstum des Datenvolumens lediglich um ein paar Wochen verzögern.

Dafür haut man jetzt eineige ziemlich große diffs raus. Man hat also kurzzeitig einen deutlich erhöhten Traffic. Der Plattenplatz verringert sich auch nicht, da die diffs Ewigkeiten auf dem Server liegen. Bspw. hourly seit ~2009

…und genau deshalb macht der Composer das ja auch automatisch für den 0815-Nutzer :wink:

Interessante Frage, vielleicht ein Fall für die rebuild-Liste?

Im Prinzip wäre es ja naheliegend, die alte CC-BY-SA-DB in eine ODbL-DB umzudiffen, also mit Diffs auf einen Stand zu bringen, der nur noch ODbL-lizensierte Daten enthält. Aber formaljuristisch wäre der so erzeugte Datenbestand ein abgeleitetes Werk der alten CC-BY-SA-Daten, welche die lokale DB enthielt…

Es kommt darauf an, wie der Neuaufbau der Datenbank technisch ablaufen wird, z.B. könnten sich alle Objekt-IDs ändern (das wurde überlegt, Ergebnis ist mir unbekannt).
Darüber wird man vermutlich dann genauer nachdenken, wenn man die Schritte davor erledigt hat. :wink:

Gruß,
Mondschein