Vandalismus oder sinnvolle Aktion?

ungeachtet der Tatsache, daß ich persönlich Sammelrelationen für unnötig halte, biete ich mich hiermit nach besten Wissen und Gewissen an, mich an einem konstruktiven und zielführenden Dialog zu beteiligen und bei einer Anpassung des Taggings aktiv mitzuwirken. Das Angebot richtet sich auch und insbesondere an unseren User cycling_zno.
Da Frederik aka. woodpeck den Revert nun angekündigt hat, will ich mich einbringen, im Nachgang und im Konsens mit der Gemeinschaft die Datenlage zu verbessern.
Ein etwas ausführliches Angebot geht an cycling_zno per PN direkt.

Sven

Der Revert wurde schon vor mehreren Stunden durchgeführt:
https://www.openstreetmap.org/changeset/29934699

Danke.

Gruß,
Mondschein

Danke!

Da bin ich anderer Ansicht. Ich verwende Sammelrelationen zwar selbst nicht, aber ich halte sie in dieser Form für völlig harmlos. Wenn sie nichts kaputt machen und jemand anders nützen bzw. aktiv genutzt werden sehe ich keinerlei Grund sie zu entfernen.

Anders wäre das, wenn sie bei der Auswertung mit anderen Objekten zu verwechseln wären und zu Fehlern führen oder wenn sie ungepflegt herumliegen und dadurch inhaltlich falsch und irreführend werden. Das läßt sich aber sehr leicht durch ein “Verfallsdatum” regeln, nachdem gelöscht werden darf.

Daß man alles mit Overpass-Queries machen kann, halte ich für eine grundsätzliche Fehleinschätzung. Overpass ist ein verdammt kompliziertes Werkzeug. Ich selber bin ein Poweruser und kann damit umgehen (wenn auch nur unter ständiger Zuhilfenahme der Anleitung), aber ich würde es nie von jemand anders verlangen, so ein Teil zu benutzen. Es bleibt ein Fakt daß die überwiegende Mehrheit der Mapper mit den komplizierteren Power-Tools nichts anfangen kann.

Falls die Idee sein sollte, vorgefertigte Abfragen abzulegen: Wer pflegt die Overpass Abfragen und stellt sicher, daß die nächstes Jahr immer noch alle da sind und sauber laufen? Hier haben wir das gleiche Pflegeproblem. Solche Dienste tendieren außerdem bei OSM dazu auch mal zu verschwinden wenn der/die Treiber das Interesse daran verlieren.

Von daher muß es jedem Mapper selbst überlassen bleiben, welche Tools er sich zutraut und nutzt. Es bringt ihm gar nichts, wenn irgendjemand anders irgendeinen für ihn obskuren Weg kennt, dasselbe zu erreichen.

Keep it simple
Nop

bye, Nop

Grundsätzlich ist unsere Datenbank für Geodaten da.

Manchmal tun wir auch “Metadaten” über unsere Bearbeitung hinzu, z.B. in der Form von “todo”- oder “fixme”-Tags. Das ist dann sinnvoll und geduldet, wenn ein für mehrere erkennbarer Sinn dahinter steckt (“todo=die Straße geht hier noch weiter”); wenn es nur ein einzelner Mapper ist, der sich seine Arbeit auf diese Weise organisiert (“todo=C:\daten\IMG00123.JPG”), dann wird man ihm vermutlich irgendwann nahelegen, das auf eine andere Weise zu tun.

