Massen-Edits, automatische Edits, mechanische Edits

woodpeck · 2012-04-21 20:40:59

Hallo,

vor ein paar Tagen hat ein langjaeriger und aktiver OSMer, der von vielen wegen seiner hilfreichen Anleitungen geschaetzt wird, mehr als 2000 Forums-Beitraege verfasst hat und auch auf der talk-de-Liste aktiv ist, eine grosse Anzahl von Grenzrelationen eigenmaechtig von type=multipolygon auf type=boundary umgesetzt.

(Die Rede ist von Andre Joost - aber ansprechen moechte ich mit diesem Posting hier alle anderen ebenso.)

Das widerspricht den Spielregeln bei OpenStreetMap, und wer so etwas macht, muss damit rechnen, dass seine Edits revertiert werden, unabhaengig davon, ob, wie im konkreten Fall behauptet, "der Aufschrei sich in Grenzen haelt" oder nicht.

Die Spielregeln sind wenige und entwickeln sich zum Teil auch erst. Im Grunde gilt fuer den einzelnen Mapper, dass er weitgehende Freiheit hat, zu mappen, was er will und wie er es will, solange er dadurch nicht andere stoert (Stichwort historischer Verlauf einer roemischen Strasse quer durch heutiges Wohngebiet) oder objektiv falsche Daten eintraegt.

Diese Freiheit gilt fuer alles, was der Mapper von eigener Hand und mit eigenen Augen erfasst. Editor aufmachen, mit ein paar Klicks ein Objekt erstellen oder aendern, hochladen - davon kann jeder so viel tun wie er will.

Die Freiheit endet dort, wo man nicht mehr einzelne Objekte persoenlich bearbeitet, sondern viele auf einmal, ohne sie sich noch einzeln anzuschauen. Das nennen wir "mechanische Edits" - zum Beispiel: ich lade ein groesseres Gebiet in JOSM, selektiere alle highway=unclassified und mache sie zu highway=residential. Das ist ein mechanischer Edit; ich habe mir die einzelnen Objekte, die ich da aendere, nicht mehr genau angeschaut. Wenn mich spaeter jemand fragt, ob ich die X-Strasse geaendert habe, kann ich nur antworten: "aeh, weiss nicht, das waren glaub ich so 50 Strassen oder so".

Automatische Edits (wenn ich ein Skript schreibe, dass irgendwas fuer mich aendert) und Importe fallen ebenfalls nicht mehr unter diese Freiheit.

Der Hauptgrund fuer diese Regel ist, dass man mit dieser Art von Aenderungen in kuerzerer Zeit mehr Schaden anrichten kann als jemand, der von Hand vorgeht. Und man kann, und das hat Andre im vorliegenden Fall gemacht, seine persoenliche Meinung davon, was wie getaggt sein sollte, anderen, die vielleicht nicht so gut im Skripte-Schreiben sind, aufdruecken, indem man vollendete Tatsachen schafft.

(In einem besonders dreisten Fall in der Vergangenheit hatte jemand zuerst im Wiki geschrieben, amenity=fire_hydrant solle nicht mehr verwendet werden, stattdessen emergency=fire_hydrant; jemand hat das rueckgaengig gemacht mit der Begruendung, amenity=fire_hydrant sei noch kaum in Verwendung. Die betr. Person hat dann kurzerhand weltweit alle amenity= nach emergency= geaendert und gesagt: "schau nochmal nach".)

Solche Aenderungen koennen zwar immer rueckgaengig gemacht werden, aber jede solche Hue-Hott-Aktion sammelt mehr Datenschrott in der Versionshistorie an, erhoeht die Last auf Datenkonsumenten, die diffs verarbeiten und so weiter.

Deshalb gilt die Regel, dass man solche Aenderungen im Detail diskutieren muss, bevor man sie durchfuehrt, und nur weitermachen darf, wenn es keinen nennenswerten Widerspruch gibt.

Der Widerspruch, der auf talk-de *nach* der Aenderung kam, haette gereicht, um die Aenderung zu diesem Zeitpunkt zu verhindern.

