Benutzer pfwald

Kann mir jemand gerade erklären, was der Kollege gerade macht?

Mir ist er aufgefallen, weil er sämtliche Relationen “Pfälzerwald Weißer Punkt” in eine Riesen-Relation geschmissen hat: https://www.openstreetmap.org/relation/8634239 Das ist bei uns eigentlich nicht üblich, räumlich getrennte Wanderwege in eine Relation zu schmeißen, nur weil sie das gleiche Symbol verwenden (hab aus genau diesem Grund vor nicht all zu langer Zeit einige Relationen in der Gegend aufgetrennt).

Offenbar hat der Kollege innerhalb kürzester Zeit über 100 Changesets produziert. Ich blick da nicht ganz durch, was mir auffällt ist, dass ein Weg nähe Drosselfels-Schwarzfels aus der Pfälzerwald Weißer Punkt-Relation geflogen ist, obwohl der Weg vor kurzem noch so ausgezeichnet war. Weiß jemand, wo seine Quelle für die Änderungen sein mag? Der Kollege editiert mit Potlatch und der Editor füllt source= nicht aus.

Leider verwendet er keine Kommentare, die seine Änderungen beschreiben. Ich habe ihn mal freundlich darum gebeten. Da es auch in der Vergangenheit bereits Probleme durch Änderungen an Relationen seinerseits kam, kann ich nur empfehlen, entsprechende CSs zu kommentieren…

Es ist in vielen Regionen üblich, für räumlich getrennte Wege dieselbe Markierung wiederzuverwenden. Deshalb handelt es sich trotzdem um völlig unabhängige Wege mit unabhängiger Relation.

Umgekehrt sind Sammelrelationen generell nicht erwünscht und eine Sammelrelation unzusammenhängender Wege nach Markierung sinnfrei.

Von daher sehe ich das Löschen der korrekten Wanderwegrelationen als Beschädigung der Daten an (um mal nicht gleich das V-Wort zu benutzen). Die beschriebenen Änderungen sollten schnellstmöglich reverted werden, bevor die Wanderwegrelationen aufgrund anderer Edits nicht mehr wiederherstellbar sind.

Klingt außerdem nach einem Fall den die DWG sich mal näher ansehen sollte.

+1. Inhaltliche Sammelrelationen sind in Einzelfällen tolerierbar (wie die hier kürzlich diskutierten Traumschleifen), aber eine Zusammenfassung von Wegen gleicher Markierung braucht nun wirklich kein Mensch (und wenn doch, lassen sie sich über das symbol-Tag selektieren). Und wenn schon sammeln, dann die Einzelrelationen als members, nicht deren Members zusammenwerfen. Die Löschung der Einzelrelationen macht es unmöglich, sich eine einzelne dieser Strecken z.B. mit rel2gpx herunterzuladen (auch wenn es nur Verbindungswege sind und das kaum jemand machen dürfte, die Möglichkeit muss gegeben sein).

Des weiteren ist „Pfälzerwald Weißer Punkt“ kein Name, sondern eine Beschreibung der Markierung, die aber auch schon im osmc:symbol steht und daher in einem Zweittag hyperfluid ist. Wenn der Weg keinen Eigennamen hat, dann wird keiner eingetragen.

Bitte diesen Müll wegwerfen und dem Kollegen mitteilen, warum.

–ks

Ich hab pfwald in https://www.openstreetmap.org/changeset/63277903 informiert und hierher eingeladen. (War der erstbeste CS, in dem wurde allerdings keine Relation gelöscht.)

–ks

Ich vermute mal, die fragliche Relation bei Drosselfels-Schwarzfels wurde in einem eigenen Changeset gelöscht. Changesets, in denen NUR Relationen gelöscht werden, haben keine Bounding-Box und erscheinen deshalb weder unter “Chronik” noch auf der Slippymap, man muss sie manuell suchen.

gelöschte Relationen lassen sich recht leicht mittels: http://resultmaps.neis-one.org/osm-suspicious?country=184&hours=96&tsearch=&mappingdays=-1&groupby=c&comp=%3E&value=1&action=d&obj=r&filterkey=#5/50.945/9.690 finden. Dann landet man bspw. hier: https://www.openstreetmap.org/changeset/63277114 oder hier: https://www.openstreetmap.org/changeset/63253998

Einunddieselbe Relation in einunddemselben CS ganze neun Mal hochladen, das muss man auch erst mal schaffen :slight_smile: Lässt der seine CS einen Tag lang offen?

–ks

Das liegt dann wohl an Potlatch - anders als beim iD wird der Changeset nach dem Hochladen nicht explizit geschlossen…

Hintergründe für die Vereinheitlichung des Verbindungsweges Pfälzerwald Weißer Punkt.

Zunächst habe ich mich geärgert, dass in Oruxmaps diese Wanderwege nicht angezeigt werden. Ursache war der bei allen Relationen falsche Eintrag osmc:symbol=white::white_round. Wie man hier https://www.wanderreitkarte.de/symbols_en.html sehen kann, ist white an erster Position unzulässig und auch white_round ist als Vordergrund nicht erlaubt. Die verschiedenen Autoren haben vermutlich den Fehler voneinander abgeschrieben.

Nun hatte ich zwei Möglichkeiten, bei allen Relationen das Feld osmc:symbol ändern oder einen Datensatz ändern und allen Wegen als Relation zuweisen. Ich habe mich trotz Mehrarbeit für den zweiten Weg entschieden. Die Entscheidung ist subjektiv-willkürlich und fußt auf der grundsätzlichen Datenbank Maxime: vermeide doppelte Daten!

Der erste Ansatz wäre richtig gewesen: Mehrfache, falsche Tags mehrfach korrigieren.

