Landkreise + Idee einer "Stable Map"

Communities Deutschland (Germany)
21

Ich würde gerne dabei helfen, z.B bei der Kontrolle der Grenzstrukturen … allerdings nicht in der Form wie es bisher geht … und den Fehlern hinterherrennen … es müsste ermal die passenden Strukturen in OSM geben, dann wäre ich dabei. Aber ich sehe schon, dass es da wohl in absehbarer Zeit keinen Konsenz geben wird.

Nochmal dann wenigstens mein Vorschlag mit einer geoordneten regelmässigen Diskussion (z.B IRC), wo man wenigstens mal über Ideen diskutiert, diese evt. auch mal ausformuliert und den verantwortlichen Stellen bei OSM mal vorlegt.

22

Es gibt keinen Verantwortlichen bei OSM. Alles was es gibt ist die OSMF eine Dataworkinggroup und Serveradmins. Der meiste Teil davon wird im englischsprachigen Raum zu finden sein.
Aber vielleicht solltest du erstmal abwarten bis der Lizenzwechsel durch ist und außerdem solltest du deine Vorschläge beim Development für die neue API version einbringen. Denn die ist die technische Vorraussetzung dafür.

23

Das wäre schon mal ein Anfang. Die Frage bleibt aber: wo kann man das mit verantwortlichen Leuten mal grundlegend und regelmäßig diskutieren. Wer ist dafür überhaupt verantwortlich bei OSM ?

24

Und ich lese daraus eine gewisse Verzweiflung darüber, daß misterboo unseren Argumenten nicht folgen will :wink: Bleiben wir trotzdem sachlich.

Ich würde mich in der Tat sogar an einem “changeset review” wie von misterboo beteiligen, wenn ich Hoffnung hätte, daß dies in der Praxis funktioniert. Schließlich gehöre ich zu denen, die regelmäßig kaputte Grenzen zusammenflicken, wie hier: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=4.56120&lat=50.55026&zoom=8&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags (OSMI zeigt noch den Stand vor der Reparatur gestern abend).

25

Das funktioniert besser als du denkst:
Ich hab letztes Jahr mal versucht, die Grenzrelation von Deutschland durch eine anders strukturierte zu ersetzen. Dies ist daran gescheitert, dass viele Mitglieder das nicht für ok hielten und massiv Einspruch erhoben haben.
Seit dem ist das Thema vom Tisch und alle sind Happy. (ich übrigens auch, da manche Argumente dagegen verdammt gut waren).
Hier handelte es sich aber um ein angekündigtes Vorhaben.

Und wenn jemand beim Editieren so richtig “Mist” baut, wird das relativ schnell erkannt. Man wird “angeknurrt” und ist danach etwas vorsichtiger.

Gruss
Walter

26

Ich weiß nicht wie lange wir jetzt über diese lächerlichen 4 Relationen diskutiert haben. Aber das Görlitz habe ich schnell geflickt. Offenbar ist das bei der Kreisgebietsreform nicht ganz sauber geglückt. Es fehlte nur ein element und ich habe die Mitglieder auch noch in die Richtige Reihenfolge gebracht.
Gedauert hat das 10 Minuten. Diskutiert haben wir … Minuten.
Siehst du was ich meine? Man kann entweder etwas sinnvolles machen oder aber sich mit sinnlosen Dingen zu erst beschäftigen. Es gibt eine Reihe von Tools die einem die Fehler zeigen. Wenn diese Stören setzt man sich hin und arbeite sie ab.

27

warum tun sich manche so schwer mit einer Diskussion … natürlich ist das keine Diskussion die man in 10 Minuten erledigt. Vermutlich nicht mal in ein paar Tagen, aber soll man deshalb gar nicht darüber diskutieren ? Ich finde es schade wenn man so eine Diskussion so einfach als sinnlos abwürgen möchte.

Natürlich bringt eine Diskussion nicht zwangsläufig gleich eine ultimative Lösung, aber man kann doch mal in Ruhe Ideen diskutieren, ich denke das sollte zu solch einem Projekt genauso gehören wie das Mappen selbst.

