Felder und äcker eintragen?

Hallo, ich bin zur Zeit damit besch�ftigt, in der Oberpfalz Stra�en, W�lder, usw. von der Luftbildern abzuzeichnen. Dabei ist mir aufgefallen, dass landwirtschaftlich genutzte Fl�chen wie �cker, Weiden, Felder nie als Fl�che mit dem Tag landuse=farm oder landuse=farmyard eingetragen sind. Hat das einen bestimmten Zweck oder waren bisher alle zu faul dazu? Und soll ich das nun auch frei lassen oder eintragen?

Es gibt Leute, die das taggen. Meiner Meinung nach ist es landwirtschaftliche Nutzung in Deutschland der Standardfall und daher tagge ich ihn nicht. Ausnahmen wie Landschaftsschutzgebiete tagge ich wieder.

Es gibt aber auch große Bereiche, wo der Wald die Landschaft prägt. Und dieser wird ja wohl regelmäßig getagt. Und warum sollte man dann die Äcker, Wiesen, Heide, Moorlandschaften etc. vernachlässigen? Ich trage solche Flächen - also auch Ackerland - regelmässig ein. Und wenn ich mir die Landschaft im weiten Deutschland so ansehe, gibt es mittlerweile richtig schöne Ecken, wo all das eingepflegt wurde. Wenn es tatsächlich zu vernachlässigen wäre, würde landuse=farm/farmyard ja wohl überflüssig sein, oder?!?

Ich könnte mir auch vorstellen dass manchmal nicht ganz klar ist ob es sich tatsächlich um farmland handelt oder was genau als farmland einzuordnen ist. Zum Beispiel Wiesen, Wiesen mit Obstbäumen, große Gärten, Weiden? Manchmal ist das optisch auch nicht so leicht zu unterscheiden. Wald ist da meistens eindeutiger, auch wenn man noch viele Arten von Wald unterscheiden könnte und nicht immer ganz klar ist wie viele Bäume es sein müssen damit es ein Wald ist… :wink:

Da haben wir es wieder. Der eine gibt sich bei der Darstellung der Landnutzung Mühe, dem anderem reicht ein Schematischer Wald und der Rest kann leer bleiben. Da sollte man sich einigen. Und zwar bevor sich die Unterschiedlichen Ansichten treffen und der erste anfängt die seiner Meinung nach überflüssigen Landsuses komplett zu löschen. Oder anders herum alles erfasst, die Mehrheit aber keine Landnutzung möchte und somit alles für Katz ist. Hat man die Infos, spricht meiner Meinung nichts dagegen das auch einzutragen. http://www.openstreetmap.org/?lat=51.2882&lon=11.41&zoom=12&layers=B000FTF Macht meine Vorstellung einer Karte nur runder. Das ist aber nur meine persöhnliche Meinung. Wohin geht es letztendlich, Landnutzung ja und umfassend, nur dieses und jenes, oder möchte die Streetmap komplett darauf verzichten?

An anderer Stelle wird darüber diskutiert, wie und ob Verkehrszeichen getaggt werden sollen. Was für Straßennavigation sicher von Vorteil ist. Eingetragene Landnutzung ist das, was die Karte am Ende “farblich” und aussagefähig macht. Da OSM aus den unterschiedlichsten Gründen genutzt wird, sollte so viel wie möglich eingegeben werden. Was der Einzelne letzten Endes darstellen läßt (typ-Datei), ist seine Sache. Gruß Matthias

Ich werde Äcker ab sofort immer eintragen. Wird zwar eine Menge Arbeit sein, weil es bisher nicht viele gemacht haben, aber so hat man wenigstens keine weißen Flecken in der Karte und jeder Fläche ist irgendein Landnutzungstyp zugewiesen. Wäre sonst auch unsinnig, so eiin tag einzuführen, wenn es dann doch niemand benutzt.

Willkommen im Club.

Dem kann ich mich nur anschließen. :slight_smile:

Fuer mich gehoeren auch keine weissen Flecken in die Karte. Der o.a. Link (http://www.openstreetmap.org/?lat=51.2882&lon=11.41&zoom=12&layers=B000FTF) ist in meinen Augen ein sehr schoenes Beispiel, wie ein ordentlich in OSM erfasstes Gebiet aussehen sollte. (Lediglich die vielen Parkplatzmarkierungen in Rossleben finde ich etwas uebertrieben. Eine Eintragung als Parkplatz setzt in meinen Augen eine Mindestgroesse vorraus, nicht jede einzelne Parkbucht verdient diese Kennzeichnung.) Wenn einer die Landwirtschaftlichen Nutzflaechen nicht eintragen will, so kann er das von mir aus gerne lassen. Es gibt ja keinen Zwang, hier irgendetwas machen zu muessen. (Ich trage ja auch nicht alles ien, was anderen Leuten wichtig erscheint.) Falls einer aber auf die Idee kommen sollte, derartige Eintragungen von anderen grundlos zu loeschen, so waere das natuerlich nicht mehr im Sinne der Sache. In abesehbarer Zeit werden wir uns auch noch mal mit dem Thema Vandalismus ernsthaft auseinandersetzen muessen. Gruss Torsten

Gibt es den “Vorkommnisse” dieser Art, das man sich mit Vandalismus auseinandersetzen muss und was wäre Deiner Einschätzung nach überhaupt Vandalismus? Ich selbst habe soetwas noch nie festgestellt, wobei das gelegentliche Löschen oder Überschreiben von Tracks eher in den Bereich von Unkenntnis zu vermuten ist. Ich denke, hier sollte man nicht übertreiben und die Kirche im Dorf lassen.

Mir sind bisher auch keine derartigen Vorkommnisse bekannt (mit Vandalismus meine ich vorsaetzliche Stoerungen in der Datenbank). Aber angesichts der zunehmenden Verbreitung wird es nur eine Frage der Zeit sein, bis das auftritt. Grenzwertig sehe ich bereits die Sache im Wiki mit dem smoothness-Tag. Das ist vorgeschlagen und darueber ist erfolgreich abgestimmt worden, aber ein einzelner User mag es einfach nicht und verschiebt es immer wieder zu den rejected features. Gruss Torsten

Ich sehe da eher ein technisches Problem dringender als Vandalismus. Es gibt immer mehr Flächenfeatures, die die Ways großflächig überdecken. Dadurch wird das Selektieren der richtigen Ways und Nodes und das Übersicht behalten immer schwieriger, die Fehlerquote steigt. Was da fehlt ist ein Filter-Feature im Editor, das es erlaubt, alle Flächen in einge eigene Layer zu ziehen oder vorübergehend auszublenden. Würde glaub ich den “Vandalismus” drastisch reduzieren.

Aussehen könnte. Mangels einheitlicher Vorgehensweise, kann man nicht auf ein Ziel hin arbeiten. Da fehlen sogar noch Parkflächen. Links und rechts der Wendelsteiner Straße sind ebenfalls Parkflächen. Es fehlt da noch ähnlich des Footways ein Tag. parking=booth/left/right/no. Die Buchten im Dichterviertel sind der typischen DDR Arbeiterviertel Bauweise geschuldet. Da wurde vor jedem Block eine Parkbucht für 5 bis 15 Fahrzeuge gebaut. Dazu kommen einzelne Garagenanlagen in der Nähe. Großflächige Parkgelegenheiten gibt es nicht. Das gibt bei der heutigen Autodichte immer wieder Probleme. Deswegen habe ich die Buchten alle markiert, bevor der Auswärtige mangels Überblick wie üblich irgendwo auf der Hauptstraße den Verkehr behindert.

Kommt drauf an wie man es umsetzt. Ich trenne z.B. grundsätzlich die Landnutzung von Objekten. Eine Straße liegt ja auf der Trasse, nicht zwei Grünstreifen links und rechts der Straße, ungünstigerweise vielleicht noch direkt an die Straße gepappt. Ist zwar praktisch wenn man Flächen zusammen mit der Straße verschieben möchte, ansonsten hat das aber nur Nachteile. Hier ein Ausschnitt aus meinem oben geposteten Gebiet.

Viele Wege fuehren nach Rom, Hauptsache man kommt ans Ziel.

amenity=parking sehe ich nicht unbedingt für Anliegerverkehr. Aber ok, ich kenne die Lage vor Ort nicht, mir viel das nur in der Karte auf, dass man da nahezu ueberall parken kann/soll.

Fuer meinen Geschmack koennten die einzelnen Gebiete kleiner zugeschnitten sein. Dann braucht man auch nur in Ausnahmefaellen die multipolygon-Relationen. Auch wenn es prinzipiell ordentlich markiert ist, in der Praxis halte ich solche Konstrukte naemlich fuer zu kompliziert und damit fuer zu fehleranfaellig. Dem urspruenglichen Ersteller ist (zumindest anfangs) zwar ganz klar, welche Gebiete letztendlich wo mit dazugehoeren, fuer einen Aussenstehenden (oder fuer den Ersteller nach einiger Zeit) ist das aber manchmal nur schwer zu durchschauen. Wenn es ordentliche Luftbilder gibt, dann probiere ich basierend darauf jedes Feld als einzelne Flaeche in OSM einzutragen. Das macht zwar erstmal eine ziemliche Arbeit, aber hey wir sind ja Tausende von Leuten, die sich die Arbeit teilen. Im Ergebnis erhaelt man dann aber eine ordentliche Grundlage fuer weitere Verfeinerungen (z.B. Einzeichnen von Graeben und Knicks, Unterscheidung von Aeckern und Weiden). Gruss Torsten

Jetzt fallen gleich die schwarzen Raben vom Himmel und zerpflücken Dir Deine Argunmente … Warte nur ein Weilchen …

Ist eben kein Anlieger. Das Wohngebiet ist generell 30 Zone (alles maxspeed 30) aber es sind alles öffentliche Straßen mit Rechts vor Links, auch die Zufahrten zwischen den einzelnen Wöhnblöcken. Ich kann und will dort auch nichts taggen, was es in der Realität nicht gibt. Sollte unwahrscheinlicherweise die Schilderseuche einzug halten, wird das natürlich geändert. Aber bis dahin ist das so nur die Wiedergabe der realen Vorlage. Gleiches hatten wir ja schon bei den Feldwegen. Da stehen hier bei max. einem Prozent enstprechende Schilder. Der Rest hat kein agri etc. also wird das auch nicht getaggt. Hier vertraut man auf gesunden Menschenverstand und nicht auf die Schildbürger. Sollte dann dennoch ein Porschefahrer über einen Grade 4 abkürzen wollen, kann ich da nur owned sagen.

So habe ich anfangs begonnen und bin dann auf Multis umgestiegen. Ich fasse die Gebiete zwischen Straßen oder einem Fluß in Rastern zusammen. Dabei sollte ein Raster nie mehr als 500 Nodes im Outer haben. Getrennt durch einen Puffer, z.B. die Trasse der Straße. Darin alles was die Landwirtschaft durchschneidet. Der Grund war einfach. War in der Praxis nicht gerade schön. Wenn ich alles aneinander lege, habe ich dort großflächig das Überschneidungsproblem. War sehr undurchsichtig und schwierig zu bearbeiten. Mit einem Multipoly habe ich das nicht. Die berühren sich nur selbst oder die puffernde Trasse, welche die Raster trennt. So liegt innerhalb alles frei. Ich kann jederzeit einen inner hinzufügen, löschen oder ändern, ohne das ich mich um die angrenzenden Fläche sorgen muss. Das Problem der Pflege hast du so oder so. Eben durch eine fehlende einheitliche Vorgehensweise. Jeder macht es irgendwie anders. Man muss sich je nach Region und Bearbeiter also immer auf andere Umstände einstellen. Ich mache Multipolygon Raster. Ein anderer klatscht alles an die Wege, der nächste zieht um jeden Straßenblock ein Residential und wieder ein anderer legt Layer übereinender.

Ich meine nicht die rechtliche Beschraenkung (gesperrt, Anlieger frei), sondern dass faktisch nur Leute dort parken, die auch genau dahin wollen. Was nuetzt es einem in der Karte, wenn da alle 100m eine Parkmoeglichkeit eingegtragen ist?

Kannst du das weiter erlaeutern? Wenn ich alles nebeneinanderlege, dann ueberschneidet sich da doch nichts.

Das mit dem schwieriger (im Sinne von aufwendiger) glaube ich. Aber undurchsichtig finde ich es nicht, da man ja immer alles im Blick hat. Bei groesseren Outer-Polygonen hat man das umschliessende Polygon haeufig gar nicht mehr auf dem Schirm, wenn man im Inneren was aendert. Da ist einem Fremden dann schnell nicht mehr klar, wie sich seine Aenderungen ein paar Kilometer weiter noch auswirken.

Es gibt sicherlich verschiedene Wege, wie man ein und die selbe Sache in OSM eintragen kann. Und dann gibt es aber noch offensichtliche Fehler :slight_smile: Gruss Torsten

Dahin wollen und frei sind zwei Kisten. Manchmal ist hier vorne alles zu, inklusive halbseitig Straße, hinter der Kurve ist aber frei. Das weiß ich, da ich hier wohne, der Auswärtige aber nicht. Der soll ja die Parkmöglichkeiten finden und nicht stundenlang suchen, am besten da wo nichts mit Parken ist. Die ganz raus zu lassen wäre auch wieder nicht richtig. Wer nicht alles abklappert sieht teilweise nur beidseitiges Parkverbot an den Straßen und fährt garnicht erst rein, parkt dann irgendwo wild.

Nicht neben. Schau dir mal das Bild an. Ich nutze bei Landflächen die selben Knoten um Daten zu sparen und um Löcher zu vermeiden. Das nebeneinander habe ich auch probiert. War in der Praxis aber ebenso unschön und brachte die doppelte Datenenmenge an Knoten und zusätzliche Areas durch einzelne Äcker. Die spare ich durch einen großen Acker als Outer ein. Ich nutze immer das was die meiste Fläche besetzt als Outer. Draußen sind das die Äcker. Darin als Inner alles andere.

Das Problem habe ich doch bei Relationen generell. 500 km Bundesstraße habe ich auch nicht mit einmal am Schirm. Outer wird doch komplett herunter geladen, der Rest darin wird aufgelistet, fehlendes als “unvollständig”. Ich mache doch keine 50 km breiten Teile. Den Rest kann man wie üblich nachladen und sieht alles gelistete auch dargestellt. Und wenn sich etwas im inneren ändert dann ist doch gerade bei der Umstzung kein Konflikt zu erwarten. Das sind ja eigenständige Flächen innerhalb einer großen Fläche, die verbindet nur ein Multipolygon mit der Rolle inner. Wenn ich nicht über einen anderen Inner hinweg zeichne, wirkt sich das nirgends aus. Fläche gegen den Uhrzeigersinn zeichnen, dem Multipolygon hinzufügen, role inner vergeben. Es ändert sich einzig die Anzahl dem Member der jeweiligen Relation, ansonsten nichts. Im grunde ist es ja im Moment auch vollkommen egal wie. Solange nicht eindeutig geklärt ist wie genau, kann jeder probieren wie er will. Für mich persöhnlich hat sich das durchgesetzt. Sollte man sich wieder erwarten offiziell auf etwas anderes einheitliches einigen, habe ich kein Problem das dann auch entsprechend anzupassen. Im Moment bin ich ohnehin Einzellkämpfer. Für die Ecke hat sich 4 Jahre lang keiner interessiert. Wird sich so schnell auch in Zukunft nicht ändern. 99% dort sind von mir. Beschwert hat sich auch noch keiner. Mal schauen was die Zukunft bringt.

Es gibt doch kein richtig und falsch. :wink: Ich persöhnlich sehe das auch als Fehler. Aber da wirst du immer einen Finden der das gut findet und anderen auch noch so beibringt. Solange das nicht offiziell und unwiderlegbar als böse gilt, wird auch das weiter praktiziert.

So habe ich das ja auch verstanden. Aber wenn ich zwei Flaechen an den Grenzen die selben Knoten nutzen lasse, dann ueberschneidet sich da doch immer noch nichts, damit liegen sie doch weiterhin nebeneinander.

Mit dem Argument koennte man logisch fortgesetzt auch ganz Deutschland als landuse=farm eintragen. Dann hat man schon mal eine Menge Daten gespart und waere zu xx% auch schon richtig. Letztendlich hat ein Acker hier mit einem in 2km Entfernung aber keinen Zusammenhang, so dass ich es als falsch empfinde, sie in der Datenbank als ein Element zusammenzufassen.

Auch da macht es ja immer wieder Probleme. allerdings passiert da nichts schlimemres, als dass die Relation kaputt geht. Jedes einzelne Mitglied ist fuer sich genommen ja ein korrekter Eintrag. Bei den multipolygon-Relation stimmt das leider nicht, ohne die Relation sind die outer-Polygone fehlerhaft, da sie eine Landnutzung an Stellen definieren, wo sie so in Wirklichkeit gar nicht ist.

Das mag ja bei deinem Lieblingseditor so sein. Wenn ein anderer in “dein Revier” kommt, benutzt er aber vielleicht einen ganz anderen Editor.

Andere Leute tun das aber mit den selben Argumenten wie bei dir.

Bei Mapnik und Osmarender vielleicht nicht, aber die Garminkarten bekommen deine Gegend mit all den ueberlagernden Elemente nicht mehr sauber dargestellt. (Sie kenne auch die multipolygon-Relation nicht, aber selbst die Zeichenprioritaet klappt da nicht mehr.)

Ich habe auch bestimmt nicht vor, dir vorzuschreiben, wie du was zu machen hast. Einerseits bin ich gerne bereit, von der Zeichentechnik anderer zu lernen. (Mein eigener Stil hat sich im Laufe der Zeit durchaus weiterentwickelt. und ich denke, dass dieser prozess auch noch nicht abgeschlossen ist.) Auf der anderen Seite betrachte ich solche Diskussionen auch als Lobby-Arbeit, damit sich auch ohne verbindliche Vorgaben ein einheitliches Vorgehen bei OSM weitgehend durchsetzt. So setze ich ich als Massstab fuer “korrektes” Tagging die englischen Mapfeatures an. Die scheinen mir am Besten von der Gemeinschaft kontrolliert, und bei der deutschen Uebersetzung gibt es z.T. schon deutliche Abweichungen. Fuer weitere Details halte ich mich dann an die entsprechenden Wiki-Seiten, auch da bevorzugt die englischsprachige Version. Daraus wuerden sich fuer dein Gebiet folgende “Probleme” ergeben: - landuse=gras gibt es nicht, stattdessen waere wohl landuse=meadow angebracht. - die Richtung der inner-Polygone sollte egal sein (das mit dem Gegendenuhrzeigersinn ist allein ein Hack fuer Mapnik) - der Rand eines inner-Polygon sollte nicht den Rand des outer-Polygon beruehren (steht so allerdings nur auf der Diskussionsseite) Trotzallem sieht dein Gebiet bei Mapnik und Osmarender sehr gut aus. Offensichtlich ist dein Stil auf diese Ausgaben hin erfolgreich optimiert. Gruss Torsten