Soweit ich festgestellt habe, ist das Remappen unter UmstĂ€nden sogar einfacher als man denkt, zumindest habe ich bei manchen Sachen, die ich auch selbst besucht hatte und wo ich keine Lust auf groĂartiges Neuabmalen der Geometrien von Bing hatte, dann einfach odbl=clean gesetzt, wenn die history dies zulieĂ (Beispiel: Ein Einkaufszentrum wurde nur mit shop=mall + name=* vom Ablehner getaggt, und dann hatte ich da z.B. frĂŒher schon die opening_hours=* hinzugefĂŒgt, und andere Zustimmer evtl. noch weiter Tags, dann hab ich das auf odbl=clean gesetzt, weil das neu von Bing abmalen und die Tags der Zustimmer kopieren war mir dann einfach zu blöd, nur damit die Geometrie von einem Zustimmer stammt, ja da waren ich und weitere Leute vor Ort und wir wissen auch wie die Mall heiĂtâŠ). Das sollte in dem Fall aus meiner Sicht möglich sein.
In diesem Fall ist das odbl=clean völlig richtig, weil die Geometrie nicht von ihm stammt. Das daneben befindliche Wohngebiet âGut Koltenhagenâ könnte mit etwas Ortskenntnis (unabhĂ€ngige Datenquelle) auch gecleant werden.
Es gibt einen norddeutschen Lizenzablehner, der die Lizenz abgelehnt hat, weil er die Kartennutzer gerne selbst verklagen möchte. Aber in diesem Fall stehen seine Chancen wohl schlecht.
Das ist ein etwas merkwuerdiges Rechtsverstaendnis. Nur weil du von anderen Leuten erzeugte Daten auf Korrektheit kontrollierst, hast du ploetzlich das Recht, die Lizenz fuer die fremden Daten zu veraendern?
Mir ist die Situation aus der Beschreibung von Fabi2 noch nicht ganz klar: Wenn der Nichtzustimmer wirklich nur name=* und shop=mall hinzugefĂŒgt hat, warum sollte man dann etwas tun mĂŒssen, âdamit die Geometrie von einem Zustimmer stammtâ. Dann tut sie das ja doch schon?
@Torsten: Wenn tatsĂ€chlich nur name=* und shop=mall hinzugefĂŒgt wurden und man weiĂ diese beiden Informationen auch, wo ist das Problem mit odbl=clean? Was fĂŒr ein Unterschied besteht zu dem Vorgehen, das Objekt zu löschen und mit neu eingetippten Tags neu anzulegen (auĂer dass das mehr Arbeit macht)? Oder willst du das letztere Vorgehen auch verbieten, und wenn ein Nichtzustimmer âErsterâ war beim Editieren, hat der fĂŒr alle Zeiten das alleinige Recht auf diese Informationen (in besagtem Fall auch noch ziemlich triviale) und es darf niemals jemand mehr dieselben Informationen in die Karte eintragen?
Um es klarzustellen: im Prinzip wird der technische Umstellungsprozess odbl=clean berĂŒcksichtigen.
Der Fall Geometrie (ausgedehntes Objekt mal angenommen) von einem Ablehner, Tags von Zustimmern ist aber -nicht- ein Fall wo dieser Tag hingehört, sondern ein solches Objekt sollte neu erstellt werden.
Abgesehen davon, dass ein Picasso sicher etwas qualitativ völlig anderes ist als zwei Trivialfakten: In dem beschriebenen Fall war es doch nach meinem VerstĂ€ndnis so, dass der odbl=clean -Setzer das nicht nur âgekonnt hĂ€tteâ, sondern wirklich unabhĂ€ngig von den aus Nicht-CT-Quelle stammenden Informationen wusste, d. h. um im Bild zu bleiben: Er konnte es tatsĂ€chlich und die AusfĂŒhrung wĂŒrde ihn auch nur wenige Sekunden kosten, nicht Stunden wie bei einem GemĂ€lde. Insofern ist hier odbl=clean doch angemessen. Etwas anderes wĂ€re es, wenn ohne eigene Kenntnis nur auf korrekte Schreibweise der Tags o. Ă. geschaut worden wĂ€re.
Hallo,
nach langer Zeit, hat mich das GefĂŒhl gepackt Schau mal was bei OSM so los ist, und ich lese das mit der Umstellung nur noch ein paar tage dauert.
Ich selbst habe schon vor lÀngerer Zeit zugestimmt aber es gibt ein Mitglied in meinen Bereich das hat nicht (noch nicht ) zugestimmt.
MuĂ ich da noch was unternehmen? Seine Sachen liegen auch wohl schon Jahre zurĂŒck
aber wie sehe ich ob es was wichtiges ist ?
Es geht um den Mapper Rudiger
Danke fĂŒr eine Antwort
GruĂ
FĂŒr alle, die sich ebenfalls fragen, ob die Datenbank morgen nun wirklich offline/read-only geht oder nicht, folgende zwei Postings von der Rebuild-Liste (von heute):
Wir laborieren seit mehr als einem Jahr am Lizenzwechsel, da kommt es auf ein paar Tage mehr wirklich nicht darauf an. Wenn der Lizenzwechsel in den ersten zwei Wochen des April 2012 abgeschlossen ist mir das frĂŒh genug.
Lieber eine paar Tage zusĂ€tzlich und dafĂŒr ordentlich als schnell, schrottig und deswegen zweimal gemacht. Das Ende ist ja im Wochenbereich abzusehen.
Meiner Meinung nach sollte man sich nach Auswertung der Tests einen Tag Pause gönnen, damit das alles noch einmal sacken kann, bevor man die Umstellung real durchfĂŒhrt.
Seh ich auch so! Wenn man die Aktion so halb auf Zuruf (So Admins, jetzt macht mal, hier ist der Plan⊠;)) sieht (meine Interpretation aus ein paar Posting auf der Rebuild-Liste), dann denke ich mal, das vor Mitte April der Wechsel nicht real durchgefĂŒhrt wurde. Bestenfalls haben wie in ein paar tagen vielleicht kurz nach dem 1. April dann ein funktionierende Redationssystem und wenn das halbwegs lĂ€uft, dann können im Hintergrund die Nichtzustimmer-Daten weggerĂ€umt werden. Ich kann nicht wirklich Ruby aber nach dem was ich bisher gesehen habe, fehlt in den TestfĂ€llen z.B. auch noch der Fall des Abfangens von nachtrĂ€glichem Gespiele an odbl=clean. Morgen gibt es vielleicht einen neuen Plan von der LWG bzw. stellt man zumindest fest, das man jetzt endlich anfĂ€ngt⊠Ja es ist aus meiner Sicht gut, daĂ man das jetzt vorantreibt, aber so schnell wie sich eineige Nichttechies das vielleicht vorstellen, wird es bestimmt nicht gehen.
Ein âlive rebuildâ (auch âsoftâ cutover genannt) ist wahrscheinlicher geworden, da der Neuaufbau der Datenbank langsamer ist, als bisher angenommen.
Damit möchte man die Ausfalldauer reduzieren.
Zuvor wird es möglicherweise einen Umzug der Datenbank auf den neuen Datenbankserver geben (da gab es im letzten Jahr die Spendenaktion), dies wird eine Ausfallzeit verursachen.
Dieser Umzug ist möglicherweise auch etwas aufwÀndiger: http://lists.openstreetmap.org/pipermail/rebuild/2012-March/000153.html
DafĂŒr wird dann der Neuaufbau der Datenbank auf dem neuen Server vermutlich schneller ablaufen.
Die Diffs wird man evtl. vor dem Beginn der Umstellungsphase abschalten und danach wieder unter einer neuen Adresse zur VerfĂŒgung stellen, damit die Diff-Konsumenten nicht unvorbereitet eine Datenbank mit Löchern vorfinden und um klarzustellen, dass ab dann eine neue Lizenz aktiv ist.