Natürlich wird es immer wieder Leute geben, die einen Fehler beheben und wohl in der gleichen Zeit werden wieder 2 neue dazukommen. Es gibt also nie eine stabile Basis außer man macht die für sich selbst ober in Zukunft machen das bestimmt auch Firmen, die die Daten veredeln.

Aber die OSM DB wird immer mehr oder weniger fehlerhaft sein, und ich bin der Meinung, eher mehr fehlerhaft mit steigender Komplexität.

Auch bin ich skeptisch und vermute mal für viele Mapper gilt, dass Mapping spannender ist beim Neuerfassen als bei der Wartung und Korrektur von Fehlern. Die Zukunft wird zeigen, ob da die Mapper genauso motiviert sein werden bei der Wartung der Daten wie beim Neuerfassen.

Ich nehme einfach mal nur jetzt das Beispiel Grenzen:

Ich habe nun so eine tolle Datenbank wie OSM. Ich brauche schnell oder wegen mir auch weniger schnell eine Teilmenge dieser Daten, z.B. die Kreisgrenzen. Diese vollständig zu bekommen ist aber alles andere als trivial.

Und wie man sicherstellen kann wie man diese Daten, vollständig und auch einfach bekommen kann, darüber kann und muss man sich doch auch Gedanken machen.

28

Einige Anmerkungen:

Das Freischalten von Änderungsdatensätzen halte ich derzeit nicht für sinnvoll.

  • Das bindet nur unnötig Kräfte und ist eine ziemlich zermürbende Arbeit, wer will das übernehmen?
  • Die Freischaltung müsste zeitnah erfolgen, damit es nicht zu Frustration bei den Mappern und Konflikten bei den Daten kommt.
  • Oft wird auch lokales Wissen nötig sein, um einige Änderungen beurteilen zu können.
    Ich könnte mir aber vorstellen, das der OSM-Server zuerst die Daten auf offensichtliche Fehler überprüft, bevor er einen Änderungsdatensatz annimmt.
    Wenn z.B. eine vorhandene Grenze durch einen Änderungsdatensatz ausläuft, dann würde dieser Änderungssatz vom Server abgelehnt.
    Dies erfordert aber entsprechende Arbeiten an der API (schon in Arbeit?).
    Außerdem erhöht das die Server-Last, es wird also evtl. noch ein neuer Server benötigt.

Deutschland ist schon ziemlich gut erfasst, so dass sich allmählich eine Sättigung einstellt (der Lizenzwechsel wird das vermutlich nur kurzfristig ändern).
Es ergibt sich also fast zwangsläufig eine gewisse Stabilisierung.
Ich überwache meinen Bereich mit einigen Werkzeugen, wie z.B. http://www.itoworld.com/product/data/ito_map/main?view=130.
Hier gibt es inzwischen nur noch sehr wenige Änderungen, so das der Aufwand gering ist.
Alle Straßen sind mit Namen erfasst, ebenfalls alle Wald- und Feldwege, bis auf vermutlich einige Trampelpfade, die ich nicht kenne, da deren Einstieg zugewachsen oder schwer zu erkennen ist.
Jetzt werden noch die Häuser vollständig erfasst und dann die Hausnummern hinzugefügt.
Und danach bleibt dann fast nur noch das Eintragen von POIs (Geschäfte u.s.w.) und die Ergänzung vorhandener Daten, wie z.B. Wegbeschaffenheit, Wanderwege, Abbiegegebote und Geschwindigkeitsbegrenzungen.

Ich halte also eine lokale und freiwillige gegenseitige Überprüfung für die beste Lösung, ergänzt durch Überprüfungen der Änderungsdatensätze durch den OSM-Server.

Wenn es Probleme mit Änderungsdatensätzen oder Fragen zum Mappen gibt, dann fragt bitte hier im Forum nach oder schreibt einen lokalen (Viel-)Mapper an.
Wir können euch fast immer helfen und auch Änderungen rückgängig machen oder bei der Reparatur von Multipolygonen helfen.

Kommunikation und Kooperation ist hier oft sehr nützlich. :slight_smile:

Gruß,
Mondschein

29

Misterboo, ich denke das ist ein natürlicher Reflex, der auftritt wenn jemand (ich übertreibe) “der keine Relationen editiert uns vorschlägt wie wir uns zu organisieren haben”. Versteh es bitte nicht falsch, aber an der Organisation des projektes wirst du #on oben oder durch Abstimmung nichts ändern.

Was du ja möchtest (und jeder hier gut findet) , ist eine bessere möglichkeit QS hier zu leisten und dadurch mehr leute fü) das Thema zu begeistern. mikel Maron ist gerade auf TALK dabei (siehe WN) Erweiterungen der user Seite einzubauen und ein Dashboard einzubauen. Dort würde sich ein fehlerreport sehr gut machen!

bei uns läuft es nur durch selber machen, leider ist das lokale Aufsetzen eines Rails Ports nicht so leicht, weshalb es viele abschreckt an der Hauptseite zu arbeiten :frowning:

30

Ich kann das aus meiner Erfahrung nicht bestätigen, es kommen hier deutlich weniger neue Fehler hinzu, als entstehen.

Je vollständiger die Datenbank ist, umso weniger Änderungen gibt es und umso stabiler wird diese werden.

Ich vermute, dass die Nutzung der Daten stark zunehmen wird und es dadurch mehr Menschen gibt, denen vorhanden Fehler auffallen und welche ein Interesse daran haben diese zu beheben.

Gruß,
Mondschein

31

Sorry, ich möchte deine Diskussion nicht abwürgen. Aber ich sehe nicht das du auf die Argumente eingehst. Der Weg für dich ist, dass Fehler im Changeset abgelehnt werden müssen. Das Betrifft nur wenige Keys.
Oliwan ist bereit mit zu arbeiten. Macht für die ganze Welt 2 Personen. Macht ihr einen Dienstplan? damit die Änderungen wie heute schnell verfügbar sind? Wenn ich heute schon Nutzer sehe, die verzweifeln weil Mapnik nicht nach 10 Minuten ihre Änderungen zeigt, dann werdet ihr wie auch immer keine Chance haben diese Ansprüche zu erfüllen. Damit scheitert das Projekt immer!
Also dein Beispiel zeigt 4 Relationen die defekt sind. Hey das ist wenn man will ich 20 Minuten erledigt. Das wollte ich damit sagen. Und wenn wieder neue Fehler hinzukommen, dann kann man sich ja mal anschauen ob die immer vom selben stammen. Diesen Nutzer anschreiben ist wesentlich besser, als alle Nutzer perse als Fehlerquelle zu betrachten. Und das bei 20 Changesets mit mehren 100 Objekten auch dem Kontrollteam ein Fehler unterläuft ist denke ich nicht unmöglich oder?
Also ich denke der einzige Weg zu besseren Daten führt über die QS Tools welche die Fehler in den Daten aufspüren und anzeigen. Dann wird es immer wieder Menschen geben, die diese Fehler beheben. automatisiert kann man sowas nicht machen. Denn sonst hätte schon längst jemand einen Bot programmiert.
Welche Möglichkeit also siehst du?
Von !i! angesprochen ist eine automatische Prüfung ob eine geschlossene Grenze geschlossen ist. Das könnte sicher ohne große Probleme bewerkstelltig werden. Allerdings heißt das nicht das die Grenze dann richtig ist.

32

Vorab: Ich hab den Thread jetzt nur überflogen, bitte verzeiht mir das oder ignoriert meinen Beitrag.