Es gibt kein allgemeines Recht auf private Mapping-Hilfskonstrukte in OSM. Ja, es “muß jedem Mapper selbst überlassen bleiben, welche Tools er sich zutraut und nutzt”, aber daraus folgt nicht, dass jeder Mapper nach Belieben Relationen anlegen darf, weil ihm das ein einfaches “Tool” scheint; es gibt Use Cases, wo ich einem Mapper sagen würde: Wenn Du das nicht ohne eine Privatrelation hinkriegst, dann kannst Du es eben gar nicht machen, sorry. Genauso wie man manchmal jemandem sagen muss: Das, was Du willst, geht eben mit dem Editor, den Du Dir ausgesucht hast, nicht. Das ist genauso ein Fall - wenn Du Dir den komplizierten Editor nicht zutraust, zwingt Dich keiner, aber deswegen alles im Rahmen der reduzierten Möglichkeiten des einfachen Editors zu mappen, kann zu Problemen führen.

Wobei wir hier jetzt im Begriff sind, zwei Sachen zu vermischen. Einmal die Sammelrelationen allgemein - sei es “gotische Kirchen in Bayern”, “deutsche Autobahnen” oder “Stolpersteine in Hamburg” - und ein andermal die von einzelnen Mappern zur leichteren Abrufbarkeit über die API angelegten “Arbeitsrelationen”. Zwischen beiden gibt es eine Überlappung, aber sie sind nicht identisch.

Über die privaten Arbeitsrelationen habe ich oben geschrieben; Sammelrelationen allgemein sind in aller Regel redundant, denn wir wollen ja gern, dass ich an den Tags der Kirche erkennen kann, ob sie gotisch ist und an ihrer Lage, ob sie in Bayern ist, und alles weitere kann dann eine geeignete Datenbankabfrage erledigen. Aber das, so dachte ich, sei weitgehend ohnehin Konsens.

Bye
Frederik

Also Overpassapi Abfragen kann man anpassen, wenn der Bedarf besteht. Hier würde ich vor allem den Mapper in der Pflicht sehen der die Abfragen braucht, sich im Forum oder sonst wo zu melden, das etwas nicht mehr funktioniert und deshalb Hilfe beim Anpassen benötigt wird.

Das jemand das Interesse an Overpass verliert, ist sicher denkbar. Das dieser Dienst deshalb verschwindet eher nicht mehr. Das liegt zum einen daran, dass er bereits bestandteil viele Projekte ist und zum anderen das es bereits mehrere Mirror gibt. Soweit sind noch nicht viele andere Projekte gekommen.

volle zustimmung für woodi. kein mensch würde es tolerieren wenn ein arzt an ihm mit mittelalterlichen werkzeugen (hier SR genannt) rumwurstelt. hier enwickelt man aber lieber verständnis für solche quacksalber (hier erfahrene mapper genannt) anstatt gezielt druck auf die auszuüben. wenn einzelne mapper zu faul oder nicht fähig sind ihre arbeitsweise anzupassen, kann das kein grundsatz sein. hier schimpft man aber lieber über mapper mit “KLEINSCHREIBUNG” (hier pöbler genannt) als sich mit der funktionsweise von aktuellen tools anzufreunden. es gibt sicher für die ewig unbelehrbaren andere themen. waldorf prinzip, irgendwas kann schliesslich jeder, besser ist fördern durch fordern. manchmal tut es halt weh. dinge ändern sich und wer es verpasst sich anzupassen kommt halt unter die räder. so kriegen wir jedenfall alte arbeitsweisen (hier revertieren genannt) niemals raus. oder wollen wir noch jahre mit der “stahlkrise” leben?

Ich fordere DICH hiermit unmissverständlich dazu auf deine Umgangsformen zu überprüfen und den unverzüglich den Gepflogenheiten in dieser Community anzupassen!

full ack.

Mir reicht es auch langsam.

Zum Glück verleiten mich Blocksatz kombiniert mit der “gemäßigten deutschen kleinschreibung” aus den 70’er Jahren dazu, solche Taktrate weitgehend zu überspringen.

Gruss
walter

Es vermischen sich hier verschiedene Dinge. Wir haben in unserer Datenbank noch mehr Metainformationen und Hilfskonstrukte zum Mappen, die alle in Frage gestellt werden können. Dazu gehören z.B. auch Polygone die lediglich die Abdeckung durch bestimmte Luftbildprovider anzeigen.

