Hallo,
On 03/01/2012 06:23 PM, Friedrich Volkmann wrote:
Die obigen Regeln sind trivial, die konnte man auch schon vor 2 Jahren
nennen.
Ja; es war mir wichtig, auf diese Weise noch einmal klarzustellen, dass
ziemlich viel eigentlich schon ziemlich lange feststeht. Trotzdem gibt
es genug Leute in Gegenden mit vielen "ganz klar wegfallenden" Objekten,
die sagen: "Remappen kann ich erst, wenn alle Regeln klar sind!". Das
scheint mir unvernuenftig.
Beispiel: Node 389524394. Ein Gipfel, der von einem Ablehner erstellt
wurde, mit natural=peak + name=* + ele=*. Name und Höhe sind
Gemeinwissen (aus jeder Karte abzulesen), die einzige schöpferische
Leistung ist die Position. Die habe ich verändert, indem ich den Node
von der Gipfelkreuzposition zum höchsten Punkt verschoben habe.
Zusötzlich setzte ich ein man_made=survey_point, weil dort ein
Vermessungsstein ist. Was passiert nun bei der Umstellung?
Bei der Umstellung werden mit an Sicherheit grenzdender
Wahrscheinlichkeit keine Unterscheidungen zwischen verschiedenen Tags
("physisch" und "nicht physisch") gemacht werden.
B) Die ursprüngichen Tags werden gelöscht. Auch das ist schlecht, denn
dann bleibt man_made=survey_point und keiner weiß mehr, dass das der
Gipfel ist. Diese Information bleibt aber wenigestens in der History
erhalten.
Vermutlich laeuft es darauf hinaus, weil wir nicht automatisiert
feststellen koennen, ob natural=peak jetzt etwas ist, was jeder
trivialerweise aus PD-Quellen ablesen kann oder nicht. Ausserdem wird
die Information aus der History auf dem OSM-Server verschwinden, d.h.
nur durch Blick auf ein altes History-File oder einen separaten "old
history service" wuerde man an die Info noch rankommen.
D) Alle Tags bleiben erhalten, da name=* und ele=* Gemeinwissen sind. So
ausgefeilt wird das Script aber nicht sein.
Genau dafuer ist odbl=clean aber da. Wenn Du persoenlich der Ansicht
bist, dass name=* und ele=* Gemeinwissen sind und in diesem konkreten
Fall keine Schoepfungshoehe haben, dann kannst Du konkret an dieses eine
Objekt ein odbl=clean dranhaengen. Wenn sich der Nichtzustimmer spaeter
beschwert, werden wir sagen: Laut Auskunft von Friedrich Volkmann haben
Deine Daten keine Schoepfungshoehe, die eine Loeschung begruenden wuerde.
Auf keinen Fall koennen wir pauschal alle ele=* und name=* von Ablehnern
beibehalten, denn es ist durchaus denkbar, dass einige davon nur unter
Aufwendung von 20 Euro Benzingeld feststellbar sind - woher sollen wir
das wissen? Wie gesagt, genau dafuer ist odbl=clean da, damit kannst Du
dem Algorithmus mitteilen "Ich habe dieses Objekt untersucht und bin
nach reiflicher Ueberlegung zu dem Schluss gekommen, dass keine
Schoepfungshoehe vorliegt." Die OSMF wird da im Grunde den Mappern
glauben, aber wenn einer ein odbl=clean an alle Hausnummern eines ganzen
Viertels pappt, fragt sie vielleicht doch mal von sich aus nach.
2b. eine Relation, die von einem Ablehner erstellt wurde, wird
lediglich um
die vom Ablehner eingetragenen Informationen vermindert, aber nicht ganz
geloescht;
Dann wird es viele Relationen ohne type=* und name=* geben. Aber nicht
so tragisch. Relationen lassen sich leicht reparieren.
Relationen, die von Ablehnern erstellt wurden, werden dadurch vermutlich
kaputt gehen und sollten idealerweise im Vorfeld "remapped" werden. Eine
typische Routenrelation, der ein Ablehner mal ein Wegstueck hinzugefuegt
hat, wird so zwar lueckenhaft, bleibt aber im Grunde erhalten.
Weitere Unklarheiten zu Ways:
- Kann ein von einem Zustimmer erstellter Way bei der Umstellung
einzelne Nodes verlieren?
Ja, wenn diese Nodes von einem Ablehner erstellt wurden.
- Was ist, wenn ein Way alle Nodes verliert oder alle bis auf einen?
Dann muss der Way geloescht werden.
- Bleibt ein von einem Zustimmer erstellter Node bestehen, wenn der
zugehörige Way gelöscht wird?
Ja.
Im Fall 3 gibt es ein paar Details, die noch unklar sind. Klar ist z.B.,
wenn der Name einer Strasse von einem Ablehner hinzugefuegt wurde und in
dieser Form immer noch vorhanden ist, wird der Name entfernt. Unklar ist,
was passiert, wenn der Name mittlerweile von einem Zustimmer veraendert
wurde - es koennte sich ja nur um eine Korrektur einer Schreibweise o.ae.
handeln.
Auch wenn es nur eine Korrektur der Schreibweise ist, weiß der
Korrigierende den Namen offenbar besser, d.h. der Name ist nicht nur
abgeschrieben.
Leider nein. Es gibt viele Korrekturen, bei denen z.B. einfach stur
"Strasse" in "Straße" oder "Str." in "Straße" gewandelt wurde oder eine
"Johann Wolfgang von Goethe-Straße" in die
"Johann-Wolfgang-von-Goethe-Strasse". In allen Faellen braucht der
korrigierende Mapper nur einen Duden und kein oertliches Wissen. Im
*umgekehrten* Fall, wenn Nichtzustimmer solche offensichtlich
"mechanischen" Aenderungen gemacht haben, sagen wir in der Regel "keine
Schoepfungshoehe - kein Revert" (qua WTFE-Seite im Wiki, siehe dort z.B.
die zahlreichen "ulfl"-Korrektur-Changesets). Da koennen wir nicht
umgekehrt, nur weil ein Zustimmer im grossen Stil aus einer "Str." eine
"Straße" macht, im alle Rechte am Namen zusprechen!
Was heißt "man kann davon ausgehen"? Hier ist dringendst eine Festlegung
nötig, ob Objekte mit odbl=clean erhalten bleiben.
Der Plan ist, dass Objekte mit odbl=clean erhalten bleiben sollen. Falls
odbl=clean in kleinem Rahmen missbraeuchlich angewendet werden sollte,
so wird man vermutlich sagen "beachte odbl=clean, ausser wenn der Mapper
X es gesetzt hat, dann ignoriere es, denn der hat das ohne Sorgfalt an
ganze Stadtviertel drangesetzt". Es gibt ein gewisses Risiko, dass bei
einer zu grossflaechigen missbraeuchlichen Verwendung von odbl=clean
durch zu viele Mapper irgendjemand sagt "lieber ignorieren wir
odbl=clean komplett, als dass wir danach monatelang Aerger haben". Daher
kann es eine definitive "Festlegung" jetzt noch nicht geben. Aber wenn
die Mapper das odbl=clean fuer den vorgesehenen Zweck einsetzen, dann
wird das auch durchgehen.
(Man muss natuerlich damit rechnen, dass ueberzeugte Ablehner gerade bei
mit odbl=clean getaggten Objekten *besonders* genau hinsehen, ob sie
einen Grund fuer eine Beschwerde finden. Auch das bedeutet, dass
Sorgfalt geboten ist.)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
