Chaos

Ich würde sagen:
1. Riesenmultipolygon
2. ohne einzelne landuse=forest
3. und user ... wollte nur den Zeltplatz auf eine Wiese in den Wald einfügen.

Da ist die ganze Aussenlinie der Relation komplett nach Südwesten über den Rhein verschoben.

@Radeln: Willst Du es reparieren, ein Revert dürfte problematisch sein?

Bernd

Salve,

vielleicht doch erst ein Revert probieren. Es sind die Changesets

14124625 Sonntag, 02. Dezember 2012, 15:13 Uhr
14123626 Sonntag, 02. Dezember 2012, 13:57 Uhr
14123019 Sonntag, 02. Dezember 2012, 13:08 Uhr

und nach WHODIDIT hat seitdem keine mehr in der Gegend gemapt.

Harry

Ok, ich versuche es mal, bitte nichts ändern

Ich hätte da eine Frage. Wenn bei einem Revert was schief geht. Kann man den Revert reverten?
Das klingt jetzt komisch ist aber eine erst gemeinte Frage.
Danke

Harry

Ja, man erstellt ja einen neuen Änderungssatz.

Aktuell versuche ich, bevor ich den neuen Änderungssatz erstelle, erst mal die Konsequenzen abzuschätzen
🙄

Bernd

Erledigt

Bitte schaut noch mal drüber, es waren fast 1800 Objekte in diesen 3 Änderungssätzen betroffen

Bernd

Hi!

Ist es das selbe Problem? Wollte es grad posten... (ggflls. Fehler "Schleifen" aktivieren)
http://keepright.at/report_map.php?sche … r=42946419

Könnte sein, warte ein paar Minuten, bis die Region neu gerendert wurde

Bernd

Wenn Du gerade beim Putzen bist: Magst Du Dich mal in Gummersbach und Umgebung umschauen? Da hat einer "Busrouten ergänzt" und dabei unzählige Knoten und Wege dupliziert. Dieser Änderungssatz besteht abgesehen von der Erzeugung von fünf Relationen ausschließlich aus dem Hochladen von Duplikaten, die nun aber unglücklicherweise in besagte Routenrelationen eingebunden sind. D.h. einfach alle neuen Objekte löschen oder den Änderungssatz rückgängig machen scheidet leider aus.

Uhh, mangels genauer Ortskenntnis ist das mir zu heikel

Was sagt der Ersteller dazu?

Bernd

zum #1:

Es ist dort alles als MP gemappt.

Mag ja Richtig sein, aber wenn dann auf der Ackerfläche "Braubacher Staatswald" steht kommt bestimmt wieder ein user und will es als landuse=farmland mappen und macht eventuell wieder den Fehler, das MP zu trennen (P2).
Früher wurden große Waldflächen als MP eingetragen - mit den heutigen Hintergrund sollte auf landuse=forest (Forstbezirken, Wälder zwischen Straßen, Eisenbahnlinien, Flüssen) geändert werden. Dies trifft auch auf riesige MP=farmland (farm, farmyard) zu, die sich aufteilen liesen und so auch m.E. weniger fehleranfällig sind.

Radeln wrote:

südlich Koblenz:
http://tools.geofabrik.de/osmi/?view=mu … icate_tags

Das die Grenze von Alaska durch NRW (nördlich von Köln) geht ist doch bestimmt nur ein Fehler vom OSMI, oder?

Christian

geri-oc wrote:

zum #1:

Es ist dort alles als MP gemappt.

Mag ja Richtig sein, aber wenn dann auf der Ackerfläche "Braubacher Staatswald" steht kommt bestimmt wieder ein user und will es als landuse=farmland mappen und macht eventuell wieder den Fehler, das MP zu trennen (P2).
Früher wurden große Waldflächen als MP eingetragen - mit den heutigen Hintergrund sollte auf landuse=forest (Forstbezirken, Wälder zwischen Straßen, Eisenbahnlinien, Flüssen) geändert werden. Dies trifft auch auf riesige MP=farmland (farm, farmyard) zu, die sich aufteilen liesen und so auch m.E. weniger fehleranfällig sind.

Der Mist, der landläufig produziert wird, hat größtenteils die Ursache an fehlenden klaren und verbindlichen Regeln. Das Wiki ist da nicht immer eine Hilfe, manchmal sogar kontraproduktiv.

- Die Unterscheidung von landwirtschaftlichen Flächen in meadow und farmland macht für mich keinen Sinn. Wie wärs mit landuse=agriculture.
- Einerseits reicht nicht mal eine bedeutende Straße oder ein Strom und landuse aufzuteilen, andererseits wird farmland nahezu um jede Ackergrume herumgezeichnet. Feldwege gehören IMHO genauso zu farmland wie die Wohnstraßen zu landuse=residential.
- aneinander grenzende landuse werden nicht verbunden
- unsinnige landuse-Überlappungen usw.

landuse bräuchte eine Überarbeitung und eine Aufspaltung in Nutzung und Bedeckung.

landuse=agriculture|forestry|residetial|industrial|commercial|military|....

Diese können sich auch überschneiden, da ein Gebiet auch mehrere Nutzungsmöglichkeiten haben kann.

landcover=grass|sand|water|wood oder trees|concrete|asphalt|farmland|.....

Landuse und Landcover sollten sich nicht überschneiden, sondern dann gemeinsam getaggt werden. Ansonsten fallen diverse Auswertungen auf den Hintern, weil man nicht mehr unterschieden kann zwischen Wiese und Weide. Also das "Problem", dass dir Landuse zu sehr zerstückelt wird, kann man damit auch nicht lösen.

hi,
wie geht es denn jetzt weiter?
Revert anscheinend abgebrochen, also händisch fixen?

Gruss
walter

Salve,

soweit ich gesehen hab war der Revert doch erfolgreich. Das "mangels genauer Ortskenntnis ist das mir zu heikel" von Bernd bezog sich doch auf den weiteren Revert Wunsch.

Harry

berndw wrote:

Uhh, mangels genauer Ortskenntnis ist das mir zu heikel

Was sagt der Ersteller dazu?

Ortskenntnis braucht es dafür nicht, aber (sehr) viel Zeit und Geduld. Den Ersteller habe ich gerade angeschrieben, vermutlich wird er selbst nichts davon bemerkt haben.
Ein Revert würde die Busrelationen zerstören. Wenn der Ersteller zustimmt, könnte man diese Option in Erwägung ziehen, müßte aber immer noch schauen, ob nicht zwischenzeitlich jemand einige der Originale gelöscht hat.

Ich frage mich immer noch, wie die Leute das überhaupt hinkriegen. Im Osten der Niederlande hat vor einiger Zeit mal jemand großflächig Gewässer dupliziert. Da lagen dann teilweise vier oder fünf identische water oder riverbank übereinander; insgesamt einige zehntausend Knoten.

gut, dann warte ich mal den nächsten osmi-lauf ab und schau mir danach die Ecke mal an.
Gruss
walter