Diese Regel gilt nicht etwa nur fuer unerfahrene Neulinge. Im Gegenteil, *gerade* von erfahrenen und angesehenen Mappern erwarte ich, dass sie mit gutem Beispiel vorangehen. Dass sie den anderen vorleben, wie ein Community-Projekt funktioniert und nicht ein Stall voll Eigenbroetlern, von denen jeder glaubt, dass an seiner Weisheit das Projekt nur wachsen kann. Damit sich bei uns eine Kultur etabliert, in der eben *nicht* jeder, der eine Skriptsprache beherrscht, glaubt, die OSM-Datenbank sei seine persoenliche Spielwiese.

Sonst geht das immer weiter mit dem "aber der hat doch auch...". Ich weiss, dass es auch derzeit noch ein paar Altlasten gibt, die nie richtig diskutiert wurden und deren Autoren sich mehr Freiheiten herausnehmen als gut ist (Beispiel Xybot), aber auch die werden wir angehen und auch die muessen sich an die gleichen Regeln halten.

Wiki-Links:

http://wiki.openstreetmap.org/wiki/Mech … dit_Policy
http://wiki.openstreetmap.org/wiki/Auto … of_conduct
http://wiki.openstreetmap.org/wiki/Import/Guidelines

Im konkreten Fall mit den type=boundary-Relationen werde ich nichts unternehmen. Das ist aber nicht im geringsten ein Freibrief fuer Andre oder andere, sowas in Zukunft oefter zu machen. Bitte bringt Euren Mit-Mappern den Respekt entgegen, vor solchen Aktionen mit ihnen zu sprechen.

Bye
Frederik

miraculixOSM · 2012-04-21 21:59:17

Hallo Frederik,

ich finde, hier nichts zu unternehmen, ist das falsche Signal. Gerade weil hier einer der sehr Erfahrenen "mit der Brechstange" versucht, seine Meinung durchzusetzen, ist es meines Erachtens umso wichtiger zu zeigen, dass es so nicht geht. Die von dir angesprochenen großflächigen Änderungen hinzunehmen zeigt doch, dass man/frau nur dreist genug vorgehen muss, um seine Auffassung von einer bestimmten Art Mapping durchzudrücken.:(:(

Meine ausdrückliche Bitte an dich ist also, die von dir angesprochenen Änderungen auch zu revertieren!

kellerma · 2012-04-21 22:13:04

woodpeck wrote:

(In einem besonders dreisten Fall in der Vergangenheit hatte jemand zuerst im Wiki geschrieben, amenity=fire_hydrant solle nicht mehr verwendet werden, stattdessen emergency=fire_hydrant; jemand hat das rueckgaengig gemacht mit der Begruendung, amenity=fire_hydrant sei noch kaum in Verwendung. Die betr. Person hat dann kurzerhand weltweit alle amenity= nach emergency= geaendert und gesagt: "schau nochmal nach".)

Das Beispiel ist unlogisch, wenn, dann muesste es lauten
... jemand hat das rueckgaengig gemacht mit der Begruendung, emergency=fire_hydrant sei noch kaum in Verwendung. ...

Ansonsten haetten ja der "Ummodler" und der "Rückgängigmacher" Hand in Hand gespielt ...

Cobra · 2012-04-21 23:07:09

Die angesprochene fire_hydrant-Geschichte ist ein wunderbares Beispiel für solchen automatischen Unfug. Die meisten Hydranten sind bei Version 5 angelangt, ohne dass wirklich etwas geändert wurde: v1 ist das Mappen vor Ort. Dann kam der angesprochene jemand1 an und hat amenity=fire_hydrant in emergency=fire_hydrant geändert (v2). Dann hat amenity=fire_hydrant wieder hinzugefügt (v3). Dann kam jemand2 und hat eins der beiden Tags entfernt (v4) und danach wieder rangepappt (v5). Da jemand1 ein weit bekannter Gegner der OSMF, der CTs und der ODbL ist, führte das im Nebeneffekt dazu, dass faktisch jeder Hydrant im WTFE-View "gelb" war.

SunCobalt · 2012-04-21 23:07:41

Als ein geläuterter Importeur möchte ich sagen, dass ich das Ziel gut finde. Nicht gut finde ich aber ein paar Sachen, die sich drumrum abspielen. Lass mich mal ein bissl polarisieren damit die Punkte deutlicher werden

1) "this policy is not a voluntary code of conduct, but an official OSMF policy" Das gibt das Mandat der OSMF gar nicht her. Die Regeln von OSM, die bestimmen, was in der Datenbank steht und was nicht, werden durch die Community bestimmt, nicht durch die OSMF, die "nur" unterstützt. Da kann ja stehen "but a community consens that will be enforced" aber die OSMF mit ein paar hundert Mitgliedern hat keine Legitimität zwischen guten und schlechten Uploads zu unterscheiden.

2) "Who is making the change (real name and how to contact...." Was für eine Rolle spielt der Klarname und warum muss der in im OSM Wiki stehen? Ob die Community weiß, dass ich Hans Müller oder John Smith (naja, der nun nicht) bin, spielt für den Import keine Rolle. Wenn es rechtliche Feinheiten gibt, die die Dokumentation von Freigaben erforderlich machen, sollte man das nicht im von jedem editierbaren Wiki machen.

