Software zur Überprüfung der OSM Einträge

marek_kleciak · 2011-04-15T10:58:46.000Z

Hallo allerseits,

ein OSM Freund aus Polen bemüht sich die Daten der Tankstellen (GPS Koordinate, Tel. Nr., Öffnungszeiten, Spritsorten, Shop Ja / Nein) zu bekommen.
Die Geschäftsführung ist nicht abgeneigt, möchte aber eine technische Möglichkeit haben, die Änderung der Einträge zu verfolgen und ggf. mutwillige Änderungen rückwirkend zu machen.
Gibt es dafür bereits Wege, oder müsste man dafür ein Tool entwickeln?

Danke im Vorab für Hinweise,

Marek

_i · 2011-04-15T12:57:19.000Z

Hallo Marek,

es gibt einige Tools zur Qualitätssicherung, aber eins das speziell nur ausgewählte Objekte beobachtet ist mir gerade nicht bekannt.
http://wiki.openstreetmap.org/wiki/QA

Ich finde es gut, dass ihr euch um Daten bemüht Allerdings wäre ich mit diesem Verhindern von Änderungen sehr vorsichtig. In Deutschland hat jemand die Daten der Gastankstellen aus einem Portal ergänzt und deren Position waren oft sehr ungenau bzw. schlichtweg falsch da veraltet. Es ist in einem Community-Projekt auch nicht gut zu sagen “Das ist meins!”, denn wir leben ja davon, dass jeder sein Wissen beiträgt und so das ganze Stück für Stück besser wird. Ich denke ein manuelles regelmäßiges Prüfen ob die neuen Änderungen sinnvoll sind, wird leider keiner machen können

errt · 2011-04-15T13:57:46.000Z

Eben. Wenn etwas wirklich falsch geändert wird (z.B. gelöscht, stark verschoben, falsche Tags) fällt das ja auch meistens so jemandem auf, bzw. kann man alle halbe Jahre mal händisch oder halbautomatisch nachprüfen. Sollte jedenfalls möglich sein beim Import die IDs in irgendeiner Form zu speichern und dann ab und zu die entsprechenden Knoten runterzuladen und zu überprüfen.

EvanE · 2011-04-15T14:21:52.000Z

errt:

Eben. Wenn etwas wirklich falsch geändert wird (z.B. gelöscht, stark verschoben, falsche Tags) fällt das ja auch meistens so jemandem auf, bzw. kann man alle halbe Jahre mal händisch oder halbautomatisch nachprüfen. Sollte jedenfalls möglich sein beim Import die IDs in irgendeiner Form zu speichern und dann ab und zu die entsprechenden Knoten runterzuladen und zu überprüfen.

Ein weiteres Problem bei allen flächenhaften Objekten wie Tankstellen ist, dass oft zuerst die Information als Punkt erfasst wird und später die Fläche (Gebäude / Anlage) erfasst wird und die Taggs an dieses neuen Objekte übertragen werden.

Edbert (EvanE)

wambacher · 2011-04-15T15:26:35.000Z

ich glaube, dass sein “Kollege” Probleme in der Argumentierung des “Spenders” der Tankstellen hat. Uns OSM-lern ist schon klar, dass es sich hier um offene, ungeschützte Daten handelt - aber was sagt man dem Spender?

Gruss
Walter

aighes · 2011-04-15T15:33:58.000Z

Meiner Meinung nach sollte man dann eher auf den Import verzichten. OSM ist ein Community-Projekt. Wenn jemand der Meinung ist, den Node in eine Fläche umzuwandeln oder in eine Relation oder was auch immer es in der Zukunft noch geben wird, dann sollte dies möglich sein. Es dürfte aber schwer werden ein Tool zu schreiben, was solche Änderungen erkennt. Wenn man aus einem Node eine Fläche macht, wird der Node in der Regel gelöscht. Manche verwenden ihn auch weiter, dann hat er aber keine Tankstellen-Eigenschaften mehr. Nun wäre es natürlich fatal, wenn dann der Spender mit seinem Tool kommt und den Node wiederherstellt.

