Hi,
diese Kreuzung wurde detailgemappt mit diversen Spuren etc.
Ok, sieht schön aus, nur leider wurde dadurch das Routing kaputt gemacht:
Typisches Beispiel für die Tatsache: Je komplexer etwas ist, desto fehleranfälliger ist es. 
Chris
Vielleicht sollte man mal den Fehler suchen. Denn wär’s ganz korrekt eingetragen, sollte das ja funktionieren.
Na, der Fehler ist klar (links das oneway). Ich wollte es nur mal als abschreckendes Beispiel demonstrieren.
Ja, wenn man Start/Ziel tauscht, sieht es besser aus.
Das oneway setzt sich auch rechts fort.
Wenn sich einer dransetzt, möge er beides prüfen/korrigieren.
Edbert (EvanE)
Und wer hat Wolkenmacher.kom gegründet? Natürlich Stefan Küste der jetzt bei Mikroweich “arbeitet”… da braucht einem nichts zu wundern. Genau so wie das neue hässliche Logo
Und Stefan Küste ist schuld dran, das sich das Datenmodel von OSM nicht richtig weiter entwickeln konnte, so das Spuren und solche Kreuzungen logischer gemappt werden können.
Abgesehen davon, dass man “Modell” mit zwei l schreibt (oder neigt edwin neuerdings zu Anglizismen 
), liegt es doch an uns, das Datenmodel weiterzuentwickeln.
edwin:
Mach doch einen Vorschlag, wie man sowas “besser” lösen kann, statt (fast) immer nur gehässige Kommentare abzugeben. In einem entsprechenden Proposal könntest du dann beweisen, dass du - außer fleißigem kartieren - auch sachdienliche Vorschläge machen kannst, die OSM weiterbringen und es anderen Mappern (Datenerfassern) leichter machen. Vielleicht macht es dir bis dahin folgendes plugin für JOSM leichter:
http://wiki.openstreetmap.org/wiki/DE:JOSM/Plugins/Turnrestrictions
Zurück zum Thema:
Wenn ich mir die Gegend anschaue, frage ich mich, ob es wirklich sinnvoll ist, jeden Acker einzeln als farmland zu erfassen. Da reicht doch ein Gesamtumriss.
Also wenn man Ackerflächen erfassen will dann finde ich es sinnvoller einzelne Äcker zu erfassen (denen man dann Details wie Besitzer, Getreideart etc. zufügen kann), als eine Gegend großflächig braun zu färben und dabei meist vergisst kleinere Wäldchen,
Bauernhöfe etc. auszuschneiden.
Die Kreuzung werde ich heute abend reparieren wenn es noch keiner gemacht hat.
Chris
wurde gestern abend schon repariert (nicht von mir)
Ciao,
Frank
Komisch. Da machst Du einen thread über die Nachteile des Detailmappings auf und plädierst hier plötzlich dafür 
Besitzer und Getreideart wechseln, währen die überwiegende Nutzung meist länger erhalten bleibt. Wenn den Wechsel der freiwillige Mapper nicht mitbekommt, haben wir falsche Daten. Richtig lustig wird es, wenn die Feldfrüchte durch Zwischenfrüchte (z.B. Raps) unterjährig wechseln.
Das muss doch auch alles zeitnah gepflegt werden.
Meine Meinung:
Lieber richtige allgemeine Daten mit einer gewissen Abstraktion als falsche Detaildaten. Wegen der kleineren Wäldchen und einzelner Höfe mache ich mir keine Sorgen. Ich habe hier einen Fall getestet und einen farmjard mit building innerhalb eines farmland angelegt, ohne diese in einem MP auszuschneiden. Mapnik und Osmarender zeigen es .
Mir ist eine fehlende Information, die jemand sieht und nachpflegt, lieber als eine falsche Information.
Es gibt auch noch andere Renderer, die es dann nicht zeigen. Ich hatte mal mit Maperitive Probleme bei so einer Situation. Das ist ein Glückspiel und hängt von der Reihenfolge des Renderings der Flächen ab. Kann gut gehen, kann auch nicht gut gehen
Dadurch dass die Renderer es richtig anzeigen ist es aber datentechnisch noch nicht korrekt.
farmland sind die Flächen ohne Ställe, Höfe etc.
farmyard sind die Höfe
dann gibt es noch landuse=farm, wo die Meinung auseinandergeht ob das äquivalent zu farmland
oder die Summe aus farmyard und farmland sein soll.
Chris
Da wir ja nicht für Renderer…
Das Problem könnte man umgehen und dabei jede Menge MP’s mit all ihren Fehleranfälligkeiten vermeiden.
Was haltet ihr von folgender Regel (auch für Renderer):
Befindet sich ein kleines Polygon mit Flächeneigenschaften innerhalb eines anderen größeren Polygons mit anderen Flächeneigenschaften auf demselben Layer, so gilt in diesem Bereich die Flächeneigenschaft des kleinen Polygons als “Ausschnitt” aus dem größeren Polygon.
Dann hätten wir die Lichtung im Wald, den See im Acker, die Insel im See ohne MP. Ob das auch bei outer-inner-outer funktioniert weiß ich nicht.
Was allerdings dagegen sprechen könnte, wären Probleme der Renderer mit dieser Regel, denn auch wenn wir nicht…
…ihre Grenzen sollten wir berücksichtigen. (siehe Fußnote)
Es sind zwar beides landuse-values, aber bei anderen (z.B. cemetry in residential) funktioniert es dich auch ohne MP
Naja, auf dem Friedhof “wohnen” ja auch Leute.
Spass beiseite, ein Friedhof ist für mich kein Wohngebiet.
Kann ich daraus schließen, dass du diesen mit einem MP als inner und dem residential als outer taggen würdest? Und dann nehmen wir noch die ganzen village_green usw. dazu. Und den Dorfteich natürlich auch. Jeder Kinderspielplatz und Parkplatz als inner? Denn da wohnt auch keiner (legal).
In der deutschen wiki steht bei landuse: überwiegende Nutzung von Gebieten und Flächen…
und englisch: For describing the primary use of areas of land.
Wenn ich jetzt engstirnig werde, müsste ich mir nun überall, wo ich tagge, den Flächennutzungsplan besorgen.
Zum Glück sind wir noch im Thema “Detailmapping”.
cemetery und village_green würde ich ausschneiden. Parkplatz, Spielplatz, kleinen Teich und Gebäude natürlich nicht.
Kannst du dafür auch einen Grund nennen?
Was hältst du als anerkannnt erfahrener Mapper eigentlich von meinem obigen Vorschlag unter #12?
Faustformel: landuses sollten sich nicht überlappen (Parkplatz, Spielplatz und Gebäude sind ja kein landuse),
alles andere entscheide ich nach Bauchgefühl.
Zum Deinem Vorschlag: Im Zweifelsfall ist es sicher nicht verkehrt kleine Polygone über größere zu legen.
Besser ist aber wenn die Daten sauber sind und der Renderer nicht raten muss.
Chris
@chris66:
Dann sind die Renderer also so schlau, dass sie bei verschiedenen keys der Flächen erkennen, welche Fläche obendrüber zu malen ist. Bei gleichem key, aber verschiedenen values versagt deren Logik ???
Und weiter heißt dies:
Wir fördern die Inflation der MP’s und mindern dadurch die Fehlerresistenz gegen unbedarfte (Neu-)Mapper.
Aber da mein Bauch altesbedingt immer größer wird, habe ich auch mehr Platz für ein toleranteres Bauchgefühl
Edit: Dreckfuhler berüchtigt 
Naja als schlau würde ich die Renderer nicht gerade bezeichnen … sie machen ja nur genau das was man ihnen vorgibt 
Es liegt also am Ersteller der Karten die Reihenfolge der Layer so einzustellen wie man es möchte.
Beispiel: die landuse Sachen werden z.B. bei Mapnik gleich am Anfang gezeichnet und da natürlich auch in einer bestimmten Reihenfolge. Da z.B. landuse=farmyard erst nach landuse=meadow oder landuse=farmland gezeichnet werden macht das natürlich nichts aus wenn das nicht sauber ausgeschnitten wird sondern landuse=farmyard einfach über eine andere landuse gelegt wird.
es kommt halt immer auf die Reihenfolge der Layer an wie diese in den einzelnen Renderern nacheinander erstellt werden. Wenn landuse=forest vor landuse=meadow kommt könnte man auch eine kleine Wiese einfach über das Waldpolygon legen, wäre es umgedreht könnte man einen kleinen Wald einfach über das Wiesen Polygon legen.
Da man aber nicht weiß welcher Renderer was genau in welcher Reihenfolge macht, sollte man doch besser alles sauber machen.
Ein Beispiel wo das schiefgehen kann ist z.B. folgendes: landuse=scrub wird recht häufig verwendet, befindet sich in dem Gebiet z.B. ein Sportplatz könnte man den ja einfach so drüberlegen, wie man das auch bein einem Sportplatz innerhalb einer bewohnten Fläche machen kann (landuse=residential).
Aber: landuse=scrub befindet sich beim Mapnik Renderer in dem water layer (warum auch immer) und wird erst als sehr später layer gezeichnet, überzeichnet also dann auch die Sachen die eigentlich darüber liegen sollten wie z.B den Sportplatz.
Da nun aber jeder Renderer und jeder der eine Karte erstellt, die Layer nach eigenen Vorgaben setzt sollte man möglichst keine Überlagerungen von Flächen vornehmen oder halt eine generelle Vorgabe für die Renderer geben …
z.B erst alle landuse Sachen … dann alle anderen Flächen … ohne diese Vorgabe sollte man Überschneidungen von Flächen wohl vermeiden.