3) Die Übergänge sind fliessend. Was in einem Land noch okay sein kann(weiße Fläche) , ist woanders (bspw Berlin) ein No-Go. An den Regeln, was erlaubt ist und was nicht, wird immer jemand rummeckern....globale Regeln vs lokale Gegebenheiten. Definiert man die Regeln für die Berliner Innenstadt, ist der sauer, der in Afrika ein Shapefile mit 50 Straßen "importieren" will,wo es in OSM nichts gibt. Andersrum geht auch nicht. Blöde Situation

4) Die DWG sollte mMn nicht selbstständig tätig werden sondern auf Anregung aus der Community. Hilfsweise, wenn es keine lokale Community gibt, kann mMn die DWG die Rolle einer lokalen Community einnehmen.

5) Die DWG sollte die Community über die Überwachungssoftware, die scheinbar im (Test)Einsatz ist und die die Changesets aller Mapper untersucht, aufklären.

aighes · 2012-04-22 01:04:03

Die Frage die ich mir stelle ist die: Woran erkenne ich, dass der Edit automatisch erfolgt.

Bsp.:
Ich lösche alle landuses in einer Region. Das kann ich mit josm-Filter, alle markieren, löschen machen. Einfach so weil mir die Karte zu bunt war. Ich kann aber genauso gut jedes einzelne Polygon angeschaut haben, mit der Realität verglichen haben und festgestellt haben, dass dieses Polygon falsch ist. Die changesets sehen in beiden Fällen identisch aus. Unterschied könnte der Kommentar sein. Aber mal ehrlich, da kann ich auch reinschreiben was ich will. Sprich ich könnte Fall 2 schildern und nach Fall 1 vorgegangen sein.

Oder...ein Waldwegemapper hat alle Wege als track erstellt. Nach einiger Zeit bekommt er mit, dass man evtl. auch noch access=forestry dranpappen sollte. Ist es nun ein automatischer Edit, nur weil er alle seine tracks markiert und diesen allen das Tag spendiert?

Tordanik · 2012-04-22 02:22:26

SunCobalt wrote:

1) "this policy is not a voluntary code of conduct, but an official OSMF policy" Das gibt das Mandat der OSMF gar nicht her. Die Regeln von OSM, die bestimmen, was in der Datenbank steht und was nicht, werden durch die Community bestimmt, nicht durch die OSMF, die "nur" unterstützt. Da kann ja stehen "but a community consens that will be enforced" aber die OSMF mit ein paar hundert Mitgliedern hat keine Legitimität zwischen guten und schlechten Uploads zu unterscheiden.

Danke. Dabei ist mir auch unbehaglich, weil es mal wieder so eine schleichende Ausweitung der selbsterklärten Zuständigkeiten der OSMF ist. Die OSMF kann gerne die diesbezügliche Community-Richtlinie umsetzen, aber die "policy" zu etablieren, ist nicht ihr Job.

Was für eine Rolle spielt der Klarname und warum muss der in im OSM Wiki stehen?

Richtig, der Klarname spielt für die Sinnhaftigkeit eines Bot-Edits keine Rolle und ist daher im Sinne der Datensparsamkeit auch nicht zu erheben. Klarnamensverwendung mag auf Mailinglisten üblich sein, aber keineswegs überall in der OSM-Community.

Noch ein paar weitere konkrete Anmerkungen habe ich zur "Mechanical Edit Policy":