Oli-Wan wrote:

Ich frage mich immer noch, wie die Leute das überhaupt hinkriegen. Im Osten der Niederlande hat vor einiger Zeit mal jemand großflächig Gewässer dupliziert.

Mein erster Versuch mit JOSM endete auch mit einem doppelten Dorf. Ich dachte mir, es sei eine gute Methode, Hausnummern zu tagen, hatte aber statt eines Nodes ein ganzes Gebiet in der Auswahl. Das hab ich dann eingefügt, eine Hausnummer geändert, das Dorf erneut eingefügt ... ich glaub beim dritten Mal fiel es mir dann auf und ich hab in Panik den Editor geschlossen. In Panik könnte ich aber auch mit Hochladen reagieren 😉

Grüße, Max

maxbe wrote:

Ich dachte mir, es sei eine gute Methode, Hausnummern zu tagen, hatte aber statt eines Nodes ein ganzes Gebiet in der Auswahl. Das hab ich dann eingefügt, eine Hausnummer geändert, das Dorf erneut eingefügt ... ich glaub beim dritten Mal fiel es mir dann auf und ich hab in Panik den Editor geschlossen.

Du meinst das Duplizieren von Objekten mit Ctrl-D? Das führt typischerweise zu verschobenen Objekten, eingefügt am Ort des Cursors. Hier und in dem anderen beschriebenen Fall liegen die Duplikate aber haargenau auf dem Original, sonst wären sie mir gar nicht aufgefallen.

Nachtrag: Ich habe soeben Antwort vom Ersteller erhalten, er wird sich selbst darum kümmern.
Ich frage mich aber weiterhin, wie solche Fehler überhaupt entstehen.

Ich habe es ab und an mal, das JOSM nach dem von Konflikten Elemente doppelt anlegt.
Andere haben das mit Potlatch auch schon hinbekommen, die Ursache dafür kenne ich nicht.
Mit Keepright fällt das sehr schnell auf, und für soetwas hatte ich mir die xy-Bot Erweiterung im entsprechenden Thread gewünscht.

BFX wrote:

Ich habe es ab und an mal, das JOSM nach dem von Konflikten Elemente doppelt anlegt.
Andere haben das mit Potlatch auch schon hinbekommen, die Ursache dafür kenne ich nicht.
Mit Keepright fällt das sehr schnell auf, und für soetwas hatte ich mir die xy-Bot Erweiterung im entsprechenden Thread gewünscht.

Das passiert ganz leicht (unabhängig vom Editor), wenn beim Hochladen Konflikte entstehen.
Die bereits hochgeladenen Elemente werden in der Situation nicht zurückgemeldet. Das heißt sie können auch nicht im Editor als hochgeladen registriert werden. Wenn man nach dem Beseitigen der Konflikte, ein zweites mal hochlädt, werden diese Elemente ein zweites (drittes, ...) Mal hochgeladen. Bei neu angelegten Objekten entstehen dabei die Duplikate, da es ja noch keine Version gibt, gegen die geprüft werden kann.

In JOSM gibt es dafür die Funktion Daten aktualisieren (im Menü Datei). Das kann und sollte man bei größeren Edits vor dem Hochladen ausführen. Dabei werden alle Konflikte angezeigt und können (vor dem Hochladen) beseitigt werden. Gegebenenfalls Daten aktualisieren zur Sicherheit danach noch einmal wiederholen.

Falls man bereits einen Teil hochgeladen hat, vor dem erneuten Hochladen (in JOSM) die Fehlerprüfung starten. Dabei werden doppelte Objekte leicht gefunden. Dabei zuerst Wege mit ID=0 (= neue Objekte) löschen. Dabei werden auch doppelte Knoten aufgrund doppelter Wege mit entfernt. Lediglich die Knoten, welche mit anderen Objekten verbunden sind oder allein stehen, muss man dann noch einzeln löschen.

Edbert (EvanE)

Alles schön und gut, aber wie kriegt man es hin, Bestandsobjekte an gleicher Stelle zu duplizieren? Also aus Objekten, die bereits beim Herunterladen des Gebiets existierten (ID > 0), neue und völlig identische Objekte (ID = 0) zu generieren und anschließend hochzuladen? Noch dazu, ohne daß JOSM sich über die doppelten Knoten (u.a.) beschwert?

Es geht im Beispiel um etliche Straßen samt ihrer Knoten. Ich würde ohne nachzusehen wetten, daß die nicht allesamt zur gleichen Zeit von jemand anderem bearbeitet wurden, sodaß Konflikte hätten entstehen können. Im anderen Fall waren es landuse-Flächen, die noch im Originalzustand aus dem Import waren, die selbst später nie wieder jemand angefaßt hat.

wambacher wrote:

gut, dann warte ich mal den nächsten osmi-lauf ab und schau mir danach die Ecke mal an.
Gruss
walter

Der Revert aller drei Changesets ging ohne Probleme über die Bühne, eine Aktualisierung des Browsercaches etwa 20-30 Minuten danach lieferte die reparierten Relationen, die unvollständige landuse=field ist weg

Ist zu mir zu heikel bezog sich auf die Busrelation

Bernd

Oli-Wan wrote:

Alles schön und gut, aber wie kriegt man es hin, Bestandsobjekte an gleicher Stelle zu duplizieren? Also aus Objekten, die bereits beim Herunterladen des Gebiets existierten (ID > 0), neue und völlig identische Objekte (ID = 0) zu generieren und anschließend hochzuladen? Noch dazu, ohne daß JOSM sich über die doppelten Knoten (u.a.) beschwert?

Es geht im Beispiel um etliche Straßen samt ihrer Knoten. Ich würde ohne nachzusehen wetten, daß die nicht allesamt zur gleichen Zeit von jemand anderem bearbeitet wurden, sodaß Konflikte hätten entstehen können. Im anderen Fall waren es landuse-Flächen, die noch im Originalzustand aus dem Import waren, die selbst später nie wieder jemand angefaßt hat.

Ganz einfach! Man habe keine gute Internetverbindung. Dann lädt man einfach den bereich herunter und verändert die Daten. Dann lädt man die Objekte hoch und wenn es scheitert noch zwei dreimal bis der Editor sagt Erfolg. Ich habe das Gefühl dabei entstehen genau solche Duplikate. Die Dinger zu finden ist dann eine heiden Arbeit.

berndw wrote:

wambacher wrote:

gut, dann warte ich mal den nächsten osmi-lauf ab und schau mir danach die Ecke mal an.
Gruss
walter

Der Revert aller drei Changesets ging ohne Probleme über die Bühne, eine Aktualisierung des Browsercaches etwa 20-30 Minuten danach lieferte die reparierten Relationen, die unvollständige landuse=field ist weg

Was ist nun mit landuse=field? Fällt wohl unter die Kategorie jeder kann machen, was er will.

viw wrote:

Ganz einfach! Man habe keine gute Internetverbindung. Dann lädt man einfach den bereich herunter und verändert die Daten. Dann lädt man die Objekte hoch und wenn es scheitert noch zwei dreimal bis der Editor sagt Erfolg. Ich habe das Gefühl dabei entstehen genau solche Duplikate. Die Dinger zu finden ist dann eine heiden Arbeit.

Auf diese Weise kann man neu erzeugte Objekte mehrfach hochladen, genau wie von Edbert auch schon beschrieben. Wenn der Editor im ersten Versuch für den Upload keine Bestätigung erhält, schiebt er die Objekte halt beim nächsten Versuch noch einmal hoch. Aber bestehende Objekte, die nicht verändert wurden, werden normalerweise gar nicht hochgeladen, wie es hier geschehen ist; Duplikate dieses Typs können also nicht auf diese Weise entstehen.

Radeln wrote:

Was ist nun mit landuse=field? Fällt wohl unter die Kategorie jeder kann machen, was er will.

Bei einem offenen Projekt habe ich, ehrlich gesagt, keine Probleme damit, wenn mir ein Tag sinnvoll erscheint, nutze ich ihn.

Was anderes ist die Qualität des Mappings an sich, vor allem, wenn es gravierend falsch ist und der Ersteller keine Anstalten macht den Fehler zu beheben, dann sollte man es ASAP korrigieren.

bernd

Du brauchst den Konflikt nicht bei dem selbst betroffenen Objekt sondern irgendwann weit hinten im Changeset.
Gab es nicht irgendwie die möglichkeit Elemente aus einem JOSM layer in den anderen zu übernehmen?
Wenn die Daten in dem Gebiet dann in dem hochgeladenen Layer nicht heruntergeladen waren, werden auch keine Warnungen angezeigt.
Außerdem kann man Warnungen auch ignorieren.

berndw wrote:

Radeln wrote:

Was ist nun mit landuse=field? Fällt wohl unter die Kategorie jeder kann machen, was er will.

Bei einem offenen Projekt habe ich, ehrlich gesagt, keine Probleme damit, wenn mir ein Tag sinnvoll erscheint, nutze ich ihn.

Was anderes ist die Qualität des Mappings an sich, vor allem, wenn es gravierend falsch ist und der Ersteller keine Anstalten macht den Fehler zu beheben, dann sollte man es ASAP korrigieren.

Es kommt eben darauf an, was man unter offen versteht.
Für mich heißt offen, jeder kann sich daran beteiligen, aber nicht con gusto, sondern nach klaren Regeln. Wer meint, sich seine eigene OSM-Welt schaffen zu müssen, sollte dies auf der Grundlage des Originals mit einem eigenen Server zu tun.
Wenn z.B. in OSM Flächen in Wäldern mit landuse=grass + name=Rodung gemappt und der Username '...förster' lautet, habe ich einen leisen Verdacht.

Du kannst einfach nicht verhindern, dass Leute Fehler eintragen. Auch wenn du feste Regeln für Tags hast, die verwendet werden dürfen und einer API, die das überprüft, kann jeder ein landuse=grass + name=Rodung eintragen. Von dem Aufwand in der API mal ganz zu schweigen.

viw wrote:

Ganz einfach! Man habe keine gute Internetverbindung. Dann lädt man einfach den bereich herunter und verändert die Daten. Dann lädt man die Objekte hoch und wenn es scheitert noch zwei dreimal bis der Editor sagt Erfolg. Ich habe das Gefühl dabei entstehen genau solche Duplikate. Die Dinger zu finden ist dann eine heiden Arbeit.

Hallo viw,

mit der duplicate nodes map war es ein Leichtes, solche doppelten Objekte zu finden (ein Haufen vieler roter Punkte). Damit hatte ich ich den letzten Jahren zeitweise große Teile Deutschlands sauber bekommen. Aber, die Karte lieferte dann eines Tages im Sommer (etwa 18-20 Monate her) keine Tiles mit den roten Punkten mehr aus - nur die normale Mapnik-Hintergrund-Karte war noch da.

Ich konnte auch erkennen, dass der erste Upload an neuen Daten (mit JOSM) keine Antwort brachte, oder der User ungeduldig wurde, weil der Server damals manchmal recht lange für die Antwort brauchte und das Fenster, das den Status des Hochladens anzeigt, geschlossen hatte und erneut hochlud, denn die älteren der doppelten Daten zeigten eine Zeit zwischen "Erstellt" und "Geschlossen" des Änderungssatzes von genau bis gut einer Stunde (Der Timeout bei einem offenen Changeset beträgt ja nach Ende des Hochladens, bei fehlendem Schließen, eine Stunde), während der jüngere der doppelten Wege und Knoten bei dieser Zeit meist deutlich unter wenigen Minuten lag. Wenn man auf solch eine Antwort des Servers lange wartet, kann man schon im Browser nachsehen, ob ein Weg, den man verändert hat, einen Zeitstempel von nach dem Beginn des Hochladens und den eigenen User-Namen trägt.

Ich wünsche mir diese Karte gerne zurück - gab es da Pläne von Matt (dem Autor), diese Karte als eine der Zeilen im Layer-Switcher der Mapnik-Karte einzubauen? - aber mit keepright sollte es auch gehen (diese schrägen gelben Fragezeichen).

Ergänzende Grüße,
Franz

FvGordon wrote:

mit der duplicate nodes map war es ein Leichtes, solche doppelten Objekte zu finden (ein Haufen vieler roter Punkte).
...
Ich wünsche mir diese Karte gerne zurück - gab es da Pläne von Matt (dem Autor), diese Karte als eine der Zeilen im Layer-Switcher der Mapnik-Karte einzubauen? - aber mit keepright sollte es auch gehen (diese schrägen gelben Fragezeichen).

Ich habe mir da wieder mal was eigenes gebastelt und damit in den letzten Wochen NRW weitestgehend aufgeräumt (größter verbliebener Schandfleck: Aachen). Ein kleines Skript, das aus einem .osm.bz2 jeweils einen der mehrfachen Knoten heraussortiert. Damit kann man sich noch nicht direkt an die Duplikatbeseitigung machen, aber man kann eine Ebene mit diesen Knoten quasi als Hintergrund in JOSM einsetzen, sieht sofort die Hotspots und muß nicht mehr zwischen JOSM und Brauser hin und her wechseln, da herumscrollen und so weiter. Ist alles quick & dirty gebastelt, nicht allzu schnell und nicht so elegant wie eine Online-Map in Quasi-Echtzeit, aber erfüllt seinen Zweck. Könnte ich zur Verfügung stellen, falls Interesse besteht. (Ist allerdings auf Linux zugeschnitten, unter Windows wären vermutlich ein paar Verrenkungen nötig.)

aighes wrote:

landuse bräuchte eine Überarbeitung und eine Aufspaltung in Nutzung und Bedeckung.

