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. 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 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...) 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) > 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. 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 [email protected] https://lists.openstreetmap.org/listinfo/talk-de