Fabi2 · 2011-04-15T15:48:06.000Z

Er darf OSM nicht der Backend-Datenbank seines Webservers verwechseln, wenn er die Daten unverändert geschützt behalten möchte, soll er sie nicht veröffentlichen.

marek_kleciak · 2011-04-15T16:03:32.000Z

Hallo allerseits,
vielen Dank Euch allen für den Feedback. Die Frage der Vertriebskette ist typisch für das Denken der Institutionen die noch nie mit cloud working zu tun hatten. Sicherheit über alles! Man befürchtet in erster Linie Akte des Vandalismus und möchte dagegen gewappnet sein. Natürlich werden diejenige, die für die Qualitätskontrolle der hauseigenen GIS Daten und somit für OSM in einer solchen Firma verantwortlich sind von unseren OSM Freunden dort in die Denk- und Arbeitsweise von OSM eingeweiht, sie werden auch OSM verstehen.

Die Frage bleibt dennoch: Kann ich die Änderungen meiner Dateninhalte verfolgen und beobachten? -wenn ja, wie?

_i · 2011-04-15T16:08:28.000Z

wambacher:

ich glaube, dass sein “Kollege” Probleme in der Argumentierung des “Spenders” der Tankstellen hat. Uns OSM-lern ist schon klar, dass es sich hier um offene, ungeschützte Daten handelt - aber was sagt man dem Spender?

Eine Gute Argumentation wäre sicherlich die Vorteile hervorzuheben:

Die Daten bleiben so “lebendig” und werden aktualisiert
Bisher ist Vandalismus durch bloßes Löschen noch nicht vorgekommen und wird von der Community auch überwacht
Der Worst Case (eine existierende Tankstelle wird gelöscht) kann relativ einfach wie errt erläutert durch gelegentliches Prüfen verhindert werden.
Keiner (auch der Datensponsor) garantiert für die Zuverlässigkeit der Daten.
Daten können auch gespendet werden, ohne diese zum Beispiel auf der eigenen Homepage zu nutzen (also “offizielle” Tankstellen noch mal als seperater Overlay)

Meiner Erfahrung nach, ist die Gefahr durch keine Pflege eigene veraltete Daten zu haben viel größer, als dass in OSM jemand in größerem Maße Schäden anrichtet.

Oli-Wan · 2011-04-15T17:15:26.000Z

marek kleciak:

Die Frage bleibt dennoch: Kann ich die Änderungen meiner Dateninhalte verfolgen und beobachten? -wenn ja, wie?

Ein fertiges Werkzeug dafür ist mir nicht bekannt. Im Prinzip ist es aber sehr einfach: Eine Liste der zu beobachtenden Objekte einschließlich Versionsnummer erstellen (sinnigerweise automatisiert, wenn möglich) und entweder ab und an das Planetfile bzw. einen passenden Extrakt nach diesen Objekten durchsuchen (oder per API die Datenbank abfragen, wenn es nur um sehr wenige Objekte geht) und auf eine Änderung der Versionsnummer überprüfen (und auch auf das Fehlen des Objekts); oder “lauern” und täglich die gleiche Suche in den daily-diffs durchführen. Wenn eine neue Version gefunden wird, Warnung ausgeben oder direkt überprüfen, was geändert wurde. Wenn die Änderung in Ordnung ist, Versionsnummer in der Liste anpassen.

Wenn es nicht gerade ein komfortables Webportal sein muß, ist eine kleine Konsolenanwendung dazu in ein bis zwei Stunden zusammengestümpert.

