Am 15.01.2013 14:20, schrieb Martin Koppenhoefer:
Am 15. Januar 2013 13:58 schrieb Peter Wendorff<wendo...@uni-paderborn.de>:
Insofern sollten wir uns überlegen, wie wir damit insgesamt umgehen können,
denn einfach nur defaults löschen reicht eben eigentlich nicht, wir müssten
genaugenommen Verifikationsdaten für jeden Tag mit einführen - und da ein
editierender Mapper auch nicht zwingend jeden Tag kontrolliert, sondern
möglicherweise nur seinen hinzufügt, müsste es eigentlich für jedes einzelne
Attribut ein "last-verified"-Datum geben.
die Idee kommt ja auch gelegentlich wieder, wenn man sowas je
einführen wollte wäre ich dafür, das direkt in der API/db zu
realisieren, z.B. als Attribut am tag, wo das changeset reinkommt
(d.h. wenn man ein Objekt ändert würde man auch für bestehende tags
clicken können: verifiziert, so dass lastverified das Datum des
entspr. Changesets wäre). Das mit jeweils neuen tags zu machen
(verified:maxspeed=20130115-16:48h) wäre ein gigantischer Overhead.
Über Tags wäre der overhead sicher gigantisch, das stimmt.
Ob aber das changeset passend ist, weiß ich nicht, denn der
changeset-timestamp ist nicht zwingend der letzte Stand der verifikation.
Einerseits stimmt das definitiv nicht bei Luftbild-Abzeichnern, die
keine lokalen Kenntnisse haben, hier wäre als Datum das Aufnahmedatum
der Luftbilder sinnvoll, andererseits stimmt das auch nicht für das
Einzeichnen von Daten anhand gesammelter Tracks und Fotos vom letzten
Sommerurlaub, wozu man aus zeitgründen aber erst im Winter kommt oder so.
Das über Tags zu machen, gebe ich dir recht, würde zu weit führen.
Ich sehe mehrere Varianten.
Zunächst möchte ich feststellen, dass ein "last-checked" eigentlich nur
für den aktuellen zustand relevant ist, ein last-checked in der history
also eigentlich nicht (evtl. abgesehen von vandalismus/reverts etc.).
Sofern ich damit falsch liege, fallen einige der Varianten weg.
Zunächst betrachte ich nur die prüfung von Tags, nicht von Geometrie
oder so.
Variante 1:
last-checked-version für jedes Tag in der datenbank.
Kosten: 1 int, typischerweise reicht ein byte pro Tag und Version.
Nachteile:
- Ich kann nicht angeben, wann ich ein Attribut verifiziert habe,
sondern das Datum kommt aus dem changeset, und das kann Wochen oder
Monate später angelegt worden sein als die Datenlage hergibt (z.B. bei
Luftbildern)
Variante 2:
last-checked-date für jedes Tag in der Datenbank.
Kosten: ein Timestamp pro Tag und Version der Datenbank (32bit = 4 byte
reichen bis 2038 aus)
Nachteile:
- mehr Speicherbedarf
Vorteile:
- ließe sich aus dem changeset setzen aber auch überschreiben mit
beliebigen Daten (sollte prüfen, dass keine zukünftigen Daten angegeben
werden können, aber auch das ist machbar)
Egal, welche der beiden Varianten man nutzt (oder eine andere), sind
dadurch noch nicht berücksichtigt:
- Geometrie: müsste sowohl an node und way als auch an Fläche (ich
betrachte Flächen mit Blick auf die Zukunft schonmal als eigenen Typen)
verifizierbar sein, da die korrekte geometrie eines (getaggeten) nodes
in einem way noch nicht darauf schließen lässt, dass auch der way
komplett eine "korrekte" Geometrie besitzt.
Hier wird als zusätzliches Problem aber auftreten, dass wir (bisher) die
Versionsnummer eines ways nicht hochzählen
- "Mitgliedschaft" in Relationen: für ein Relations-Mitglied muss die
Mitgliedschaft sowie die Rolle verifizierbar sein, evtl. auch "nur"
beides zusammen. In manchen Fällen schlimmstenfalls die Geometrie des
Mitglieds, weil die Mitgliedschaft durch eine Geometrieänderung nicht
mehr korrekt wäre etc. (wobei mir dazu außer den Kategorie-Relationen,
die wir ja eigentlich nicht haben wollen, kein Beispiel einfällt;
höchstens noch für Multipolygone, die aber als Fläche betrachtet hier
evtl. rausfallen würden).
Das ist so (noch) nicht praktikabel, aber wenn, dann sind "überflüssige"
default-Werte unser kleinstes Problem, was die Datenmenge angeht.
wobei es schon einen Unterschied macht m.E., ob man foot=yes an einen
footway setzt bzw. motorcar=yes an eine Autobahn, oder ob wir über
tags wie surface, lanes oder oneway sprechen. Erstere finde ich in der
Tat überflüssig, während ich letztere auch mit so geläufigen Werten
wie lanes=2, surface=asphalt oder oneway=no noch halbwegs sinnvoll
finde (oneway=no setze ich in der Regel persönlich nicht, aber in
einem Land wie Italien, wo gefühlt die Hälfte der residentials
Einbahnstraßen sind, hat das evtl. auch seine Berechtigung).
Diese zusätzlichen Tags wird es aber immer mehr geben, und in Bezug auf
den "default", der eben auch einerseits, wie du sagst, nicht eindeutig
ist (z.B. regional unterschiedlich) und andererseits nicht von
ungetagged zu unterscheiden wäre, ist das eben auch ganz sinnvoll.
Wie man das in Richtung der Datenbankbelastung in den Griff kriegt, weiß
ich nicht, aber ich denke, das Problem muss irgendwie gelöst werden,
denn das ewige Argument der Datenbankbelastung ist zwar korrekt, aber
nicht zu vermeiden - die Frage ist nur, wie schnell wächst die Datenbank
und warum.
Es wird der Zeitpunkt kommen, wo wir entweder Mapper verlieren, oder
Mapper sich auf dem bestehenden System Verifikationsmechanismen
ausdenken; und wenn irgendwann an jedem Objekt für jeden Tag a ein
a:verifiedAt="2013-12-02 12:22" und a:verifiedBy="user0815" und
a:verificationSource="survey" dransteht, dann ist die Datenbankbelastung
noch größer.
Gruß
Peter
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