Ich glaube auch ein gewisses Prinzip “im Zweifel für den Angeklagten” zu beobachten. Z.B. in der Diskussion um Mountainbike-Tags an für Fahrräder gesperrten Wegen. Oder Langlaufloipen, die die meiste Zeit nicht vorhanden sind und bei denen es auch nicht sicher ist, ob sie im nächsten Winter wieder gespurt werden oder falls ja an der gleichen Stelle. Streng genommen keine gültigen Geodaten, aber für manche Mapper interessant, nützlich und pflegenswert. Früher war ich eher der Ansicht alles zu löschen was aus meiner Sicht überflüssig oder unpassend ist. Heute orientiere ich mich daran ob etwas Schaden anrichtet und freue mich wenn so etwas wie der access/mtb Edit war neulich durch tolerante Kooexistenz gelöst werden kann.

Ich sehe ein großes Problem in der Abgrenzung. Wenn wir kleinlich in der Auslegung von Geodaten sind, muß sehr viel entfernt werden was heute zumindest ein paar Leuten nützt. Wenn wir willkürlich in dem einen Punkt kleinlich sind und in dem anderen tolerant gibt es nur Chaos und Streit. Den zielführendsten Ansatz sehe ich in der toleranten Kooexistenz, solange niemand gestört wird und keine Falschinformationen entstehen.

bye, Nop

Da bin ich aus Erfahrung skeptisch. Ich habe im Lauf der Jahre sehr viele Dinge bei OSM gesehen, die jahrelang als feste Größe angesehen wurden und dann eine inkompatible Änderung erfahren haben oder ganz ausgefallen sind. Aus dem Stegreif fallen mir schon ein: die Änderungen an der OSM Hauptseite (URL format), der OSMR und die All-in-one-Karte (keine Updates mehr), OpenLayers (inkompatible Updates), Höhenlinien von srtm2osm (eingestellt), Relation Analyzer (keine GPX Exporte mehr), Kartengenerator Kosmos (eingestellt).

Das waren alles Sachen, denen man hinterherprogrammieren mußte. In einigen Fällen blieb auch eine Forenanfrage ohne hilfreiches Ergebnis, es half nur eine Alternativ/Um/Eigenimplementierung. (srtm2osm, GPX, Kosmos).

Von daher sehe ich es nicht als echte Alternative, sich in Abhängigkeit zu einem Tool zu begeben, bei dem man bei jeder Erweiterung oder Änderung auf fremde Hilfe angewiesen ist.

bye, Nop

danke, du hast mir das osterfest verschönert :slight_smile:

grüße von lutz

Das wäre auch mein Ansatz.
So lange Meta-Informationen/Redundanzen die Datenbank, die Hauptanwendungen und das Editieren nicht spürbar stören, plädiere ich für Großzügigkeit. Nicht immer ist ein tatsächlich vorhandener Nutzen sofort für jeden ersichtlich.
Die Grenze wäre für mich überschritten, wenn die Wohnorte der Tanten erfasst würden oder beim Editieren das Relationen-Fenster immer wieder mit lauter Sammelrelationen zugepflastert würde.

100% Zustimmung!

Auch von mir 100% Zustimmung!

Frohe Ostern…

Sven

Sammelrelationen sind aber eben nun mal auch für andere User ein Problem, nicht einfach nur überflüssig. Sie sorgen dafür, dass gerade neue Mapper mit etwas konfrontiert werden, das sie nicht verstehen. Die meisten werden lieber gar nicht editieren statt etwas zu zerstören. Und weil wohl nur ein Bruchteil der User mit Problemen auch im Forum landet, funktioniert aus meiner Sicht der Ansatz nicht, zu warten, bis jemand über Probleme mit einer bestimmten Reaktion klagt.