Es wurde ja schon argumentiert, daß eine solche Überwachung “eigener” Daten im allgemeinen nicht unbedingt im Sinne eines Community-Projektes ist. Nicht daß ein falscher Eindruck entsteht: ich will dem mit diesem Posting gar nicht widersprechen; aber in bestimmten Einzelfällen könnte es dennoch sinnvoll sein. Speziell wenn es nicht darum geht, “seine” Daten gegen fremde Bearbeitungen zu “verteidigen”, sondern bestimmte “besonders empfindliche” oder einem sehr an Herz gewachsene Objekte zu überwachen und deren Änderungen ggf. zu überprüfen. In Wikis gibt es ja auch Beobachtungslisten, u.a. zu genau diesem Zweck.

_i · 2011-04-15T21:10:40.000Z

Ja das stimmt Oli-Wan, ich orientierte mich aber insbesondere an Mareks Beispiel mit den Tankstellen, wo es sich sicherlich um einige Hundert handelt. Wenn jemand seinen Liebings-Radweg in der Weise beobachtet und pflegt (sprich bei fremden Bearbeitungen nachfragt) gibt es da sicherlich wenig dran auszusetzen.

viw · 2011-04-15T21:20:24.000Z

!i!:

wambacher:

ich glaube, dass sein “Kollege” Probleme in der Argumentierung des “Spenders” der Tankstellen hat. Uns OSM-lern ist schon klar, dass es sich hier um offene, ungeschützte Daten handelt - aber was sagt man dem Spender?

Eine Gute Argumentation wäre sicherlich die Vorteile hervorzuheben:

Die Daten bleiben so “lebendig” und werden aktualisiert

Bisher ist Vandalismus durch bloßes Löschen noch nicht vorgekommen und wird von der Community auch überwacht

Der Worst Case (eine existierende Tankstelle wird gelöscht) kann relativ einfach wie errt erläutert durch gelegentliches Prüfen verhindert werden.

Keiner (auch der Datensponsor) garantiert für die Zuverlässigkeit der Daten.

Daten können auch gespendet werden, ohne diese zum Beispiel auf der eigenen Homepage zu nutzen (also “offizielle” Tankstellen noch mal als seperater Overlay)

Meiner Erfahrung nach, ist die Gefahr durch keine Pflege eigene veraltete Daten zu haben viel größer, als dass in OSM jemand in größerem Maße Schäden anrichtet.

Ich verstehe die Ganze Sache nicht. Dort ist ein Anbieter, der eigentlich am Besten weiß wo seine Daten hingehören bzw. wann sich diese ändern. Jetzt will dieser jemand gerne diese Daten (einige hundert) in die OSM Datenbank eintragen lassen. Gleichzeitig möchte er aber sicherstellen, dass in der Datenbank keine Änderungen gemacht werden, welche nicht richtig sind. Andernfalls wird er die Änderung ja akzeptieren.
Ich denke diesem Problem muss sich OSM als Ganzes stellen, wenn wir wollen, dass die Karte auch in produktiven Anwendungen läuft. Andernfalls läuft es nämlich nur auf Hintergrundkarten mit einem Overlay hinaus, wenn ich sicher sein will das die Tankstelle auch morgen noch an dieser Kreuzung steht und um 22 Uhr schließt!
Der Vorteil der Comunity ist vielleicht in Deutschland in Großstädten gegeben. Aber mal ehrlich, wem fällt denn auf das ein User die Öffnungszeiten am Laden vor der Haustür ändert? Im Normalfall doch erst wenn man sich dahinbewegt und vor verschlossener Tür steht. Genau das will der Anbieter hier aber verhindern. Jedenfalls wo es in seiner Macht steht.
Ich denke schon die ganze Zeit darüber nach wie man es vernüftig realisieren könnte, dass einmal eingetragene Läden aktuell gehalten werden, ohne das ich ständig vorbei schaue. Die einzige Lösung bisher ist den Besitzer informieren und hoffen das er sich um seinen Laden kümmert.

Tordanik · 2011-04-15T21:51:29.000Z

