Am 30.01.2014 17:09, schrieb malenki:
On 30.01.2014 14:22, gmbo wrote:
Mir persönlich geht es nicht um die Relationen, z.B. Stolpersteine.
Ich versuche zu verstehen warum dieser Overhead so stört. Alles was
wir in OSM einflegen bringt auf der einen Seite einen Nutzen auf der
Anderen stört es.
Bitte nenne einen konkreten Nutzen.
Wie gesagt bei den Stolpersteinen fehlt mir der Nutzen der Relation
selbst auch,
Nachteile wurden bereits aufgezählt.
Am schwerwiegendsten finde ich:
* Die Relationen müssen von Hand nachgeführt werden. Im Gegensatz dazu
liefert eine OAPI-Abfrage immer alle Stolpersteine. Unnützer Mehraufwand
Laut taginfo existieren derzeit 11349 nodes mit
memorial:type=stolperstein
Wenn da niemand draufschaut und ungleiches Tagging angleicht wären auch
das viel weniger.
Die Zahl der in Stolpersteinrelationen gesammelten nodes beläuft sich
auf 8051.
Möchtest du wirklich die 3298 in OSM vorhandenen, aber nicht per
Relation "erfassten" Stolpersteine in Relationen sammeln? Von den noch
zu mappenden Stolpersteinen nicht zu reden.
(Klar, mithilfe der OAPI wäre das einfach...)
Könntest du mir so eine einfache Abfrage, die mir alle z.B.
Bushaltestellennodes listet die nicht in einer bestimmten Relation sind.
Das habe ich bisher nicht hinbekommen.
Die dafür aufzubringende Zeit kann man auch in sinnvolle Arbeit
investieren.
Wenn du die Zeit nicht investieren möchtest: Andere wollen das noch
weniger.
Wenn keiner die Zeit in die Relationenpflege investieren möchte ist
offensichtlich, dass die Sammelrelationen unnütz sind: eine
unvollständige Sammlung gleicher Objekte.
Ein weiterer nicht zu vernachlässigender Punkt:
Relationen gehen gern mal kaputt. Den Zeitaufwand der Reparatur kann
man sich schenken.
Leider bin ich noch nicht so lange im Mapgeschehen, dass ich die
Zusammenhänge, warum die einzelnen Relationen erstellt wurden für
mich nachvollziehbar sind.
Die einzelnen Relationen habe ich nicht tiefer analysiert, aber ich
kann mir vorstellen dass sie zu einer Zeit angelegt wurden, als die
OAPI noch nicht existierte bzw kein so benutzerfreundliches Frontend
hatte wie jetzt.
Jan hat die Relationen ja bis vor kurzen in seiner Karte genutzt.
Das er sie jetzt nicht mehr benötigt sagt aber nicht aus dass die
Relationen nicht von anderen benutzt werden.
Allerdings bin ich dagegen, dass ein paar wenige Nutzer kurzerhand
über wird gebraucht oder nicht entscheiden.
OSM ist eine Do-Ocracy, keine bureaucracy. :)
Das wird die ganze Zeit so gemacht. In OSM werden nicht ständig alle
gefragt, was man wie machen soll bzw. ob das, was man vorhat, korrekt
ist.
Wenn du dir die Beteiligung an Proposal-Abstimmungen anschaust wirst du
feststellen, dass nur ein Bruchteil der aktiven Mapper daran teilnimmt.
Da sind ein paar wenige Nutzer, die über "wird gebraucht/nicht
gebraucht" entscheiden.
Wenn du taginfo durchstöberst wirst du sogar key/value-Kombinationen
finden, die niemand bisher dokumentiert hat. Teilweise entscheiden also
einzelne User darüber, was sie brauchen.
Ein paar Tags, die ich öfter benötige, sammle ich hier:
http://wiki.openstreetmap.org/wiki/User:Malenki/undoc_tags
Denn so kann man auch Daten manipulieren, oder Anwendungen, die dann
mit einem Mal nicht mehr laufen.
Beim konkreten Problem ist deine Befürchtung vernachlässigbar:
Wenn jemand eine Karte für Stolpersteine aufgesetzt hat oder ein Script,
das sich täglich die aktuellen Stolpersteine von OSM holt, dürfte der
Jemand auch die Fähigkeiten haben, diese Daten auch aus der OAPI zu
holen.
Weiterhin hätte er den Vorteil, ein Drittel mehr an Stolpersteinen zu
finden als bisher (siehe oben)
Bei den Stolpersteinen sehe ich das auch so. Wenn sich aber jemand etwas
mit den OSM-Daten programmieren lassen hat, so könnte ein anderer, durch
solche Störungen, diese Anwendung auf längere Sicht lahmlegen.
Wenn so etwas öfter geziehlt passiert, dann sehe ich dort Gefahren.
Und wenn das irgendwann mit den OSM-Daten passiert, dann geht das so
schnell abwärts wie es bisher aufwärts ging.
Gegenbeispiele, die mir spontan einfallen:
landuse=farm weint keiner hinterher
Sogar ein ganze Datentyp wurde entsorgt: Seit API 0.5 gibt es keine
Segmente mehr.
Ein dynamisches Objekt wie OSM sollte dynamisch bleiben.
Stell dir vor, wir behalten die Sammelrelationen für Stolpersteine bei.
Natürlich ist die Flexibilität wichtig,
Die Sammelrelation Stolpersteine war, weil ich sie als vorhanden
vorfand, für mich ein leicht zu verstehendes Beispiel, auf die ich ja
auch verzichten kann, auch wenn ich sie zwischenzeitlich zum direkten
Laden in JOSM nutzte.
Ich war auch der Meinung, dass durch die Sammlung von übergeordneten
Tags in der Relation der Speicherbedarf verringert würde. Auch der
Aufbau mit Eltern-Kindrelationen führt mich in Richtung Sammeln.
Wie gesagt viele Relationen sind sehr änlich aufgebaut.
Mach das Sammeln also nicht von der Stolpersteinrelation abhängig.
Gruß Gisbert
Dann will jemand alle Dinge in der Nähe von Flüssen in Relationen
sammeln (Vor Jahren hatte das mal jemand bei der Donau gemacht).
Der nächste will alle Straßenkreuzungen in $Ortschaft.
Willst du, dass sich der Schwerpunkt in OSM vom Sammeln und Pflegen von
Daten zum Verwalten von Daten verschiebt? /Dann/ sähe ich wirklich
eine Gefahr für OSM. Zum Glück wird sich kaum jemand dafür einsetzen.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