Bedeutet "national-language mailing lists" zwingend talk-de etc., oder könnte ich z.B. auch auf der Niederbayern- oder Augsburg-Mailingliste einen Konsens über ein lokales Thema finden? Letzteres halte ich bei regional begrenzten Edits für deutlich besser.
Das empfohlene Anlegen einer Wikiseite ("suggested procedure") ist Overkill. Es gibt nämlich durchaus auch unstrittige Änderungen, die man nach kurzer Diskussion auf den o.g. Kanälen auch als solche erkennen kann.
Es ist eigentlich Konsens, dass die "eigenen" Daten natürlich auch mit Suchen-und-Ersetzen-Funktionen nachträglich korrigiert werden dürfen. Darauf finde ich in der Policy aber keinerlei Hinweis.

Generell finde ich die Richtlinie überbrürokratisch. Genau genommen darf ich dann nicht mal mehr offensichtliche Rechtschreibfehler (traktype=grade4 oder so) flächendeckend korrigieren ohne vorherige langwierige Diskussion. Überhaupt scheint mir die Richtlinie eher auf potentiell kontroverse Riesen-Edits ausgelegt. Aber die Definition trifft, durch die fehlende Berücksichtigung eigener Beiträge, unstrittiger Änderungen und lokaler Aktionen, auch alltägliche Verbesserungen an den Daten und ist daher m.E. zu breit angelegt.

Radeln · 2012-04-22 08:58:32

Hi,

Spielwiese, Spielregeln -> Jeder kann machen, was er will.
Das O in OSM bedeutet für mich, daß jeder mit machen kann und soll, im Gegensatz zu propietären Projekten.

Ersteres ist für mich der verkehrte Ansatz. Weshalb gibt es keine und vor allem eindeutige Regeln für das Mappen. Es gäbe dann mit Sicherheit bedeutend weniger Probleme.
Und, Regeln sind nicht zementiert, können also bei Bedarf angepaßt werden.

BTW, hier wird z.T. ellenlang herumdiskutiert, ohne daß dies sich irgendwo niederschlägt. Auch Aussagen wie: Da muß ein Konsens gefunden werden, aber daran halten brauche ich mich nicht. Weshalb dann Konsens?

Last edited by Radeln (2012-04-22 09:01:27)

geri-oc · 2012-04-22 09:28:05

Wenn ich einen Fehler oder eine andere Tatsache finde, wende ich mich an den Mapper, was er damit bezweckt.
Und ich selbst bin dankbar, wenn mich jemand auf einen Fehler oder vermeintlichen Fehler hinweist. Ein Mapper "vor Ort" kann nur richtig taggen, wenn er seine Fehler kennt. Und "überregional" taggen bringt nur etwas, wenn der Mapper vor Ort informiert ist.
Als Beispiel: Hochspannungsleitungen und -maste
Massen-Edits, automatische Edits, mechanische Edits sollten nur nach den "WIKI-Vorgaben" erfolgen. Gibt es hier "Varianten", sollten diese m.E. als erstes korrigiert werden.

hurdygurdyman · 2012-04-22 09:34:57

Radeln wrote:

Hi,
Spielwiese, Spielregeln -> Jeder kann machen, was er will.
Das O in OSM bedeutet für mich, daß jeder mit machen kann und soll, im Gegensatz zu propietären Projekten.
Ersteres ist für mich der verkehrte Ansatz. Weshalb gibt es keine und vor allem eindeutige Regeln für das Mappen. Es gäbe dann mit Sicherheit bedeutend weniger Probleme.
Und, Regeln sind nicht zementiert, können also bei Bedarf angepaßt werden.
BTW, hier wird z.T. ellenlang herumdiskutiert, ohne daß dies sich irgendwo niederschlägt. Auch Aussagen wie: Da muß ein Konsens gefunden werden, aber daran halten brauche ich mich nicht. Weshalb dann Konsens?

+1
Und noch mal zum Stein des Anstoßes (umtaggen von type=multipolygon auf type=boundary):
In der Wiki steht "In Deutschland, Equador, Kolumbien und in den Niederlanden ist type=multipolygon üblich, sonst type=boundary"
Somit ist auf dem Großteil unseres Planeten type=boundary etabliert, woraus sich eine klare Mehrheit für diese Lösung ergibt. Auch wenn es gute Gründe für type=multipolygon gibt, hat sich die community wohl anders entschieden. Warum soll das dann im Interesse der Eindeutigkeit nicht auch in Deutschland so gehandhabt werden?

Last edited by hurdygurdyman (2012-04-22 09:45:08)

Hobby Navigator · 2012-04-22 14:56:47

Radeln wrote:

...BTW, hier wird z.T. ellenlang herumdiskutiert, ohne daß dies sich irgendwo niederschlägt. Auch Aussagen wie: Da muß ein Konsens gefunden werden, aber daran halten brauche ich mich nicht. Weshalb dann Konsens?

Hallo Josef, Konsens bedeutet ja nicht das etwas von allen Beteiligten getragen werden muss. Konsens als Ziel bei Gruppenentscheidungen (WIKIPEDIA) trifft es IMHO ganz gut. Von dieser Diskussion lebt doch letztendlich OSM, oder?
Georg

Radeln · 2012-04-22 21:43:30

Hobby Navigator wrote:

Radeln wrote:
...BTW, hier wird z.T. ellenlang herumdiskutiert, ohne daß dies sich irgendwo niederschlägt. Auch Aussagen wie: Da muß ein Konsens gefunden werden, aber daran halten brauche ich mich nicht. Weshalb dann Konsens?
Hallo Josef, Konsens bedeutet ja nicht das etwas von allen Beteiligten getragen werden muss. Konsens als Ziel bei Gruppenentscheidungen (WIKIPEDIA) trifft es IMHO ganz gut. Von dieser Diskussion lebt doch letztendlich OSM, oder?
Georg

Von jemand, der den Konsens mit herbeigeführt hat, darf man doch wohl erwarten, daß er sich daran hält. Und genau um darum geht es und nicht darum, daß sich Unbeteiligte daran halten müssen. Letzteres müßte dann durch eindeutige Regeln festgemacht werden.

Betreffs Diskussionen bleibe ich bei meiner Haltung.

g0ldfish · 2012-04-23 15:15:53

Massen-Edits habe ich auch schon gemacht (layer=0 gelöscht) und finde das einerseits nach wie vor vertretbar in dem Sinne, dass das nicht rückgängig gemacht werden muss, würde es andererseits heute eher nicht mehr machen, sondern das Tag nur dann entfernen, wenn ich etwas anderes an einem Objekt hinzufüge oder ändere.

SunCobalt wrote:

1) "this policy is not a voluntary code of conduct, but an official OSMF policy" Das gibt das Mandat der OSMF gar nicht her. Die Regeln von OSM, die bestimmen, was in der Datenbank steht und was nicht, werden durch die Community bestimmt, nicht durch die OSMF, die "nur" unterstützt. Da kann ja stehen "but a community consens that will be enforced" aber die OSMF mit ein paar hundert Mitgliedern hat keine Legitimität zwischen guten und schlechten Uploads zu unterscheiden.
2) "Who is making the change (real name and how to contact...." Was für eine Rolle spielt der Klarname und warum muss der in im OSM Wiki stehen? Ob die Community weiß, dass ich Hans Müller oder John Smith (naja, der nun nicht) bin, spielt für den Import keine Rolle. Wenn es rechtliche Feinheiten gibt, die die Dokumentation von Freigaben erforderlich machen, sollte man das nicht im von jedem editierbaren Wiki machen.

Volle Zustimmung, insbesondere zu 2. Ich will meinen Klarnamen nicht im Netz veröffentlichen und mache den bewusst nur begrenzten Personenkreisen zugänglich, denen ich vertraue (was auch eine Mailingliste sein könnte, aber eben keine mit öffentlich zugänglichen Archiv). OSM ist ohnehin schon ein ziemlicher Spriptease, was Datenschutz angeht . Ist allerdings eigentlich etwas abseits vom Thema, kannst du das vielleicht auch im Wiki anmerken?

monotar · 2012-04-23 17:00:04

Dann gebt halt einen falschen Namen an, es wird schon keiner nach eurem Ausweis fragen. Ist sowieso immer besser, die Leute absichtlich in die Irre zu führen, dann kommt erst recht keiner auf die Idee, dass ihr das sein könntet.

Gruß
Mario

Willi2006 · 2012-04-24 14:43:43

woodpeck wrote:

Und man kann, und das hat Andre im vorliegenden Fall gemacht, seine persoenliche Meinung davon, was wie getaggt sein sollte, anderen, die vielleicht nicht so gut im Skripte-Schreiben sind, aufdruecken, indem man vollendete Tatsachen schafft.

Meines Erachtens ist das dann nicht nur eine Unverschämtheit sondern ein bewusster, gezielter Affront gegen die anders Denkenden. Wären von mir eingegebene Daten betroffen, würde ich dies ohne zu zögern rückgängig machen.

Willi