viw:

Ich denke schon die ganze Zeit darüber nach wie man es vernüftig realisieren könnte, dass einmal eingetragene Läden aktuell gehalten werden, ohne das ich ständig vorbei schaue. Die einzige Lösung bisher ist den Besitzer informieren und hoffen das er sich um seinen Laden kümmert.

Ich spekuliere mal, dass so etwas am besten zuverlässig aktuell gehalten werden könnte, wenn wir die Eigentümer der Läden/Tankstellen/… in größerem Umfang mit einspannen würden. Die sitzen erstens direkt an der Quelle, während auch ein fleißiger Mapper nicht täglich nach Änderungen der Öffnungszeiten aller Läden schauen kann, und haben zweitens auch ein Interesse daran, dass sie gefunden werden. (Das gilt natürlich erst im vollen Umfang, wenn unsere Karten und Anwendungen als wichtig genug wahrgenommen werden.) Dazu wäre es natürlich nötig, das Eintragen und Aktualisieren auch denjenigen zu ermöglichen, die nicht den vollen Funktionsumfang unserer Editoren beherrschen.

Kurz gesagt: http://www.google.de/places mit anderer Lizenz.

Im aktuellen Fall helfen solche Überlegungen aber wenig. Derzeit halte ich Vandalismus ja noch für eher unwahrscheinlich, so dass es wohl gut wäre, wenn sich der Betreiber von einer optimistischeren Ansicht überzeugen ließe. Etwas problematisch an Beobachtung durch den Betreiber wäre halt auch, dass er vielleicht gar nicht verstehen würde, ob ein Edit sinnvoll ist oder nicht. Würde der beobachtende Mitarbeiter verstehen, dass die Löschung der Tankstelle ok ist, wenn dafür z.B. eine Area oder ein Multipolygon angelegt wird? Verfolgt er Änderungen am Taggingschema mit?
Ansonsten: Ist es rein technisch denkbar, hier mit einer Vielzahl von OWL-RSS-Feeds mit sehr kleiner Bounding Box zu arbeiten?

wambacher · 2011-04-15T22:03:14.000Z

viw:

Ich denke schon die ganze Zeit darüber nach wie man es vernüftig realisieren könnte, dass einmal eingetragene Läden aktuell gehalten werden, ohne das ich ständig vorbei schaue. Die einzige Lösung bisher ist den Besitzer informieren und hoffen das er sich um seinen Laden kümmert.

wenn man eigene db hat ist das ganz einfach:
definier einen sql-trigger, der beim update oder delete eines objektes aktiv wird und die dich interessierenden Objekte rausfiltert.
osmosis macht die schwerarbeit und der trigger der datenbank filtert die kritischen sachen raus.
ca 20-30 zeilen pgsql code. keine änderungen an osmosis.
gruss
walter

p.s. kein java

CREATE TRIGGER oberfoerster
  AFTER INSERT OR UPDATE OR DELETE
  ON ways
  FOR EACH ROW
  EXECUTE PROCEDURE oberfoerster();

CREATE OR REPLACE FUNCTION oberfoerster() RETURNS trigger AS $$

-- 263596 Oberförster

declare ts timestamp;

   BEGIN
      ts = current_timestamp;
      if TG_OP = 'INSERT' or TG_OP = 'UPDATE'
         then
            if (NEW.user_id = 263596 )
            then
               RAISE NOTICE  'Oberförster-Alarm: % way %',TG_OP, NEW.id;                    
               INSERT INTO logfile(dtm, trigger, what, state) values(ts, 'oberförster', NEW.id, TG_OP);
            end if;
      end if; 
      RETURN NEW;  
   END;
$$ LANGUAGE plpgsql;

viw · 2011-04-16T04:15:09.000Z

Tordanik:

Im aktuellen Fall helfen solche Überlegungen aber wenig. Derzeit halte ich Vandalismus ja noch für eher unwahrscheinlich, so dass es wohl gut wäre, wenn sich der Betreiber von einer optimistischeren Ansicht überzeugen ließe. Etwas problematisch an Beobachtung durch den Betreiber wäre halt auch, dass er vielleicht gar nicht verstehen würde, ob ein Edit sinnvoll ist oder nicht. Würde der beobachtende Mitarbeiter verstehen, dass die Löschung der Tankstelle ok ist, wenn dafür z.B. eine Area oder ein Multipolygon angelegt wird? Verfolgt er Änderungen am Taggingschema mit?
Ansonsten: Ist es rein technisch denkbar, hier mit einer Vielzahl von OWL-RSS-Feeds mit sehr kleiner Bounding Box zu arbeiten?

Wenn der Mitarbeiter keine Ahnung hat, dann kann er die Änderung auch nicht alleine Rückgängig machen. Wäre also wieder in Ordnung.

EvanE · 2011-04-16T14:15:54.000Z

Man sollte allerdings auch bedenken, dass die Lage eines Objektes (Geokoordinaten) einem Betreiber nicht immer ausreichend genau bekannt ist. Die Esso-Station in Bonn-Mehlem Mainzer Straße 3 liegt bei der Esso-eigenen Tankstellensuche eine Parallelstraße weiter (Konstantinstraße).

Von daher sind Änderungen an den Koordinaten unvermeitlich.
Ob die Objekt-Koordinaten richtig sind und die Straßen eine falsche Lage haben oder umgekehrt, ist in der Regel nur schlecht einzuschätzen. Da ergibt sich dann schnell die Frage, ob topologisch richtig besser ist als lagegenau. Ich tendiere zu topologisch richtig.

Edbert (EvanE)

aighes · 2011-04-16T17:14:20.000Z

Sehe ich genauso wie Edbert.
OSM ist ein CrowdSource-Projekt, in dem jeder Änderungen machen soll, der meint, dass seine Daten genauer sind, als die vorhandenen. Wenn nun aber ein Spender meint, dass seine Koordinaten die Wahrheit sind und in OSM nicht mehr verändert werden sollen (anders kann man den Wunsch meiner Meinung nach nicht verstehen), dann passt das nicht zusammen.

viw · 2011-04-16T17:45:31.000Z

Hey wer sagte denn, dass der Spender nicht möchte das die Daten richtiger werden? er will bloß bescheid wissen, wenn jemand seine Öffnungszeiten ändert. Zum Beispiel.

marek_kleciak · 2011-04-16T20:04:52.000Z

Danke viv, so ist das: die Geschäftsführung hat uns mitgeteilt, dass lediglich Datenvandalismus verfolgt werden soll. Änderungen, die eine Bereicherung sind, sind gern willkommen.

Dennis_B · 2011-04-16T20:25:15.000Z

Das einfachste, auf Vandalismus zu prüfen ist, wenn man die Nodes als Hyperlinks speichert: http://www.openstreetmap.org/browse/way/23868044

Hier sehe ich auf einen Blick, was Sache ist. Wenn jemand den Node nach “Shell” umbenennt oder die Öffnungszeit auf “16-16:15 Uhr” ändern, oder ihn löscht, sehe ich das.

Wenn Du 100 Objekte hast, die Du alle 1-3 Monate prüfen möchtest, kannst Du Dir eine Seite mit 100 I-Frames machen, wo alle 100 Objekte untereinander angezeigt werden. Das ist ganz einfach: Anleitung: http://de.selfhtml.org/html/frames/eingebettete.htm#definieren

Wenn Du allerdings 1000’de Objekte hast oder die Prüfung Wöchentlich machen möchtest, ist die Lösung kaum mehr möglich.

edit: Unten ist ein Button “Als XML Herunterladen”. Mit den Daten kannst Du eine Software programmieren, welche auf Änderungen hin überwacht.