OpenStreetMap Forum

Ja, aber 21% der Edits, also hat Oli-Wan schon recht. Zwar ist die Nutzerbasis von Potlatch zugegebenermaßen groß (u.a., weil eben praktisch jeder mindestens mal am Anfang damit ein Changeset gemacht hat), dafür ist aber die Changesetgröße sehr gering.

Sollte in erster Näherung mit ähnlichen Bedingungen wie bei den Tags gehen: Z.B. wenn ein anderer Weg, der den Knoten enthält (und möglicherweise alle Tags), Mitglied der gleichen Relationen ist.

Mittlere Maustaste gedrückt halten

Kommentare zu deinen 3 Szenarien:

1. Dieses Problem lässt sich auf jeden Fall vermeiden, indem man nur taglose 1NW löscht. Das sind zwar nur ein Teil aller 1NW, aber zumindest ein Anfang. Für die anderen könnte man überlegen, die Tags an den Knoten zu übertragen. Selbst wenn es sich um Tags für Wege handelt, kann das sinnvoll sein - Information geht keine verloren, QA-Tools können das anzeigen.
2. Halte ich für irrelevant. Entweder gibt es einen Mapper, der an dieser Stelle bereit ist, Straßen einzuzeichnen, dann wird der das auch tun, wenn da kein 1NW sitzt, oder es gibt keinen, dann wird auch niemand den 1NW verbessern.
3. Hier könnte es helfen, die Wege nicht zu löschen, wenn sie zuvor aus mehreren Knoten bestanden. Eventuell könnte man sie (bzw. nur ihre Geometrie) dann auf den letzten Stand mit mehr als einem Knoten zurücksetzen, das sollte normalerweise nicht schaden - sie waren ja auf diesem Stand schon mal in der DB und falscher als ein 1NW kann es auch kaum sein. Und wenn es Gründe für eine Änderung gibt, dann sind sie dann zumindest wieder leichter in Karten oder im Editor sichtbar.

Von meiner Seite also: Ja, sinnvoll.

Wobei die angesprochenen Dinge ja durchaus stimmen, also die Tatsache, dass wir das auf einem anderen Abstraktionslevel mappen als Straßen, weshalb z.B. Bahnübergänge eher ungünstig sind aktuell und dass für viele Zwecke das Rendern einer Linie völlig ausreicht (auch wenn das durchaus, wenn auch eher aufwendig, wohl aus den aktuellen Daten geht).

Vorschlag für den Anfang: Nur dann den ersten Buchstaben kleinschreiben, wenn danach keine Großbuchstaben mehr kommen. Während es durchaus Sinn machen kann, Abkürzungen auch in keys groß zu schreiben sollte [A-Z][a-z]* eigentlich immer falsch sein, weil es einfach nicht den allgemeinen Regeln entspricht, selbst wenn es vielleicht in einem Proposal in dieser Form angenommen worden wäre.

Du vertust dich Das untere kann ja schlecht Fußgänger AND Radfahrer sein, sonst müsste man ja zugleich Fußgänger und Radfahrer sein. Das ist ganz offensichtlich (Fußgänger OR Radfahrer) AND NOT Fußgänger. Und das ist natürlich identisch mit dem Ergebnis aus der Mengenlehre, da (B, ∧, ∨, ¬) isomorph zu (M, ∩, ∪, \) ist

@malenki: Der Link stammt nicht von mir

@Netzwolf: Scheint sich mir aber eher auf Wohngebäude zu beziehen, was auch zu den Zahlen von Simon und malenki passen würde - aber wir erfassen ja eben noch wesentlich mehr Gebäude, insofern sind wahrscheinlich Simons 36 Mio. halbwegs realistisch, wenn nicht noch deutlich zu wenig. Also hätten wir höchstens etwa 25% erfasst.

Ansonsten auch von mir +1 für Siedlungsgrenzen.

???

Was spricht denn gegen die Herren Altenburger? Der Herr Basler ist sogar recht bekannt. Und beim Namen Bremer ist die Liste sogar ziemlich lang. Um die drei Beispiele zu finden hab ich ganze 4 Namen aus der Liste abgetippt, nur zu Altenberger hatte die Wikipedia auf die Schnelle nichts bereit. Also so ganz einfach scheint mir die Sache nicht zu liegen

Apropos Berlinerstraße: Wer sagt eigentlich, dass damit nicht dieser Berliner gemeint ist?^^

Strichpunkt wäre eher der Verwendung bei anderen Tags entsprechend.

Ich bin auf jeden Fall für I. und II.a. Ich würde ebenfalls das trimmen von Leerzeichen in Freitextvalues unterstützen (da haben sie genausowenig zu suchen, der Code dürfte einfacher werden und verschiedene Probleme, wie Sortierung wurden ja schon angesprochen). Ich würde sogar soweit gehen, und mehrfache Leerzeichen in der Mitte (nicht nur) von Freitextvalues zu einem zusammenfassen: Manche nutzen das nämlich leider, um Namen in Mapnik an ihnen genehmeren Stellen rendern zu lassen. Würde das durch einen Bot gefixt, würden die entsprechenden Mapper schnell darauf hingewiesen, dass das keine gute Praxis ist und es sich in Zukunft wohl anders überlegen. Eventuell könnte man ja, wie bei den anderen Korrekturen durch Wall·E für solche Korrekturen eine Liste führen, damit ein Objekt nicht zweimal angefasst wird, für die seltenen Fälle, wo das vielleicht doch mal sinnvoll sein sollte.

Btw., wenn ich's gerade schon von der Liste habe: Speichert die eigentlich nur das Objekt oder auch, welcher Fehler korrigiert wurde - sprich, wenn jemand das ganze nicht auf den Stand von vorher zurücksetzt, sondern einen neuen, potentiellen Fehler einbaut, greift Wall·E dann nochmal ein, oder nicht?

Naja, da steht nur "So long as a licensee appropriately attributes the BY licensor", nicht, dass der Urheber explizit sein Einverständnis geben muss. Wäre auch unsinnig, denn wenn ich den Urheber fragen muss, brauche ich ja keine Lizenz - ich kann der Urheber ja direkt fragen. Trotzdem kann man sich über die Bedeutung von "appropriately" streiten und es kann deshalb nichts schaden, trotzdem nochmal nachzufragen.