Radeln · 2012-04-24 16:19:35

Willi2006 wrote:

woodpeck wrote:
Und man kann, und das hat Andre im vorliegenden Fall gemacht, seine persoenliche Meinung davon, was wie getaggt sein sollte, anderen, die vielleicht nicht so gut im Skripte-Schreiben sind, aufdruecken, indem man vollendete Tatsachen schafft.
Meines Erachtens ist das dann nicht nur eine Unverschämtheit sondern ein bewusster, gezielter Affront gegen die anders Denkenden. Wären von mir eingegebene Daten betroffen, würde ich dies ohne zu zögern rückgängig machen.

IMHO genauso unschön, wenn man jemanden in einer Sache vergeblich anschreibt und hinterher feststellen muß, daß in der gleichen Art und Weise weiter gemacht wird.
Man sollte sich in so machen Punkten eben einigen und Festlegungen/Regeln treffen. Dann gäbe es bestimmt weniger Probleme.

Mir fällt da so spontan ein. Manche malen landuse=farmland//meadow um tracks herum, andere bügeln landuse großzügig über Autobahnen, größere Straßen oder doppelgleisige Bahnstrecken. IMHO gehören tracks dazu. Aber was solls, letztendlich sollte dies aber einheitlich gemappt werden und nicht con gusto.
Gerade, wenn eine nicht eingeschworene Gemeinschaft an einem Projekt arbeitet, sind IMHO grundlegende, bindende Regeln erforderlich.

Last edited by Radeln (2012-04-24 16:21:10)

aighes · 2012-04-24 16:29:08

Nehmen wir mal an, der Idealzustand wäre: Jedes Feld ist einzeln auf die Fläche gemappt, auf der tatsächlich Getreide etc. angebaut wird.

Jedoch hat nicht jeder Mapper den diesen Anspruch und in vielen Gegenden ist dieser Anspruch auch nicht unbedingt nötig. Soll man jetzt den Mapper im Iran etc. dazu verdonner, er möge doch bitte gleich alles im Idealzustand eintragen oder es sein lassen?

Radeln · 2012-04-24 16:51:01

aighes wrote:

Nehmen wir mal an, der Idealzustand wäre: Jedes Feld ist einzeln auf die Fläche gemappt, auf der tatsächlich Getreide etc. angebaut wird.
Jedoch hat nicht jeder Mapper den diesen Anspruch und in vielen Gegenden ist dieser Anspruch auch nicht unbedingt nötig. Soll man jetzt den Mapper im Iran etc. dazu verdonner, er möge doch bitte gleich alles im Idealzustand eintragen oder es sein lassen?

Der Anspruch eines Mappers ist also höher zu bewerten als ein einheitliches Mappen?

Willi2006 · 2012-04-25 14:51:10

Radeln wrote:

IMHO genauso unschön, wenn man jemanden in einer Sache vergeblich anschreibt und hinterher feststellen muß, daß in der gleichen Art und Weise weiter gemacht wird.
Man sollte sich in so machen Punkten eben einigen und Festlegungen/Regeln treffen. Dann gäbe es bestimmt weniger Probleme.

Was hat dies mit dem Thema dieser Diskussion "Massen-Edits ..." zu tun?
Oder soll etwa die Tatsache, dass manche auf Anschreiben nicht reagieren oder an Debatten nicht teilnehmen als Rechtfertigung für Massen-Edits und ähnliches herhalten? Überspitzt gesagt: den Teufel mit dem Belzebub austreiben.

gismock · 2012-04-25 14:57:12

Willi2006 wrote:

Radeln wrote:
IMHO genauso unschön, wenn man jemanden in einer Sache vergeblich anschreibt und hinterher feststellen muß, daß in der gleichen Art und Weise weiter gemacht wird.
Man sollte sich in so machen Punkten eben einigen und Festlegungen/Regeln treffen. Dann gäbe es bestimmt weniger Probleme.
Was hat dies mit dem Thema dieser Diskussion "Massen-Edits ..." zu tun?
Oder soll etwa die Tatsache, dass manche auf Anschreiben nicht reagieren oder an Debatten nicht teilnehmen als Rechtfertigung für Massen-Edits und ähnliches herhalten? Überspitzt gesagt: den Teufel mit dem Belzebub austreiben.