Hier haben manche ins Spiel gebracht, dass man dem Pfleger einer Sammlung von Objekten nicht zumuten dürfe, neue Tools und komplexere Abläufe zu erlernen. Aber gilt das nicht erst recht für Mapper, die einfach nur die “gesammelten” Objekte bearbeiten wollen?

Meine Meinung ist daher, dass diejenigen Sammelrelationen, die problemlos mit Overpass-Abfragen zu ersetzen sind, auf solche Abfragen umgestellt werden sollten. Natürlich nicht durch Hauruck-Löschung wie es hier passiert ist, sondern nach ordentlicher Diskussion und Vorlaufzeit. Dass es auch Relationen gibt, die nicht so ohne weiteres durch eine Abfrage ersetzt werden können - geschenkt. Aber deren Existenz sollte uns nicht dazu verleiten, überhaupt nichts zu tun.

das empfinde ich bei den haaren herbeigezogen, denn da müßte ein neuer mapper mit allen relationen probleme haben,
sprich keine wanderwege usw. anfassen aus angst die zu zerstören.

ich habe noch keine sammelrelation gesehen, die sich schwerer oder leichter bearbeiten läßt, als andere relationen.
da wäre ein beispiel ganz recht…

ansonsten schön das du dich für neue mapper einsetzt :slight_smile:

ein vorschlag gab es ja schon, scheint aber bei den gegnern von sammelrelationen keinen anklang zu finden…

grüße von lutz

Klar, neue Mapper haben mit allen Relationstypen so ihre Probleme, das dürfte ja allgemein bekannt sein.

Der Unterschied ist nur, dass wir bei Wanderwegen keine bessere Alternative haben. Bei vielen Sammelrelationen haben wir aber eine. Und ich würde mir wünschen, dass wir diese Alternative auch nutzen.

Danke. :slight_smile: Ich finde es schon immer schwierig, am Stammtisch oder bei Veranstaltungen das Konzept Relation und den Umgang damit zu erklären. Natürlich sind die Sammelrelationen da nur ein kleiner Teil davon, aber wenn man andere Maßnahmen dazunimmt (z.B. die Umsetzung des Area-Datentyps) kann man die Einstiegshürde hoffentlich möglichst klein halten.

Meinst du damit die Möglichkeit, die Relationen im Useraccount und/oder lokal über den Editor zu speichern? Mit dem Ansatz wäre ich auch zufrieden, allerdings hat Joachim das speziell mit denjenigen Sammelrelationen begründet, bei denen es kein computerlesbares Kriterium für eine Abfrage gibt. Mir geht es ja gerade um die einfacheren Fälle, bei denen bestehende Tools schon für eine Abfrage ausreichen.

Ich sehe auch den Einsatz von Overpass als weniger problematisch an, als er von manchen hier beschrieben wird. Die Software ist eine der am besten gepflegten im OSM-Umfeld und wird sicherlich nicht spurlos verschwinden. Mit Overpass Turbo und dem “Wizard” dort kann man grundlegende Anfragen ohne jede Kenntnis der Overpass-Befehlssprache erstellen und bekommt das Ergebnis anschaulich auf einer Karte angezeigt. Und letztlich muss ja nur einer der Nutzer einer bestimmten Sammelrelation die Abfrage erstellen und alle können sie verwenden.

nein, das hört sich kompliziert an.
hätte aber nichts dagegen…

ich meine einen temporären relationstype, bei dem im wiki klar geregelt wird, wann und wie lange er bestand haben darf.
eigentlich schnell und einfach umsetzbar…

der relationstype soll einfach nur helfen projekt-bezogenes arbeiten eines oder mehrerer mapper zu vereinfachen.

grüße von lutz

Kann man in JOSM jederzeit machen:

  • Relation mit Elementen auswählen (rot machen)
  • copy
  • neue Ebene
  • paste
  • als Datei peichern

Nur ist es zugegebenermaßen umständlich.

Gruss
walter