Das sollte bzw. muß man aus meiner Sicht leider noch weiter unterscheiden bzw. aufsplitten, weil es müssen ja u.a. folgende Unterscheidungen gemacht werden:

Die landschaftliche Prägung: Eine natürliche Anhäufung von Sand wird ja nicht automatisch immer zur Wüste, es kann z.B. auch eine Heidelandschaft sein. (Strand ist dagegen eine Nutzung einer größeren natürlichen Sandfläche.)
Der natürliche Untergrund: z.B. Stein/Fels, Sand, Erde.
Der evtl. vorhandenen Bewuchs auf dem Untergrund: Moose, Flechten, Gräser (einschließlich "Gras"), Kräuter, Sträucher/Büche, (spezielle) Bäume, spezielle Pflanzen (crop=*).
Auf dem natürlichen Untergrund (genaue Abgrenzung bei z.B. Gewässern/Gletschern?) vorhandenen natürliche/künstliche Auflagen: Gletscher, Schotter, Beton, Asphalt.

Irgendwie scheinen selbst diese paar Punkte kategoriemäßig schon weiter aufzulösen als z.B. das DLM, andere nennenswerte Modelle habe ich gerade nicht gefunden.

Dann kommt natürlich die Nutzung der Fläche: alleinige Nutzung, kombinierte Nutzung, weiter untergliederte voneinander abhängige Nutzungen.

landcover=grass ist z.B. kein landcover, sondern $bewuchs (aber in natural=* ist ja auch alles mögliche drin), landcover wäre da z.B. ground.
Dann ist nicht klar, was surface=* genau meint, weil die Wegoberfläche, für die der Tag benutzt wird, kann wahlweise natürlich oder künstlich sein. Eine Wiese mit einem Track ist landcover=ground mit zusätzlichem $bewuchs=grass außerhalb des Tracks.

Fabi2 wrote:

aighes wrote:

landuse bräuchte eine Überarbeitung und eine Aufspaltung in Nutzung und Bedeckung.

Das sollte bzw. muß man aus meiner Sicht leider noch weiter unterscheiden bzw. aufsplitten, weil es müssen ja u.a. folgende Unterscheidungen gemacht werden:
...
Dann kommt natürlich die Nutzung der Fläche: alleinige Nutzung, kombinierte Nutzung, weiter untergliederte voneinander abhängige Nutzungen.

Klarere Trennung zwischen Bedeckung und Nutzung (z.B. Wald, Wiese,... versus Agrarwirtschaft, Bebauung, Militär, ...) halte ich für sinnvoll und machbar , aber Landuse 2.0?
Sorry, aber das tu ich mir nicht an.

Gruss
walter

wambacher wrote:

Sorry, aber das tu ich mir nicht an.

+1 Ich kann's auch nicht mehr hören.
"Wir mappen die Realität" : Dann müsste man jedes Atom einzeln mappen..... Ob dann noch 'ne nutzbare Karte dabei
rauskommt? 😉

Fabi2 wrote:

aighes wrote:

landuse bräuchte eine Überarbeitung und eine Aufspaltung in Nutzung und Bedeckung.

Das sollte bzw. muß man aus meiner Sicht leider noch weiter unterscheiden bzw. aufsplitten, weil es müssen ja u.a. folgende Unterscheidungen gemacht werden:

Die landschaftliche Prägung: Eine natürliche Anhäufung von Sand wird ja nicht automatisch immer zur Wüste, es kann z.B. auch eine Heidelandschaft sein. (Strand ist dagegen eine Nutzung einer größeren natürlichen Sandfläche.)
Der natürliche Untergrund: z.B. Stein/Fels, Sand, Erde.
Der evtl. vorhandenen Bewuchs auf dem Untergrund: Moose, Flechten, Gräser (einschließlich "Gras"), Kräuter, Sträucher/Büche, (spezielle) Bäume, spezielle Pflanzen (crop=*).
Auf dem natürlichen Untergrund (genaue Abgrenzung bei z.B. Gewässern/Gletschern?) vorhandenen natürliche/künstliche Auflagen: Gletscher, Schotter, Beton, Asphalt.

Irgendwie scheinen selbst diese paar Punkte kategoriemäßig schon weiter aufzulösen als z.B. das DLM, andere nennenswerte Modelle habe ich gerade nicht gefunden.

Dann kommt natürlich die Nutzung der Fläche: alleinige Nutzung, kombinierte Nutzung, weiter untergliederte voneinander abhängige Nutzungen.

landcover=grass ist z.B. kein landcover, sondern $bewuchs (aber in natural=* ist ja auch alles mögliche drin), landcover wäre da z.B. ground.
Dann ist nicht klar, was surface=* genau meint, weil die Wegoberfläche, für die der Tag benutzt wird, kann wahlweise natürlich oder künstlich sein. Eine Wiese mit einem Track ist landcover=ground mit zusätzlichem $bewuchs=grass außerhalb des Tracks.

Geht's noch?

@Fabi2: Ähmm...ja...und wenn der Sandhaufen von Holz umgeben ist und Förmchen drin liegen ist es ein Sandkasten/Spielplatz. 😉

Diese Landschaftsformen sind besser in natural=* aufgehoben. Bspw. wäre dann ein natural=beach landcover="Kies" ein Kiesstrand und natural=beach landcover=sand ein Sandstrand und so weiter. landcover beschriebt eher das, was auf dem Luftbild sehen würde. Klar, man kann das auch weiter treiben und den pH-Wert des Bodens eintragen. Ich sehe aber darin keinen Vorteil 😉

Hallo,

wambacher wrote:

Klarere Trennung zwischen Bedeckung und Nutzung (z.B. Wald, Wiese,... versus Agrarwirtschaft, Bebauung, Militär, ...) halte ich für sinnvoll und machbar

+1

Das hieße dann aber auch, daß landuse um viele Tags reduziert wird, da ja hier sehr viel Bedeckung mit dabei ist Das trifft meiner Ansicht nach dann aber auch auf natural=* zu...
Streng genommen ergäben sich bei der Nutzung Mehrfachangaben: ein Wald wird forstwirtschaftlich genutzt, Jagdnutzung, Erholung... wobei ich die Nutzung nicht so im Vordergund sehen würde. Wichtiger ist mir ein einfaches Schema für die Bedeckung...

meint Sven

aighes wrote:

Du kannst einfach nicht verhindern, dass Leute Fehler eintragen. Auch wenn du feste Regeln für Tags hast, die verwendet werden dürfen und einer API, die das überprüft, kann jeder ein landuse=grass + name=Rodung eintragen. Von dem Aufwand in der API mal ganz zu schweigen.

ACK, ändert aber nichts daran, dass klare, eindeutige Regeln Fehler und das Durcheinander beim Mappen erheblich reduzieren würden.

Die Koblenzer Chaos-Corner sieh zumindest im OSM-Inspektor wieder sauber aus.
Danke an alle Mitwirkende.

Gruss
walter

Oli-Wan wrote:

Nachtrag: Ich habe soeben Antwort vom Ersteller erhalten, er wird sich selbst darum kümmern.

Der Vollständigkeit halber: Der Ersteller der Duplikate hat seinen Worten Taten folgen lassen und aufgeräumt. Alles wieder gut, der Großteil der NRW-Doppelknoten liegt wieder in Aachen.

FvGordon wrote:

mit der duplicate nodes map war es ein Leichtes, solche doppelten Objekte zu finden (ein Haufen vieler roter Punkte). Damit hatte ich ich den letzten Jahren zeitweise große Teile Deutschlands sauber bekommen.

In Potlatch2 werden diese großen, roten Punkte angezeigt. Für größere Gebiete aber recht langsam.

Hi

ich habe gerade wieder ein fehlerhaftes Changeset eines neuen P2-Mappers revertiert. nichts allzu schlimmes und relativ kleinflächig, aber eindeutig auf P2 zurückzuführen.

Bernd

berndw wrote:

Hi

ich habe gerade wieder ein fehlerhaftes Changeset eines neuen P2-Mappers revertiert. nichts allzu schlimmes und relativ kleinflächig, aber eindeutig auf P2 zurückzuführen.

Bernd

Potlatch2 ist nun mal die primäre "Einstiegsdroge". Deshalb kann man dem Tool aber nicht die ganze Schuld an Anfängerfehlern geben. Wie erkennst Du, dass die Fehler eindeutig auf P2 zurückzuführen sind?

Radeln wrote:

- Die Unterscheidung von landwirtschaftlichen Flächen in meadow und farmland macht für mich keinen Sinn. Wie wärs mit landuse=agriculture.

Für Dich vielleicht nicht, für andere Kartennutzer schon. Deswegen wird seit ca. 200 Jahren Acker und Grasland in mitteleropäischen Karten unterschiedlich gezeichnet.

Taunide wrote:

Radeln wrote:

- Die Unterscheidung von landwirtschaftlichen Flächen in meadow und farmland macht für mich keinen Sinn. Wie wärs mit landuse=agriculture.

Für Dich vielleicht nicht, für andere Kartennutzer schon. Deswegen wird seit ca. 200 Jahren Acker und Grasland in mitteleropäischen Karten unterschiedlich gezeichnet.

+1
Sven

hurdygurdyman wrote:

Potlatch2 ist nun mal die primäre "Einstiegsdroge". Deshalb kann man dem Tool aber nicht die ganze Schuld an Anfängerfehlern geben. Wie erkennst Du, dass die Fehler eindeutig auf P2 zurückzuführen sind?

Drei Anzeichen

Erstes: Eine einfache Änderung ohne Zusammenhang, keine besonderen Tags
zweites: meist nur ein Changeset,des Users. das zweite sind dann meist schon Korrekturen des ersten
drittes: Potlatch* als Editor in der Historie

Das trifft in "meiner" Region mindestens einmal die Woche zu.

🙄

Für mich sieht das fast immer so aus:
Auf 'bearbeiten' geklickt, die folgende Warnung ignoriert, wer liest die schon, wenn so viele andere Warnungen im Browser aufgehen, ein bisschen die Karte verschoben um das eigene Haus zusehen und versehentlich eine Linie gezogen. Dann die Panik bekommen und das Fenster geschlossen, ist ja nichts passiert, oder doch?

Reaktionen auf freundliche Mails, ich schreibe eigentlich immer eine mit dem Angebot weiterer Hilfe, sind dann auch sehr selten.

ich habe mal so einen Bock mit JOSM geschossen, da war dann aber eigene Blödheit
😉

Bernd

berndw wrote:

hurdygurdyman wrote:

Potlatch2 ist nun mal die primäre "Einstiegsdroge". Deshalb kann man dem Tool aber nicht die ganze Schuld an Anfängerfehlern geben. Wie erkennst Du, dass die Fehler eindeutig auf P2 zurückzuführen sind?

Drei Anzeichen
...
zweites: meist nur ein Changeset,des Users. das zweite sind dann meist schon Korrekturen des ersten

Das wäre dann ein Lernprozess 😉
und wenn User Warnungen ignorieren ist das doch nicht die Schuld der Software 🙄

berndw wrote:

Für mich sieht das fast immer so aus:
Auf 'bearbeiten' geklickt, die folgende Warnung ignoriert, wer liest die schon, wenn so viele andere Warnungen im Browser aufgehen, ein bisschen die Karte verschoben um das eigene Haus zusehen und versehentlich eine Linie gezogen. Dann die Panik bekommen und das Fenster geschlossen, ist ja nichts passiert, oder doch?

Und wie erklärst du dir, dass der User in deinem Szenario vor dem panischen Schließen des Fensters noch auf Speichern klickt? Potlatch2 arbeitet schließlich nicht mehr live.

hurdygurdyman wrote:

und wenn User Warnungen ignorieren ist das doch nicht die Schuld der Software

Hier muss ich allerdings widersprechen. Ein Interface-Designer, der sich darauf verlässt, dass Nutzer Warnungen lesen, macht seinen Job nicht besonders gut. 😉

Tordanik wrote:

Und wie erklärst du dir, dass der User in deinem Szenario vor dem panischen Schließen des Fensters noch auf Speichern klickt? Potlatch2 arbeitet schließlich nicht mehr live.

Ist es nicht mehr so?
Potlatch fragt zu Beginn, ob ich live arbeiten möchte, dann editiere ich etwas, wenn mit dem Objekt fertig, klicke ich auf eine freie Fläche, wird das geänderte gespeichert. Will ich aber das Fenster schließen, ohne die Markierung aufzuheben, kommt die Nachfrage, ob ich speichern möchte.
Das erste wird ohne Nachfrage gespeichert, das zweite nicht
Ich bin kein P2-User, nutze es auch nur sehr selten, deswegen kann ich auch falsch liegen.

Bernd

berndw wrote:

Potlatch fragt zu Beginn, ob ich live arbeiten möchte

Nee, "Live editing" gibt es in P2 zum Glück nicht mehr.

Tordanik wrote:

hurdygurdyman wrote:

und wenn User Warnungen ignorieren ist das doch nicht die Schuld der Software

Hier muss ich allerdings widersprechen. Ein Interface-Designer, der sich darauf verlässt, dass Nutzer Warnungen lesen, macht seinen Job nicht besonders gut. 😉

Solche Warnungen kenne ich sogar aus SAP 🙄 und der berühmte "del c:\" in MS-DOS spuckte auch (aber nicht von Anfang an) eine Warnung aus.
Meine generelle Meinung:
Wenn ich ein Programm erstmalig nutze, muss ich mich vorher über die Funktionsweise informieren, um abschätzen zu können, welche Folgen mein Handeln hat. Aber leider macht sich "try and error" als Grundsatz in der Anwendung von Software mit den entsprechenden Folgen immer mehr breit.