Die Diskussionen die hier sattfinden eignen sich weniger einen Konsens zu finden, sie sind mehr eine Zurschaustellung persönlicher Meinungen. Wäre das etwas weniger der Fall würde sich wohl auch mehr Mapper daran beteiligen.

aighes · 2012-04-25 15:40:01

Radeln wrote:

Der Anspruch eines Mappers ist also höher zu bewerten als ein einheitliches Mappen?

Mit Sicherheit ist er das. Es sei denn, man kann auf einige Mapper verzichten, die sich sagen: Das ist mir zu viel Aufwand, da lass ich es halt sein. Trägt ein Mapper aber ein Objekt bspw. nur sehr grob ein, so können andere Mapper dieses Objekt verbessern und gemeinsam nähert man sich immer mehr dem Idealzustand an. So funktioniert OSM. Nicht zwangsläufig so, dass alles gleich beim Eintragen ideal ist.

misterboo · 2012-04-25 16:22:16

aighes wrote:

... und gemeinsam nähert man sich immer mehr dem Idealzustand an. So funktioniert OSM.

Das ist ein Wunsch oder ? Die Realität sieht ja anders aus ... weil es keine Regeln gibt, gibt es sehr oft sehr unterschiedliche Sichtweisen eines Idealzustandes. Je nach Sichtweise gibt es in OSM dann ein Sammelsurium von vielen "Idealzuständen", dazu dann noch eine ansehliche Menge von weniger idealen Sachen. Das macht die Arbeit mit den Daten nicht gerade einfach, denn als Anwender muss man diese vielen Zustände extrem zeitaufwändig analysieren und auswerten. Ich bin auch der Meinung, dass sich Regeln oder noch allgemeiner Grundsätze eines Projektes durchaus auch im Laufe seiner Entwicklung ändern können und auch sollen.

Die Philosophie von OSM mit dem Quasi Motto "jeder kann machen was er will" hat erstaunlich gut funktioniert in der Phase der Neuerfassung von Daten. Irgendwann ist diese Phase jedoch zu Ende und man sollte sich verstärkt der Qualitätssicherung zuwenden. Das könnte durchaus auch bedeuten, dass Tagging Schemas vereinheitlicht werden und sehr viel klarere Regeln definiert werden.

Last edited by misterboo (2012-04-25 16:31:54)

aighes · 2012-04-25 17:05:06

Ja, jeder definiert den Idealzustand anders. Mein Idealzustand bei einer Straße ist Geometrie, highway, name, surface und Zugangsbeschränkungen aller Art. Ich habe aber kein Problem damit, wenn ein anderer Mapper kommt und sagt, mich interessiert surface nicht, dass erfasse ich nicht. Ebenso gibt es Mapper die interessiert auch maxspeed, etc. Diese Mapper müssen aber akzeptieren, dass ich maxspeed nicht eintrage oder ist irgendeinem geholfen wenn ich maxspeed=unknown eintrage, nur damit bei maxspeed ein Wert steht?

Wo willst du die Regel "ideale Straße" nun setzen, die jeder eintragen muss, ohne Ärger zu bekommen? Reichen schon x Nodes um den Kurvenverlauf als korrekt gelten zu lassen oder sollten es doch besser y sein oder gar z?

Ist es nicht besser, die Info zwischen A und B gibt es eine Straße oder hier ist ein Haus in den Daten zu haben als gar keine Info?

misterboo · 2012-04-25 17:19:05

Dein Beispiel ist ein einfaches Beispiel, das meiner Meinung auch keine klaren regeln braucht, es ist ein way getagged mit highway=irgendwas, was da zusätzlich getagged wird ist jedem selbst überlassen und auch der Anwender hat da kein Problem, denn er wählt sich das was er braucht.

Die Problematik z.B. beim Spurmapping oder type = multipolygon vs boundary ist da schon was anderes, denn da muss man als Anwender schon erheblichen Aufwand betreiben um das herauszubekommen was man will.

Ein anderes Beispiel, das ich gerade versuche zu visualisieren sind die POIs aus dem Bereich Education:

http://osm.misterboo.de/education/
http://forum.openstreetmap.org/viewtopic.php?id=16345

Es reicht nicht wenn ich einfach die nodes mit amenity=school suche, da werden Gebäude so gemapped, Flächen der Schulen, das ganze in beliebigen Kombinationen, also teilweise Fläche, Gebäude und noch ein Node mit amenity = school.

Weiter sind die tags recht beliebig verteilt, manchmal nur am node, manchmal nur an der Fläche, manchmal überall.

