Vandalismus oder sinnvolle Aktion?

ich hab kein problem damit und hoffe nur der/die/das löschknecht(in) liesst das mit. nochmal ganz klar “ICH BIN NICHT DIE LÖSCHSOCKE

Oh Shift-Taste funktioniert. :sunglasses:

Löschomat hat sich geäußert dass es speziell um die Sammelrelationen von cycling_no ging: https://www.openstreetmap.org/changeset/29870671

Deine Gedanken sind soweit verständlich. Doch um mittels irgend einer Datenbankabfrage ein sinnvolles Ergebnis erhalten zu können, müssen die gewünschten Elemente gemeinsame Kriterien erfüllen. Das mag in manchen Fällen machbar sein (z.B. Radwege 30km um Stadt herum usw.), doch das was eine Relation bietet - ein völlig freier Verbund von Elementen - ist via keiner Datenbankabfrage ohne Hilfskrücke (was eine Relation letztlich ist) umsetzbar. Für den Mapper kann (die höhere Hürde mittels) Overpass genügen, doch eine Relation ist einfacher und mächtiger. Das ideale Tool, und - je nach Fall - auch ohne Alternative.

Da es sich aber um userbezogene (!) Daten handelt, gehören die m.E. idealerweise entweder am Useraccount, oder aber auf dem Rechner des Users gespeichert. In diese Richtung sollte eine Lösung angestrebt werden. Also entweder das Datenmodell der Usertabelle erweitern, oder aber die Editoren integrieren die Möglichkeit eigene Relationen wie Bookmarks zu speichern. Haken hierbei ist allerdings: Wird ein Weg z.B. aufgeteilt, so bekommt der Rechner des Users nix von mit. Hingegen auf Datenabkebene (sprich: speichern an der Usertabelle) wäre das zwar lösbar, aber sicher nicht ohne elendig lange (und somit resourcenhungrigen) Speicheraktionen… Da aber auch aktuell viele beim Mappen nicht unbedingt auf bestehende Relationen sonderlich achten, denke ich, dass der Infoverlust - z.B. beim Aufspalten eines Weges ohne dass die usereigene Relation davon etwas mitbekommt - kein völlig inakzeptables Unding darstellt. Krücke bleibt Krücke.

Ein anderer Gedanke wäre, wirklich einen Relationstyp für das interne Mappen zu definieren - wie hier bereits schon vorgeschlagen. Dazu ein dokumentiertes automatisches Aufräumen, z.B. bei 18 Monaten ohne Bearbeitung. Da es sich ohnehin um Relationen zum damit arbeiten handelt, sollten betreffende Mapper mit einem solchen Deal auch keine Probleme haben. Vorteil dieser Lösung: Technisch wohl eher einfach umsetzbar, und bestehende Arbeitsweisen können fortgeführt werden.

Das wären mal meine ersten Gedanken, um bei dieser Thematik eine Besserung herbeiführen zu können. Schlauer wäre sicher es würden sich jene zu Wort melden, die solche Relationen tatsächlich auch nutzen…

damit der nächste löschtrottel weiß wo er suchen soll?

es gibt mapper, die haben das glück, sich täglich mit osm beschäftigen zu können.
ich glaube nicht, das das die mehrheit ist.
es kann durchaus sein, das der eine oder andere 5 stunden die woche seiner kostbaren zeit für osm abzwackt.

kann es sein, oder habe ich nur den eindruck, das die mapper mit dem glück vom anderen verlangen, das dieser immer auf ihren wissensstand zu sein hat?

mir wurde mal auf den hinweiß hin, das ich keiner fremdsprache mächtig bin geantwortet " englisch lernt man in der schule" .
warscheinlich bin ich zu dumm, oder war zu faul…

grüße von lutz

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