Ansonsten verlasse ich jetzt diese teilweise auch auf Halb- oder Unwissen basierende Diskussion mit dem Fazit:
Beide Editoren haben für eingearbeitete Anwender Vor- und Nachteile. Möge jeder selbst herausfinden, mit welchem er am besten seinen Beitrag zu OSM leisten will.

Radeln wrote:

Es kommt eben darauf an, was man unter offen versteht.
Für mich heißt offen, jeder kann sich daran beteiligen, aber nicht con gusto, sondern nach klaren Regeln. Wer meint, sich seine eigene OSM-Welt schaffen zu müssen, sollte dies auf der Grundlage des Originals mit einem eigenen Server zu tun.
Wenn z.B. in OSM Flächen in Wäldern mit landuse=grass + name=Rodung gemappt und der Username '...förster' lautet, habe ich einen leisen Verdacht.

Was du hier so treibst, das grenzt schon an Edit War.

Habe gerade eine ganze Reihe deiner Änderungen in meinem Heimatort rückgängig gemacht. Was bringt das, in einem Gebiet wo nach einheitlichen und einvernehmlich Regeln gemappt wird, einfach mal willkürlich und ohne Ortskenntnis wild und unsystematisch umzumappen? Und das ganze noch relativ schlampig (z.B. Gebäude mit Landuse-Areas verbunden).

Der Mist hat mich jetzt gut eine Stunde gekostet und in der Zeit hätten stattdessen wieder einige Wege und Gebäude erfasst sein können. Das ist unproduktiv. Es wird nichts neues gemappt sondern nur umgemappt.

Genial finde ich auch deinen Vorschlag, alles was von Bing abweichend gemappt wird, extra zu kennzeichnen. Damit es von ortsfremden Bing-Mappern nicht platt gemacht wird.
Also immer wenn ich hier was lokales mappe, dann soll ich jetzt nachschauen, ob das in Bing schon vorhanden war und dann einen Warnhinweis setzen!
Das muss man wohl nicht weiter kommentieren. 😉

Such dir bitte ein Gebiet, wo du produktiv was tun kannst, und versuche nicht, anderen dein Mapping-Schema aufzudrücken.

Das ist wohl der Fluch der neuen Bing-Karten, dass jetzt jeder meint ohne Ortskenntnis überall mappen zu müssen. 🙁

dgdg wrote:

Radeln wrote:

Es kommt eben darauf an, was man unter offen versteht.
Für mich heißt offen, jeder kann sich daran beteiligen, aber nicht con gusto, sondern nach klaren Regeln. Wer meint, sich seine eigene OSM-Welt schaffen zu müssen, sollte dies auf der Grundlage des Originals mit einem eigenen Server zu tun.
Wenn z.B. in OSM Flächen in Wäldern mit landuse=grass + name=Rodung gemappt und der Username '...förster' lautet, habe ich einen leisen Verdacht.

Was du hier so treibst, das grenzt schon an Edit War.

Habe gerade eine ganze Reihe deiner Änderungen in meinem Heimatort rückgängig gemacht. Was bringt das, in einem Gebiet wo nach einheitlichen und einvernehmlich Regeln gemappt wird, einfach mal willkürlich und ohne Ortskenntnis wild und unsystematisch umzumappen? Und das ganze noch relativ schlampig (z.B. Gebäude mit Landuse-Areas verbunden).

Der Mist hat mich jetzt gut eine Stunde gekostet und in der Zeit hätten stattdessen wieder einige Wege und Gebäude erfasst sein können. Das ist unproduktiv. Es wird nichts neues gemappt sondern nur umgemappt.

Genial finde ich auch deinen Vorschlag, alles was von Bing abweichend gemappt wird, extra zu kennzeichnen. Damit es von ortsfremden Bing-Mappern nicht platt gemacht wird.
Also immer wenn ich hier was lokales mappe, dann soll ich jetzt nachschauen, ob das in Bing schon vorhanden war und dann einen Warnhinweis setzen!
Das muss man wohl nicht weiter kommentieren. 😉

Such dir bitte ein Gebiet, wo du produktiv was tun kannst, und versuche nicht, anderen dein Mapping-Schema aufzudrücken.

Das ist wohl der Fluch der neuen Bing-Karten, dass jetzt jeder meint ohne Ortskenntnis überall mappen zu müssen. 🙁

Nur mal was davor war/z.T. noch ist: 70 Gebäudeüberschneidungen, intersections, überlappende landuse, ganzer waterway mit layer=-1 sowie überflüssige MPs mit einem Element.
Weiterhin habe ich landuse, zwischen denen nichts liegt (Niemandsland) verbunden.
Sehe nicht, was daran falsch sein soll.

Im Wiki dokumentierte und angenommene Änderungen sollten umgesetzt werden. Es verlangt einerseits auch keiner von Dir, dass Du 2 Jahre alte Mappings an aktuelles Mappen anpasst. Andererseits sollte Du aber solche Änderungen annehmen, die durch Dritte erfolgen.

BTW, Häuser habe ich nicht an landuse gepappt.

Oli-Wan wrote:

berndw wrote:

Potlatch fragt zu Beginn, ob ich live arbeiten möchte

Nee, "Live editing" gibt es in P2 zum Glück nicht mehr.

Ich kann es noch nicht mal ausprobieren, da P2 momentan rumzickt 😉

Aber ich habe noch was gefunden http://www.openstreetmap.org/browse/changeset/14257820

Bernd

berndw wrote:

Aber ich habe noch was gefunden http://www.openstreetmap.org/browse/changeset/14257820

Typische Anfängerspielerei, ebenso wie sich im vorigen Änderungssatz unter demselben Account typische Anfängerfehler finden. Aber bei aller Abneigung gegen Potlatch kann ich das nicht Potlatch ankreiden. Mit JOSM hätte die Person vermutlich genauso herumgespielt; sie ist aber halt zuerst an P2 geraten.

PS. Wenn Du willst, schmiere ich Dir so einen Rotz auch mit Emacs hin 😉

🙂

Ja, aber JOSM setzt etwas Engagement voraus, schliesslich muß man ein paar Vorarbeiten erledigen, und wenn man nur auf eine Echse drückt.. ähh EXE klickt

Bernd

Klar, ich kann für jedes Mapping JOSM benutzen.

Ich kann auch für jedes Kantholz zusägen meine Kettensäge anschmeissen, wenn ich werkzeugverliebt bin.

Je größer das Werkzeug, desto besser die Arbeit. Ooooobi!

Radeln wrote:

Nur mal was davor war/z.T. noch ist: 70 Gebäudeüberschneidungen, intersections, überlappende landuse, ganzer waterway mit layer=-1 sowie überflüssige MPs mit einem Element.
Weiterhin habe ich landuse, zwischen denen nichts liegt (Niemandsland) verbunden.
Sehe nicht, was daran falsch sein soll.
BTW, Häuser habe ich nicht an landuse gepappt.