Ich denke, grundsätzlich wäre es schon möglich, ‘stabile’ Datensätze anzubieten. In gewisser Weise passiert das ja schon - die Planetfiles sind ja stabile (im Sinne von nicht mehr veränderlich, nicht im Sinne von fehlerbereinigt) Auszüge aus der Datenbank. Was fehlt, ist das, was bei Software nach solch einer Fixierung eben passiert: Es wird nicht nur an dem veränderlichen Zustand für die Zukunft gearbeitet, sondern parallel dazu werden in dem schon festgesetzten Auszug Fehler korrigiert. Das wäre auch bei OSM durchaus machbar: So, wie ab und zu Full-History-Planets veröffentlicht werden, könnte man in regelmäßigen Zeitabständen Planetfiles für ‘stable’ erklären, die dann in einer separaten Datenbank landen. In der würde sich dann ein Team darum kümmern, dass Fehler beseitigt werden und keine neuen dazukommen, z.B. indem Changesets für diese Datenbank individuell geprüft werden. Natürlich müsste auch klar sein, dass Changesets dort nur der Fehlerbehebung dienen sollen. Das Ganze würde dann unabhängig von der eigentlichen Datenbank laufen und irgendwann, wenn der soundsovielte stable-Nachfolger draußen ist, eben aufgegeben werden.
Nur: So etwas wird es denke ich in absehbarer Zeit nicht ‘offiziell’ von der OSMF auf den OSM Servern geben. Zum einen, weil der Betreuungsaufwand wohl enorm wäre, zum anderen, weil man eben ein offizielles Team dafür einsetzen müsste, was nicht jeder gut fände und zu Konflikten führen dürfte.
Andererseits ist OSM sowieso eine do-ocracy, sprich, wenn sich einer findet, der das Ganze, so wie oben beschrieben (oder natürlich auch gerne anders) aufzieht, könnte man es demnächst schon haben. Natürlich erfordert es einiges an Ressourcen, technische wie personelle, aber ich denke, ein engagiertes Team könnte sowas durchaus auf die Beine stellen.
Jedenfalls kann man so ein stable map System meiner Meinung nach am Besten möglichst getrennt von der Hauptdatenbank anfangen und damit muss nicht unbedingt die OSMF tätig werden, um es zu ermöglichen.

33

Meinst du diesen Vorschlag ernst? Ich habe ein Problem damit, wenn Mapper dann damit beschäftigt sind Fehler zu beseitigen und die aktuelle Datenbank davon nicht mehr probiert.
Außerdem muss man sich dann darüber einigen was Fehlerbereinigung ist und was neu ist. Schon wenn man Dinge für das Routing verbessert wird diese Abgrenzung schwierig. Wie wird das dann mit Straßen die nicht mehr befahrbar sind etc. Ist das noch Fehlerbereinigung?

34

Ob ich das ernst meine? Ja, natürlich. Ich meine, ich will nicht sagen, dass sich ein Haufen Leute damit beschäftigen sollten, statt zum aktuellen Datenbestand beizutragen. Aber wir können keinem vorschreiben, was er zu tun hat - und wenn jemand lieber das tun würde, fände ich das in Ordnung. Natürlich geht dadurch Arbeitskraft für die Hauptdatenbank verloren. Dafür hätte man aber auch große Vorteile durch die Bereitstellung stabilisierter Versionen. Ob das nun die Nachteile aufwiegt oder nicht, muss jeder für sich wissen, ich habe nur gesagt, wie ich mir technisch vorstellen könnte, das so etwas funktioniert. Und die Idee, von OpenSource Software zu kopieren, kam ja nicht von mir - und da (und auch bei proprietärer Software) ist es durchaus üblich, dass sich eben Leute um ältere, aber stabilere Datenbestände kümmern, auch wenn sie dadurch nicht zur Weiterentwicklung beitragen. Siehe z.B. die Linux Kernel Versionen, die weiterbetreut werden.
Was Fehlerbereinigung ist, könnte dann natürlich derjenige entscheiden, der das Projekt verwaltet. Deshalb sage ich ja, dass es das wohl kaum offiziell geben wird. Aber wenn ich mich morgen hinsetzen würde und mit so etwas anfangen und meinetwegen Routingfehler beseitigen würde, dann wäre das, was rauskommt, eben eine für’s Routing stabilisierte Version. Wenn jemand anderes andere Ziele hat, kann er die ja ebenfalls verfolgen. Wie gesagt, alles eine Sache derjenigen, die sich die Arbeit machen, und nichts, was man von außen versuchen sollte, zu steuern.

35

Das Team bräuchte dann aber lokales Wissen und müsste dementsprechend groß sein, das erscheint mir kaum möglich.