Mehrere unabhängige Wege zu einer Relation zusammenzulegen hat die Datenstruktur zerstört und muß rückgängig gemacht werden.

Diese Maxime ist in doppelter Hinsicht nicht anwendbar:

  • sie geht in Richtung Normalisierung von Daten, das ist bei OSM grundsätzlich nicht erwünscht, da solche Daten für die meisten Menschen nicht mehr lesbar sind und das dem Crowdsourcing-Ansatz widerspricht.
  • es handelt sich nicht um doppelte Daten, sondern um Attribute unterschiedlicher Entities, die nur zufällig den gleichen Wert haben

Das rein datentechnische Problem besteht darin, dass du nicht einen Verbindungsweg Weißer Punkt geschaffen hast, sondern einen virtuellen, nicht ablaufbaren Weg aus (wenn ich richtig gezählt habe) 34 vollkommen verstreuten, nicht-zusammenhängenden Verbindungswegen Weißer Punkt. Ich sehe nicht, wo da der Sinn liegen soll. Da kann man auch alle Häuser mit der Adresse Hauptstraße 12 zu einem Multipolygon mit entsprechend vielen outers zusammenfassen und argumentieren, dass man so den Straßennamen nicht mehrfach in der Datenbank hat.

Mehrfach in der Realität vorhandene Objekte müssen mehrfach in der Datenbank sein, um die Wirklichkeit abzubilden.

Davon abgesehen ist die Korrektur des Fehlers im osmc:symbol-Tagging natürlich in Ordnung. Nur das Mergen der einzelnen Relationen ist es nicht.

–ks

Das ist eine willkürliche Behauptung die ihren persönlichen Gewohnheiten entspringt. Genau so subjektiv wie meine Entscheidung, zu der ich stehe. Das wird sowieso in jedem Teil der Welt anders gesehen. Über viele Jahre waren die Daten falsch eingetragen und dadurch nicht anzeigbar. Jetzt funktioniert es, fertig.

Das schöne aber ist, jeder darf ändern oder zurück rollen, auch sie. Aber vergessen sie nicht, der richtige Eintrag lautet: osmc:symbol=black:white_round

+1

Ich würde es eher anders sagen: Aufgrund der recht simplen Datenstruktur von OSM ist es schlichtweg nicht ohne weiteres möglich, die Daten zu normalisieren, ohne etablierte und funktionierende Datenauswerteanwendungen (jeglicher Art, auch Karten) komplett über den Haufen zu werfen… Die datenbanktechnisch anzustrebende dritte Normalform wird auch Mittel- bis langfristig nicht möglich sein; nicht zuletzt auch deshalb, weil grundlegende (eigentlich) nötige Geodatentypen in OSM fehlen… Auch fehlt eine vorhandene sinnvolle und auswertbare Datenbankstruktur, um 1:n-Datenbestände zu erfassen und auszuwerten (Kombination aus echten Geo- und Sachdaten)… Mit dem OSM-Hintergrund würde man da aber auch mit Kannonen auf Spatzen schießen…

Sammelrelationen sind da ein absolut falscher Weg, durch diese Krücke wird das wahre Problem nicht gelöst, mit ihnen kann datenbanktechnisch keine wirkliche Normalisierung der Daten erreicht werden…

Es ist auf Grund der Datenstruktur von OSM aber möglich, bei einer sinnvollen Datenerfassung im Rahmen der etablierten Taggingmöglichkeiten und der daraus resultierenden Auswertemöglichkeiten, bestimmte, ausgewählte Daten durchaus gezielt zu modifizieren, ohne Sammelrelationen zu verwenden.

OSM ist mit reinen relationalen Datenbanken die mindestens die dritte Normalform erreicht haben, nicht vergleichbar.

Sven

Off-topic:

Mit einem Entwicklerhut an, gibt das ein kräftiges ARGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!

Wenn man von einem Fehler weiss, dann doch bitte melden, egal ob OSS, proprietär, oder Gott weiss was. Es können nur Fehler (aktiv) behoben werden von dem man weiss.

Ich hab in der Zwischenzeit ein Issue erstellt, und es ist ganz klar, dass das Verhalten so nicht beabsichtigt war und falsch ist, siehe https://github.com/openstreetmap/openstreetmap-website/issues/2020

Mit anderen Worten den Fehler hätte man vor Jahren beheben können, wenn nur jemand Pieps gesagt hätte.

Von diesem Ansatz würde auch ich dir hier bei OSM sofort abraten: eine OSM Relation hat aber auch so rein gar nichts mit einer DB Relation gemeinsam.

Du hast dir doch hoffentlich auch schon das OSM DB Schema zu Gemüte geführt?

Frage, da ich diese App auch nutze und noch nie auf diese Funktion gestoßen bin: wie zeigt man in OruxMaps denn Wanderwegrelationen an? Oder

Nur ein kleiner Hinweis: Siezen ist in der OSM-Community nicht üblich. Tut man es dennoch, wird “Ihren” und “Sie” üblicherweise groß geschrieben. :slight_smile:

Der Fehler ist in der Zwischenzeit behoben.

Was noch offen ist, ist das beabsichtigte weglassen von Members die selbst Relationen sind bei der Berechnung der Boundingbox. Es scheint ursprünglich die Meinung geherrscht zu haben, dass das zu aufwendig ist.

D.h. zum Beispiel, dass aktuell wenn in einem Changeset (nur) eine Masterroute gelöscht wird keine Boundingbox erstellt wird. Ich bin eigentlich der Meinung, dass man durchaus 1 Stufe Relationen berücksichtigen könnte (und ich vermute auch, dass würde auch der grösste Teil der Fälle abdecken).