Dann gibt es auch noch relationen mit amenity=school, dabei auch noch unterschiedliche mit type=site, type=multipolygon und type=collection

Das steht aber nirgends, im Wiki steht nur was von Node oder der Fläche der Schule.

Alles andere muss man extrem zeitaufwenig erst mal analysieren, dann erst mal Programme schreiben um das grob zu analysieren und dann noch mal Programme schreiben, die mit den ganzen wilden taggings umgehen.

Sowas könnte man mit einfachen, klar formulierten Regeln und natürlich auch einem Kontrollsystem für diese Regeln lösen.

Last edited by misterboo (2012-04-25 17:24:41)

fx99 · 2012-04-25 18:14:11

misterboo wrote:

Es reicht nicht wenn ich einfach die nodes mit amenity=school suche, da werden Gebäude so gemapped, Flächen der Schulen, das ganze in beliebigen Kombinationen, also teilweise Fläche, Gebäude und noch ein Node mit amenity = school.
Weiter sind die tags recht beliebig verteilt, manchmal nur am node, manchmal nur an der Fläche, manchmal überall.
Dann gibt es auch noch relationen mit amenity=school, dabei auch noch unterschiedliche mit type=site, type=multipolygon und type=collection
Das steht aber nirgends, im Wiki steht nur was von Node oder der Fläche der Schule.

Leider ist das Wiki noch unterentwickelter als die OSM Daten.
Am Anfang waren die meisten mit einem Node zufrieden, aber mit besseren Luftbildern
kan man auch flächenhafte Objekte erfassen. Was gehört dann zur Schule?

Nur das/die Gebäude, der Schulhof, der Sportplatz?

OpenStreetMap Forum

#1 2012-04-21 20:40:59

Massen-Edits, automatische Edits, mechanische Edits

#2 2012-04-21 21:59:17

Re: Massen-Edits, automatische Edits, mechanische Edits

#3 2012-04-21 22:13:04

Re: Massen-Edits, automatische Edits, mechanische Edits

#4 2012-04-21 23:07:09

Re: Massen-Edits, automatische Edits, mechanische Edits

#5 2012-04-21 23:07:41

Re: Massen-Edits, automatische Edits, mechanische Edits

#6 2012-04-22 01:04:03

Re: Massen-Edits, automatische Edits, mechanische Edits

#7 2012-04-22 02:22:26

Re: Massen-Edits, automatische Edits, mechanische Edits

#8 2012-04-22 08:58:32

Re: Massen-Edits, automatische Edits, mechanische Edits

#9 2012-04-22 09:28:05

Re: Massen-Edits, automatische Edits, mechanische Edits

#10 2012-04-22 09:34:57

Re: Massen-Edits, automatische Edits, mechanische Edits

#11 2012-04-22 14:56:47

Re: Massen-Edits, automatische Edits, mechanische Edits

#12 2012-04-22 21:43:30

Re: Massen-Edits, automatische Edits, mechanische Edits

#13 2012-04-23 15:15:53

Re: Massen-Edits, automatische Edits, mechanische Edits

#14 2012-04-23 17:00:04

Re: Massen-Edits, automatische Edits, mechanische Edits

#15 2012-04-24 14:43:43

Re: Massen-Edits, automatische Edits, mechanische Edits

#16 2012-04-24 16:19:35

Re: Massen-Edits, automatische Edits, mechanische Edits

#17 2012-04-24 16:29:08

Re: Massen-Edits, automatische Edits, mechanische Edits

#18 2012-04-24 16:51:01

Re: Massen-Edits, automatische Edits, mechanische Edits

#19 2012-04-25 14:51:10

Re: Massen-Edits, automatische Edits, mechanische Edits

#20 2012-04-25 14:57:12

Re: Massen-Edits, automatische Edits, mechanische Edits

#21 2012-04-25 15:40:01

Re: Massen-Edits, automatische Edits, mechanische Edits

#22 2012-04-25 16:22:16

Re: Massen-Edits, automatische Edits, mechanische Edits

#23 2012-04-25 17:05:06

Re: Massen-Edits, automatische Edits, mechanische Edits

#24 2012-04-25 17:19:05

Re: Massen-Edits, automatische Edits, mechanische Edits

#25 2012-04-25 18:14:11

Re: Massen-Edits, automatische Edits, mechanische Edits

Board footer