Hallo Frederik, danke für Deine wertvollen und detaillierten Vorschläge zur Qualitätssicherung! Ich denke, das sind zukunftsträchtige Ideen, die sich möglicherweise schon in den nächsten OSMXapi-Versionen wiederfinden könnten. - Aktuell besteht ja noch keine Notwendigkeit, denn entsprechend sicherheitsbedürftige Daten liegen noch nicht grossflächig vor (aber das kann sich bei der schnellen Entwicklung von OSM ja bald ändern).
_sicherheitsrelevante Objekte_ Mein Wunsch ist es, für sicherheitsrelevante Objekte, beispielsweise ein Leuchtturm für die Schifffahrt, verlässliche Daten zu haben. Meine Idee war, dies über eine besonders sorgfältige - *Qualitätsprüfung bei der Dateneingabe*, und über eine - *red-only*-Funktion der geprüften Daten bei der Datenausgabe zu erreichen. Änderungen an den Daten würden dann genauso wie bei der Dateneingabe die Qualitätsprüfung durchlaufen. Damit wäre gewährleistet, dass Anwendungsprogramme bei sicherheitsrelevanten Objekten nur qualitätsgeprüfte Daten erhalten. Nach aussen würde sich nichts ändern: Der Benutzer sieht im Editor die vorhandenen Daten, ändert sie oder fügt neue hinzu, diese werden geprüft und anschliessend neu angezeigt. > Grundsätzlich halte ich es für gar nicht wünschenswert, > dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit > in die Datenbank einbauen. Warum? > Ich könnte mir aber gut vorstellen, dass man Objekte dadurch "schützt", > dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu "Qualität am Ausgang zu überprüfen" und Ausschuss ggf. wegzuschmeissen). > Checksummen-Algorithmus Das ist ein wertvolles Instrument für die Eingangsprüfung, beispielsweise zum Vergleich mit amtlichen Daten (zur sicheren Prüfung von Abweichungen), oder mit bestehenden Daten (zur Verhinderung von Tippfehlern, versehentliches Verschieben, etc.). > Programme, die Daten auslesen, könnten die Checksumme prüfen > und wenn sie nicht zu den Koordinaten passt, den Node ignorieren > (oder den Benutzer irgendwie warnen). Eine Ausgabeprüfung würde - Daten einzelner Objekte nicht ausliefern (bei Fehlern) - den Download verlangsamen (durch die Prüfung) > sich gegen *absichtliche* Datenänderungen schützen, > "trust"-Weg: Man hat eine Liste von Benutzern, denen man vertraut, > und bei bestimmten Objekten verlässt man sich > ausschliesslich auf diese Leute Das entspricht der von mir vorgeschlagenen "sorgfältigen Eingangsprüfung", und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Qualität bedingt definierte Ziele und Parameter. Sie entsteht durch Menschen, die diese verstanden haben und denen man vertraut diese umzusetzten, verfeinert durch ein "Vier-Augen-Prinzip. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Der Nachteil dabei ist, dass die Eingangsprüfung Zeit braucht, eine Änderung in der DB also nicht in Echtzeit erfolgt. > "Seezeichen-Qualitätskontrollgruppe" mit gemeinsamem OSM-Account > alle Seezeichen prüfen und mit unserem Accountnamen "abstempeln". > und wenn jemand genau unsere abgesegnete Seezeichenkarte > will, wird er beim Download halt alles rauswerfen, was nicht von unserem > Account kommt. Ja, das wäre eine Alternative zu "read-only". Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). > Wir würden zugleich ein Tool a la OSM-Inspector oder OSM > Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von > "unseren" Objekten ändert, um diese Änderung dann auch prüfen und > "abstempeln" zu können. In der Eingangskontrolle wären solche Instrumente sehr effizient. > Krypto-Tokens, basierend auf public key-Kryptographie. Die Anwendung habe ich noch nicht ganz verstanden. Aber ich erinnere mich, dass ECDIS zur Verifizierung ihrer Daten solche Methoden anwendet (aber eher aus ökonomischen Gründen). > Die OSMXapi hat übrigens ein interessantes Feature, das in diese > Richtung geht (siehe > http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein > bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre > "Watchlist" setzen können, und selbst wenn andere Benutzer dieses Tag > entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die > Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, > trotzdem einen "gefilterten" Mirror zu betreiben, der Änderungen nur > dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln > zulässig sind. Das klingt interessant! Und vielleicht sind "gefilterter mirror" ja dasselbe wie "read-only" für einen keinen Bereich von sicherheitsrelevanten Daten.... Gruss, Markus PS: ich verstehe nicht so viel von DB-Design - aber so rein gefühlsmässig erscheint mir eine einzige weltweite OSM-DB einfacher, sicherer und schneller, als mehrere verteilte kleine DBs. _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