Evtl. könnte man täglich automatische Routing-Analysen (zumindest bei großen Straßen) durchführen lassen und dann entsprechende Meldungen/Änderungen manuell überprüfen (lassen).

Software-Projekte sind hier kaum vergleichbar.

Gruß,
Mondschein

36

Ich denke man müsste das laaaannnnngggggssssaaaammmm machen.
also zuerst zB: wichtige Grenz und küstenrelationen dann Autobahnen usw.

Ich würde das auf Basis einer automatischen überwachung ob gewisse relationen oder Routings sich verändert haben.
Dies sollte auf einer öffentlichen automatisierten benutzerfreundlichen Homepage zu sehen sein.

Also wenn zum Beispiel einer eine die deutsche Grenze hochlädt und diese ist nachher nicht mehr am Stück könnte doch derjenige (und eingetragene “abbonennten” der Grenzrelation) eine Nachricht erhalten dass diese nun “kaputt” ist.
So hat schon mal der user selbst die möglichkeit seinen Fehler zu fixen.

Und dass sollte langsam ausgebaut werden um die wichtigsten dinge fürs routing zu überwachen.

Damit kann man dann doch öfters eine “teilweise stable map” machen wo man “garantiert” dass gewisse Ziele erreicht wurden.

was haltet ihr davon?
leider bin ich kein programmierer…

37

Das ist ungefair das was OSM Inspector und Keepright schon machen. Nur eben ohne darüber zu benachrichtigen. Und auch nicht auf 5 Minuten aktuell.

38

@Mondschein: Wie gesagt, dass kommt auf die Ziele an. Wenn man nur die wichtigsten, offensichtlichsten Fehler ausbessern will und eventuell in Kauf nimmt, dass nach ‘Korrektur’ eine Stelle vielleicht nicht absolut akkurat, dafür aber routing(-/render-/sonstwas-)fähig ist, muss kein besonderes lokales Wissen vorhanden sein. Wenn man die Plattform so öffnen würde, dass jeder (oder zumindest ein großer Personenkreis) Korrekturen vornehmen kann, die aber von einem Team eben individuell zumindest auf logische Korrektheit und offensichtliche Fehler geprüft werden, müsste dieses Team ebenfalls kein lokales Wissen haben - es würde einfach alles, was nach Verbesserung (im Hinblick auf das gesetzte Ziel) aussieht annehmen und den Rest verwerfen. Das der Maßstab ein anderer als bei Softwareprojekten ist, sollte klar sein, nichts desto trotz halte ich es durchaus für durchführbar, wenn sich da ein paar Leute dahinterklemmen würden (und das Interesse an solchen Datenbankauszügen da ist - aber das wurde ja schon mehrfach bekundet). Im Endeffekt wäre es eben ein Drittanbieterservice. So wie die geofabrik Grenzpolygone bereitstellt oder Leute Karten für bestimmte Zwecke und oder Endgeräte konstruieren.

Und was ich noch an viw vergessen hatte: Es würde ja, geeignete Infrastruktur vorausgesetzt, nichts dagegen sprechen, Korrekturen an der Extradatenbank zur Hauptdatenbank zurückfließen zu lassen (und zwischen den Extradatenbanken für verschiedene Versionsstände). Wenn das relativ schnell läuft, sollte es meist ohne Konflikte laufen, wenn nicht, kann man die immernoch händisch beheben oder in diesem Fall eben die Korrektur verfallen lassen. Nur ein Fluss Hauptdatenbank → Extradatenbank dürfte nicht stattfinden, zumindest nicht ohne jedes Changeset zu kontrollieren und das dürfte wohl viel zu aufwendig sein, bei der Masse an Änderungen an der Hauptdatenbank.

39