Habe gerade wieder das residential-Polygon von Fronhausen reparieren müssen, nach dem du da gestern zum wiederholten Male dran rumgefummelt hast. Der Friedhof wurde auch nicht mehr gerendert, weil das inner-Polygon kaputt war (deswegen ist mir das Ganze aufgefallen).

Noch mal mein Apell: Lass die Mapper vor Ort einfach arbeiten. Sicher gab/gibt es hier (wie überall) Mapping-Fehler. Aber was du treibst, macht alles nur noch schlimmer.
Die meisten angeblichen Fehler, die du behebst, sind nur Dinge, die dir nicht passen. Redundanz ist kein Fehler.

dgdg wrote:

Radeln wrote:

Nur mal was davor war/z.T. noch ist: 70 Gebäudeüberschneidungen, intersections, überlappende landuse, ganzer waterway mit layer=-1 sowie überflüssige MPs mit einem Element.
Weiterhin habe ich landuse, zwischen denen nichts liegt (Niemandsland) verbunden.
Sehe nicht, was daran falsch sein soll.
BTW, Häuser habe ich nicht an landuse gepappt.

Habe gerade wieder das residential-Polygon von Fronhausen reparieren müssen, nach dem du da gestern zum wiederholten Male dran rumgefummelt hast. Der Friedhof wurde auch nicht mehr gerendert, weil das inner-Polygon kaputt war (deswegen ist mir das Ganze aufgefallen).

Welchs inner-Polygon? Den Friedhof (jüdisch) hatte ich als inner zur Relation zugefügt. Du hast den inner dann wieder rausgenommem -> Fehler. Falls Du der Meinung bist, dass dies kein Fehler ist, weshalb ist dann der andere Friedhof als inner in der Relation?

Und BTW, mappen und dann zu schauen, ob der Renderer es darstellt, ist nicht immer der richtige Weg. Mappen für den Renderer.

dgdg wrote:

Noch mal mein Apell: Lass die Mapper vor Ort einfach arbeiten. Sicher gab/gibt es hier (wie überall) Mapping-Fehler. Aber was du treibst, macht alles nur noch schlimmer.
Die meisten angeblichen Fehler, die du behebst, sind nur Dinge, die dir nicht passen. Redundanz ist kein Fehler.

Überlappende bzw. sich schneidende Gebäude oder auch sich überlappende Multipolygone (westlich des Sportplatzes) sind IMHO eindeutig Fehler. Letzteren hast Du wieder etabliert.
Auch sehe ich aneinander grenzende nicht verbundene landuse, zwischen denen nichts liegt oder verläuft, als falsch an. Anders gesagt, weshalb muss eine Wiese und ein Acker, die in der Natur direkt aneinander grenzen, in der Karte getrennt sein. Wenn dem so ist, machen es hunderte andere Mapper falsch.
(JOSM: ContourMerge Plugin -> wieder ein paar weisse Flecken weniger).

Radeln wrote:

Mappen für den Renderer. Und BTW, mappen und dann zu schauen, ob der Renderer es darstellt, ist nicht immer der richtige Weg.

Mappen für den OSM Inspector auch nicht. Da haben noch nicht mal die Kartennutzer was von.

Taunide wrote:

Radeln wrote:

Mappen für den Renderer. Und BTW, mappen und dann zu schauen, ob der Renderer es darstellt, ist nicht immer der richtige Weg.

Mappen für den OSM Inspector auch nicht. Da haben noch nicht mal die Kartennutzer was von.

Bla, bla ....

Taunide wrote:

Da haben noch nicht mal die Kartennutzer was von.

Ich glaube du verwechselst da Kartennutzer mit "Bunte-Bildchen-auf openstreetmap.org-Anschauer" - zweitere werden nicht immer eine Veränderung erkennen können.

Radeln wrote:

Auch sehe ich aneinander grenzende nicht verbundene landuse, zwischen denen nichts liegt oder verläuft, als falsch an. Anders gesagt, weshalb muss eine Wiese und ein Acker, die in der Natur direkt aneinander grenzen, in der Karte getrennt sein. Wenn dem so ist, machen es hunderte andere Mapper falsch.
(JOSM: ContourMerge Plugin -> wieder ein paar weisse Flecken weniger).

Hätte mich schon mal interessiert, wie andere das sehen, oder fällt dies auch unter die Kategorie jeder kann machen, was er will

Radeln wrote:

Radeln wrote:

Auch sehe ich aneinander grenzende nicht verbundene landuse, zwischen denen nichts liegt oder verläuft, als falsch an. Anders gesagt, weshalb muss eine Wiese und ein Acker, die in der Natur direkt aneinander grenzen, in der Karte getrennt sein. Wenn dem so ist, machen es hunderte andere Mapper falsch.
(JOSM: ContourMerge Plugin -> wieder ein paar weisse Flecken weniger).

Hätte mich schon mal interessiert, wie andere das sehen, oder fällt dies auch unter die Kategorie jeder kann machen, was er will

Die Dinge sind nicht immer so klar, wie man sich das wünscht.
- Übergangsbereich zwischen Acker und Feld (meist Büsche)
- Übergangsbereich zwischen Acker und Straße (Grün, Büsche, Graben, ...)

Von daher ist es in vielen Fällen vertretbar landuse nicht unmittelbar an landuse zu pappen. Es besteht keinerlei Verpflichtung unsere Karte lückenlos zu gestalten.

JM2C
Edbert (EvanE)

EvanE wrote:

Radeln wrote:

Radeln wrote:

Auch sehe ich aneinander grenzende nicht verbundene landuse, zwischen denen nichts liegt oder verläuft, als falsch an. Anders gesagt, weshalb muss eine Wiese und ein Acker, die in der Natur direkt aneinander grenzen, in der Karte getrennt sein. Wenn dem so ist, machen es hunderte andere Mapper falsch.
(JOSM: ContourMerge Plugin -> wieder ein paar weisse Flecken weniger).

Hätte mich schon mal interessiert, wie andere das sehen, oder fällt dies auch unter die Kategorie jeder kann machen, was er will

Die Dinge sind nicht immer so klar, wie man sich das wünscht.
- Übergangsbereich zwischen Acker und Feld (meist Büsche)
- Übergangsbereich zwischen Acker und Straße (Grün, Büsche, Graben, ...)

Von daher ist es in vielen Fällen vertretbar landuse nicht unmittelbar an landuse zu pappen. Es besteht keinerlei Verpflichtung unsere Karte lückenlos zu gestalten.

Dinge, die nicht so klar sind, waren auch nicht gemeint, sondern ein eindeutiges direktes Angrenzen. Anderes Beispiel, zwei farmland-Flächen, die sich nur in der Färbung (Bing) unterscheiden. Die fasse ich auch mal zusammen.
BTW, ein Feldrain z.B. sehe ich als zum Acker zugehörig.

