Beides sind privatwirtschaftliche Unternehmen, die jederzeit ihre AGB ändern können. Bei beiden muss man sich registrieren, um auf die Daten zuzugreifen.
Wollen wir das wirklich so haben? Begeben wir uns damit in eine schleichende Abhängigkeit?
Ich könnte gerne auf solche Art Quellenhinweise im Datensatz verzichten, zumal ich es viel sinnvoller finde, die Quellen im Änderungssatz anzugeben, da sich die verwendeten Quellen bei verschiedenen Bearbeitern durchaus unterscheiden können.
Mir ist aufgefallen, dass einige Datensätze die Information mapillary=(einen Schlüssel, wahrscheinlich ein link zu einem Foto) enthalten. Das Tool, mit dem dieser Datensatz bearbeitet wurde, ist Pic4Review.
“For each contribution, survey:date=* and picture tags (either mapillary=, flickr=, wikimedia_commons=* or image=*) is added automatically on OSM feature”
Solange wir keine möglichkeit innerhalb des OSM Projektes haben die Bilder in der Quantität wie Mapillary abzulegen (Und wir hatten hier einen Thread anlässlich der Übernahme von Mapillary durch Facebook) bleibt einem ja nichts anderes.
Und bevor ich keine Informationen habe die ich für andere nachvollziebar anhängen kann mache ich lieber Mapillary oder OpenStreetCam.
Wenn die dann Platt oder unerreichbar sind dann ist der mechanische Edit die Links zu entfernen eher Kleinkram. Wir haben in den USA auch mal die ganzen überflüssigen Tags des Census Bureau imports entfernt. Das geht schon.
Ich sehe das erstmal Leidenschaftslos. Ich hab mir angewöhnt möglichst nichts mehr zu mappen ohne Mapillary Bilder. Zu häufig wird man dann wieder angenölt was das denn alles soll und das wäre doch ganz anders. So Diskussionen kann man dann gleich mit einem link auf ein Bild abwürgen. “Da lieber Blockwart - Hier ist das Faktum”
Ich würde mir auch wünschen das wir so einen Dienst, auch in der Qualität wie Mapillary, innerhalb des OSM Projektes haben. Aber mal einfach auf die veröffentlichten Umsatzzahlen von Mapillary gucken dann wird schnell klar warum das als OSM nicht stemmbar ist.
Sehe ich genau so. Wenn ich Mapillary-Bilder zu einem OSM-Objekt suche, kann ich bei Mapillary mit den Koordinaten suchen. Dann krieg ich auch andere Bilder vielleicht neueren Datums. Ich sehe keinen Mehrwert darin, auf diese Art und Weise nach Mapillary zu verlinken.
Warum muss man sich für seine Tätigkeit hier rechtfertigen? Das ist auch so ein Trend, den ich nicht gut finde.
Ja, den wünsche ich mir auch. Ich habe mal testweise ein paar Bilder zu Mapillary gesendet, aber mir dann doch überlegt, das das nicht so schlau ist. Damit ist man sehr schön trackbar. Position des Fotografen und Zeit werden frei Haus geliefert. Und jetzt kann Facebook das ganze noch wunderbar mit dem anderen gesammelten Daten verbinden. Und auf vielen Fotos sind Dinge drauf, die keinen was angehen.
Aber das war nicht das Thema, sondern:
Muss so ein link zu einem Foto unbedingt an den Datensatz?
Ich habe den mapillary=* Tag schon händisch gesetzt. z.B. bei Wegweisern oder Infotafeln die nicht relevant genug für Wikimedia Commons sind. Solche Bilder kann man prima mit wenig Aufwand auf Mapillary schieben und darauf verlinken.
In dem Fall sehe ich auch einen Mehrwert von einer direkten Verlinkung via Tag, da das verlinkte Bild dann auch das Objekt aus OSM zeigt und nicht nur irgendwas mit ähnlichen Koordinaten.
Ich denke wenn das verlinkte Bild das getagte Objekt “gut” zeigt ist der mapillary Tag anmessen. Leider hat man bei Mapillary oft, dass interessante Objekte nur irgendwo verschwommen im Hintergrund zu sehen sind. Da würde ich dann auch eher drauf verzichten.
Wenn ich Zeit habe muss ich mal schauen wie Pic4Review das handhabt und wie brauchbar die Verlinkungen sind.
Es war schonmal im Gespräch diese IDs optional zu machen. Leider mangelt es wohl an entsprechender Zeit/Unterstützung. Allgemein gibt es Potenzial für Verbesserungen. Adrien Pavie ist da generell auch offen für. Nur umsetzen kann er es wohl nicht immer.
Persönlich mag ich sie jetzt auch nicht so und würde sie lieber in den Changeset-Tags sehen. Aber das passt bei anderen Editoren auch nicht immer so recht. Also würde ich das nicht erwarten.
Mmh, nur am Rande - Relevanz spielt bei Wikimadia-Commons keine Rolle, man soll nur bereit sein die Kategorie-Struktur mit zu granulieren, damit dass ganze auch vernünftig übersichtlich bleibt.
Als Beispiel der erste Link in #7, Rosa-Luxemburg-Straße in Rostock https://commons.wikimedia.org/wiki/Category:Rosa-Luxemburg-Stra%C3%9Fe_%28Rostock%29
Natürlich kann Mapper da ein Bild von oder mit dem footway=crossing hochladen und per image-Tag dann in OSM einbinden.
(und natürlich ist das bei Anbietern mit kommerziellen Interessen möglicherweise “einfacher”)
Die Rosa-Luxemburg-Straße ist ein sehr eindrucksvolles Beispiel, warum diese links zu einem “kommerziellen Anbieter” und auch aus den Wikimedia-Commons m.E.n. nicht an den Datensatz gehören:
Die Straße wird im Moment (seit Juni) umgebaut. Gleise neu verlegt, eine Gleisverbindung ausgebaut, eine Bahn-/Bushaltestelle abgebaut und zwei neue wieder errichtet. Dazu tactile_paving an die neuen Haltestellen. Ampel und Fußgängerüberwege verlegt. Weder die Bilder aus deinem link noch die von Mapillary sind aktuell.
Wenn sich jetzt ein Mapper unaufmerksam die verlinkten Bilder ansieht und und alles “berichtigt”, dann gute Nacht. Nur sinnlose Arbeit von ihm und für einen Anderen, der den richtigen Zustand wieder herstellt. Das klappt schon nicht mit den Luftbildern, wo aus alten Lufbildern schon geänderte Dinge wieder auf den alten Stand zurückge"dreht" wurden.
Wenn jemand meint, das unbedingt dokumentieren zu müssen, dann soll er das im changeset tun. Aber bitte nicht “automatisch” durch ein tool.
In diesem Datensatz wurde ein Foto verlinkt, dass das bearbeitete Objekt überhaupt nicht zeigt.
Das habe ich auch gar nicht behauptet, und ist ein anderes Thema. Einige commos-Hochlader waren offensichtlich aber so schlau, das Aufnahmedatum (zb. 2011-09-10) gleich im Dateinamen zu codieren - eine Technik die ich hier im Rahmen meiner kleinen commons-Werbeeinblendung auch allen Anderen nahelegen möchte (ansonsten findet es sich in Beschreibungstext der Bilddatei).