Ich habe keine Ahnung welche Vorstellung ihr von der Fehlerkorrektur habt. Entweder gibt es in dem Datenbank auszug nur wenige Fehler, dann sind die Zeitnah schnell behoben. Wenn es aber viele Fehler sind, und damit die Bearbeitungszeit länger ist, besteht die Gefahr, das die Objekte in den anderen Datenständen gar nicht mehr in der Art existieren. Da sind aus Straßen eben Flächen geworden oder aus einer Straße eben zwei als Richtungsfahrbahnen. Wenn wir uns anschauen zu welchen Konflikten es schon kam in der normalen Datenbank als nur wenige hochauflösende Luftbilder zur Verfügung standen, dann ist das denke ich abwegig zu sagen, dass dies hier nicht auftreten wird.
Daher bin ich immer noch der Meinung, dass die Fehler in der eigentlichen Datenbank beseitigt werden müssen, sonst macht man sich die Arbeit zweimal. Und alle die mehr von den Daten wollen, sollen geeignete Methoden finden/anbieten damit es sich ändert.
Die Geofabrik macht das ja auch nicht zum Spaß. Sie verdienen damit Geld. Und den anderen Playern im Boot wird es ähnlich gehen. So trägt jeder seinen Teil zum Ökosystem bei.

40

Auch ich gestehe -wie errt- nicht alles im Detail gelesen zu haben. Aber ich kümmere mich regelmäßig um das Thema DQ [wenn auch mehr im Bereich Tagschreibweise (besonders im Umfeld Adresse)] und auch beruflich habe mit diesem Thema Berüherungspunkte.

Eine der wichtigsten Grundaufgaben im Bereich DQ ist eine Meßgröße festzulegen, um den DQ-Zustand der Daten festzuhalten (einfache OSM-Beispiel: Anzahl der oneway Tags mit unbekannten Werteausprägungen siehe http://www.familieverweyen.de/txt_0054.php)).

Dann muss eine (messbare)Definition festgelegt werden, was einen Datensatz mit gut Qualität (bzw. akzeptabler Qualität) und nicht ausreichender Qualität auszeichnet. Also z.B.: wenn sich bei einer Verwaltungsgrenze (nach Auflösung aller potentiellen Unter-Relationen) eine Menge von in sich geschlossene Wegen bildet, die sich nicht überlappen. (Akzeptabel wäre, wenn die Wege nach einer Sortierung (und ggf. Richtungsänderung) eine solche Menge bilden würden.) [Bewußt vereinfacht dargestellt!]

Danach muss man sich eine Menge der zu messenden Objekte festlegen (z.B. admin_level < x). In den Changeset-Dateien kann man sich dann alle Objekte mit diesem Schlüssel herausfischen und die Kontrolleroutine dazu laufen lassen. Wenn man keine große DB aufbauen will, sollte man sich die notwendigen Daten aktuell aus der Overpass-API organisieren.

Man sollte beachten, dass man natürlich nur entdecken kann, was man auch messen kann bzw. zum DQ-Merkmal bestimmt hat. Wenn sich im obrigen Beispiel zwei Gemeindegrenzen wohlsortiert und überschneidungsfrei abbilden lassen, können sich immer noch die beiden Gemeindegebiete überlappen und dies wäre mit den definierten Messungen nicht erkennbar (Merke: wichtig ist also eine vollständige Definition von guter Qualität).

Wenn erkannt werden soll, dass Daten mit admin_level=x gelöscht werden, wäre dies wahrscheinlich nur durch regelmäßige, resourcen intensive Abfrage aller Verwaltunsggrenzen möglich (Fläche aller Verwaltunsgrenzen mit admin_level=n+1 ist identisch mit der Fläche mit admin_level=n, Anzahl der Objekte reicht leider nicht ganz, denn hier kann es bei Verwaltungsreformen zu zuvielen Fehlalarme kommen). Allein aus diesem Grund wäre es sinnvoll eine lokale Liste (Datentabelle) aller bekannter Objekte mit Ihren Qualitätsmerkmal zu halten, dazu müsste man aber auch alle gelöschten Objekte (zumindestens Relationen und Wege, Knoten entfallen wohl bei diesem Fall), gegen die Liste der bekannten Objekte prüfen.

Mein persönliche Meinung ist, dass man sich nicht unbedingt vor April mit einem sehr schwierigen Variante dieses DQ-Thema beschäftigen sollte.

MfG Georg V. (OSM=user_5359)