Es ist halt das ewige Kuddelmuddel, was einem OSM so vermiest. Einerseits werden farmland und meadow um Feldwege (tracks) herumgepinselt, andererseits werden landuse über riverbank und mehrspurige Straßen drüber gepinselt. Auch Flächen an einen highway kleben gehört dazu, mal abgesehn davon highway als Grenze für MP-Relationen zu nutzen (strittig).
Wenn ich dann höre, so ist halt OSM, ziehts mir die Schuhe aus. Da gehört endlich mal etwas mehr Ordnung rein und das geht nur über klare Regeln.

Die Dinge sind nicht immer so klar, wie man sich das wünscht.

Doch!

- Übergangsbereich zwischen Acker und Feld (meist Büsche)

natural=scrub

- Übergangsbereich zwischen Acker und Straße (Grün, Büsche, Graben, ...)

waterway=ditch

Die Natur hat auch keine Lücken.

Wolfgang B wrote:

Die Dinge sind nicht immer so klar, wie man sich das wünscht.

Doch!
...
Die Natur hat auch keine Lücken.

Wenn du die Natur im subatomaren Bereich ansiehst, gibt es in der Hauptsache Lücken und nur wenig Teilchen. 😠

Für den von uns betrachteten Makro-Bereich gilt deine Aussage zwar, aber das heißt noch lange nicht, dass wir jedes Steinchen erfassen müssen. In meinen Augen ist es nicht notwendig eine lückenlose Karte erstellen zu wollen. Wenn jemand nur die größeren Dinge wie Acker und Wald erfassen will, aber die kleine Dinge dazwischen diesem Mapper zu lästig sind, dann sollten wir ohne Murren damit leben. Schließlich kann ja später jemand, den das stört, die Zwischenräume seinerseits auffüllen.

Was ich damit sagen will ist:
Bitte nicht wegen einer Karte Acker/Wald/... größer machen als sie sind, nur damit keine Lücken in so einer Karte erscheinen.

Edbert (EvanE)

Wolfgang B wrote:

Die Natur hat auch keine Lücken.

In der Natur sind eine Straße oder ein Graben aber auch kein Strich.
Etwas Abstraktion gehört schon dazu.

EvanE wrote:

Wolfgang B wrote:

Die Dinge sind nicht immer so klar, wie man sich das wünscht.

Doch!
...
Die Natur hat auch keine Lücken.

Wenn du die Natur im subatomaren Bereich ansiehst, gibt es in der Hauptsache Lücken und nur wenig Teilchen. 😠

Für den von uns betrachteten Makro-Bereich gilt deine Aussage zwar, aber das heißt noch lange nicht, dass wir jedes Steinchen erfassen müssen. In meinen Augen ist es nicht notwendig eine lückenlose Karte erstellen zu wollen. Wenn jemand nur die größeren Dinge wie Acker und Wald erfassen will, aber die kleine Dinge dazwischen diesem Mapper zu lästig sind, dann sollten wir ohne Murren damit leben. Schließlich kann ja später jemand, den das stört, die Zwischenräume seinerseits auffüllen.

Genau lelzteres habe ich getan. Nur waren da keine keine Lücken aufzufüllen, sondern nur auszugleichen.

HeBri wrote:

Wolfgang B wrote:

Die Natur hat auch keine Lücken.

In der Natur sind eine Straße oder ein Graben aber auch kein Strich.
Etwas Abstraktion gehört schon dazu.

Sag das mal denjenigen, die Flächen an Straßen und andere Linien klatschen.

Wolfgang B wrote:

Die Natur hat auch keine Lücken.

Stimmt, in den disskutierten Fällen hat höchstens das Tagging-Schema bei OSM noch Lücken...

meint Sven, der bei der einen oder anderen Sache auch keine so rechte Idee hat 🙂

Radeln wrote:

Dinge, die nicht so klar sind, waren auch nicht gemeint, sondern ein eindeutiges direktes Angrenzen. Anderes Beispiel, zwei farmland-Flächen, die sich nur in der Färbung (Bing) unterscheiden. Die fasse ich auch mal zusammen. BTW, ein Feldrain z.B. sehe ich als zum Acker zugehörig.

Eben. DU siehst das so. Ich sehe das anders. Und jetzt kommst du daher und willst mir (und anderen) dein Mapping-Schema aufzwingen.

Wenn ich dann höre, so ist halt OSM, ziehts mir die Schuhe aus. Da gehört endlich mal etwas mehr Ordnung rein und das geht nur über klare Regeln.

Ich glaube, du hast ein grundlegendes Verständnisproblem. Nicht DU gibst die Regeln vor und auch nicht das Wiki. Vielleicht solltest du dir ein Projekt mit festen Regeln suchen.

Mal ne Frage: Wieviele NEUE Wege hast du eigentlich zu dem Projekt beigetragen?

EvanE wrote:

Was ich damit sagen will ist:
Bitte nicht wegen einer Karte Acker/Wald/... größer machen als sie sind, nur damit keine Lücken in so einer Karte erscheinen.

Du spricht mir aus der Seele. Ich versuche das zu mappen, was ich sehe (in der Natur oder auf Bing). Ich werde nicht einen Acker mit einem Feldweg verbinden (und dabei den dazwischen liegenden Graben und Buschwerk ignorieren) nur um irgendwelchen idealisierten Mapping-Schematas zu genügen.

Mut zur Lücke! ;-)

dgdg wrote:

Mal ne Frage: Wieviele NEUE Wege hast du eigentlich zu dem Projekt beigetragen?

Kannst du unter http://hdyc.neis-one.org/?Radeln selber nachsehen.

Edbert (EvanE)

dgdg wrote:

EvanE wrote:

... nur damit keine Lücken in so einer Karte erscheinen.

Du spricht mir aus der Seele.

Schließe mich uneingeschränkt an.

dgdg wrote:

Ich glaube, du hast ein grundlegendes Verständnisproblem. Nicht DU gibst die Regeln vor und auch nicht das Wiki. Vielleicht solltest du dir ein Projekt mit festen Regeln suchen.

Mal ne Frage: Wieviele NEUE Wege hast du eigentlich zu dem Projekt beigetragen?

Was soll die bescheuerte Frage?

dgdg wrote:

EvanE wrote:

Was ich damit sagen will ist:
Bitte nicht wegen einer Karte Acker/Wald/... größer machen als sie sind, nur damit keine Lücken in so einer Karte erscheinen.

Du spricht mir aus der Seele. Ich versuche das zu mappen, was ich sehe (in der Natur oder auf Bing). Ich werde nicht einen Acker mit einem Feldweg verbinden (und dabei den dazwischen liegenden Graben und Buschwerk ignorieren) nur um irgendwelchen idealisierten Mapping-Schematas zu genügen.

Mut zur Lücke! ;-)

Versuch macht Kluch. Man siehts.

EvanE wrote:

dgdg wrote:

Mal ne Frage: Wieviele NEUE Wege hast du eigentlich zu dem Projekt beigetragen?

Kannst du unter http://hdyc.neis-one.org/?Radeln selber nachsehen.

Kannte ich nicht. Danke!