Jagen in Wäldern als Multipolygon?

Hallo zusammen,

ich versuche, die Einteilungen des Reichswaldes in sog. “Jagen” (siehe Nummern in http://www.openstreetmap.org/?lat=51.7344&lon=6.0895&zoom=14&layers=B000FTF)), sinnvoll in die Datenbank einzufügen.

Erst habe ich dafür einfach Polygone mit area=yes und name= verwendet, was aber den Nachteil hat, dass die Kanten der (rechteckigen) Jagen sich mit den begrenzenden Wegen überlappen und die Informationen so eigentlich doppelt vorliegen.

Nun bin ich auf die Idee gekommen, Relationen (type=multypolygon, name=) mit den begrenzenden Wegen als “outer”-Elemente, was mir als wesentlich bessere Lösung erscheint. Leider gibt es (noch?) kein Tag für ‘Jagen’, so dass ich es erst nur die Jagennummern als “name” verwendet habe. Blöderweise weden diese dann von Mapnik als gelb gefüllt dargestellt, was sehr unschön ist. Ich weiß, wir mappen nicht für die Renderer, aber ich will ungern die Darstellung so “verschandeln”

Als Übergangslösung habe ich den Relationen also landuse=forest gesetzt, was dazu führt, dass über den eigentlichen Wald ein Zweiter gerendert wird, was wiederum dazu führt, dass die Wald-Muster teilweise versetzt erscheinen. Schlimmer finde ich aber, dass das so ja logisch nicht richtig ist, es sind ja keine zwei Wälder übereinander.

Ich suche eigentlich nur eine einfache Lösung um für ein von Wegen begrenztes Rechteck einen Namen zu vergeben, der dann in der MItte des Rechtecks angezeigt wird. Hat jemand einen Tipp?

Noch etwas anderes. Um die Wege als äußere Grenzen für die Jagen zu verwenden, musste ich sie an den Kreuzungen auftrennen, was aber dazu führt, dass evtl. vergebene Namen für jedes Segment einzeln gerendert werden (siehe http://www.openstreetmap.org/?lat=51.72498&lon=6.08173&zoom=15&layers=B000FTF)). Gibt es hierfür eine Lösung? Sollte man Routen verwenden?

Vielen Dank und viele Grüße,
Florian

Laut Wikipedia sind “Jagen” forstwirtschaftliche Abteilungen um die Waldnutzung zu organisieren.
Ich bin sicher nicht der Einzige, dem “Jagen” kein Begriff war.
Forstfläche/-abteilung/-distrikt/-… ließe den Sinn leichter erfassen.

Du kannst die Grenzen auch neben den Wegen zeichnen, füllt aber die Datenbank zusätzlich.
Weg über Weg ist definitiv keine gute Idee.

Relation erst einmal schön und gut, aber was ist dann das “inner”-Element?
Wie wäre es den ganzen Wald als “outer” und die Forstflächen als “inner” zu deklarieren?
Wäre für deinen Fall nicht type=boundary + boundary=civil + name=* sinnvoller als ein Multipolygon ohne “inner”?
Einen eigenen Wert für Forst- oder Landwirtschaft gibt es zur Zeit nicht.

Siehe oben: Relation type=boundary …

Ich sehe eine Relation mit dem Namen des Weges nur an der Relation als einzige Lösung.
Aber ob die diversen Renderer das dann, wie von dir gewünscht, darstellen, ist eine andere Frage.

Osmarender zeigt deine Namen für Forstflächen (noch) nicht.
Das kann aber auch an den unterschiedlichen Update-Intervallen liegen.

Edbert (EvanE)

Hi Florian,

ich hab mir das mal angeschaut im JOSM… hab er ein bisserl gebraucht gesehen hab wie du es gemacht hast. Ganz schön aufwendig, keine leichte Kost.

Warum machst du nicht einfach einen einzelnen Punkt für jedes Jagen? Wie ich gesehn hab kann man landuse=forest als einzelnen Punkt erfassen, aber ich weiss nicht ob Mapnik dann auch rendert. Für name die Jagennummer und als note=“Jagennummer bzw. Nummer für Forstfläche/-abteilung/-distrikt”.

http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dforest

Dann hätte man immer noch zweimal verschiedene Einträge für einen Sachverhalt.
Das sollte man möglichst vermeiden.
Alternative wäre mMn place=locality + name= + …, wenn fpose einen Punkt benutzen will.

Allerdings sehe ich hier den Nachteil, dass die Grenze der Forstfläche nicht dokumentiert ist.
Die ist ja nicht immer durch Wege und damit eindeutig bestimmt.

Edbert (EvanE)

Moin,

Ich war schon immer der Meinung, dass area=yes eine extrem schlechte Loesung fuer das Problem ist, fuer das das Tag eingefuehrt worden ist (Fussgaengerzonen). Und der andauernde (Miss-)Brauch des Tags bestaetigt mich jedes mal wieder in dieser Ansicht.

Das mit den doppelten Kanten ist ansich erstmal kein Problem. Mal abgesehen davon, dass unserer Editoren mit ueberlagernden Wegen nicht ganz so doll zurechtkommen. Es wuerde bei JOSM meiner Meinung nach schon viel helfen, wenn man beim Anklicken von ueberlagernden Wegen automatisch immer einen Auswahldialog bekaeme, welchen Weg man denn nun meine. Quasi also das Verhalten mit gedrueckter STRG-Taste Default werden wuerde.
Wenn Wege und Flaechen netlang der selben Kannte verlaufen, dann ist es z.Z. nicht unueblich, die beiden leicht seitlich gegeneinander zu verschieben, so dass das Editieren leichter faellt. Ich habe mir angewoehnt, dabei darauf zu achten, dass jeder Knoten gedoppelt wird, so dass man spaeter mal die beiden Elemente leichter zusammenfuehren kann, in dem man einfach die doppelten Knoten verschmlizt.

Trage lieber die Kannten fuer die Flaechen als eigene Wege ein. Im Prinpzip kann man sicherlich jede Flaeche als Moltypolygon aus bestehenden Elmenten un ein paar fehlenden Kannten zusammensetzen. Die dabei entstehenden Datenstrukturen werden dann aber derartig komplex, so dass eine automatisierte Auswertung (wie z.B. das Rendering) nahezu unmoeglich wird.

Wenn du das so angehst, dann musst den den Wald als Ganzes loeschen. Stattdessen gibt es dann nur die Jagen als Einzelelemente, und der Wald ergibt sich dann automatisch als Summe seiner Einzelteile.

Wie schon angemerkt wurde: Da es fuer die Jagen bisher nichts spezifisches gibt, un dich auch nicht daraus bauen wuerde, dass was entsprechendes sich in absehbarer Zeit verbreitet, bietet sich dafuer place=locality an. Damit werden allgemein Gegenden oder Landstriche (im Gegensatz zu Ortschaften) mit Namen versehen.
Am einfachsten waere es, wenn du das Tag als Node setzt mit name= der Nummer der Jagd (ist das der Singular von Jagen?).
Am Ordentlichesten waere es, wenn du trotzdem die Jagen als Flaechen einzeichnen wuerdest.

Wie oben schon geschrieben: Trage die Flaechen lieber als eigene Elemente ein. Ansonsten ist das mit den mehrfachne Namen nun mal so, eine Route-relation ist fuer was ganz anders da: Eine Route ist eine Strecke (z.B. ein Wanderweg), der ueber mehrere einzelne Wege (mit eigenen/unterschiedlichen Namen) fuehrt.

Gruss
Torsten

Es gibt durchaus Überlegung auch für Straßen/Wege Relationen zu verwenden.
Straßen und Wege sind in OSM aus vielen Gründen oft in mehreren Teilstücken gespeichert.
Mit einer Relation kann eine Straße wieder zu einem Ganzen zusammengefasst werden.

Ob man dafür einen eigenen Typ will oder das existierende type=route + route=road verwendet,
ist erst mal zweitrangig. Passende Tags sind auf jeden Fall vorhanden.
Es spricht nichts dagegen die auch zu verwenden.

Edbert (EvanE)

Dabei geht aber die Information name=Reichswald für den Wald als Gesamtheit verloren. Wird zwar derzeit nirgendwo gerendert, wäre aber trotzdem schön

Ersatzweise wäre der Gesamtwald als area ohne landuse, nur mit name-tag zu belassen.

Gruß,
ajoessen

Das kann man ja machen. Ob das aber viel Sinn hat, bezweifel ich mal. Wenn es nur um die Darstellung beim Renderer geht, dann kann das besser der Renderer selber anhand seiner Regeln entscheiden. Denn zerstueckelte Strassen gibt es ja auch mit Abzweigungen und ich kenne auch Faelle, wo die einzelnen Teiabschnitte einer Strasse ueberhaupt nicht miteinander verbunden sind. In solchen Faellen soll der Renderer i.A. fuer jeden Einzelabschnitt den Namen anzeigen, er kann das also nicht von einer Relation abhaengig machen.

Einen zerstueckelte Strasse als route einzutragen ist einfach nur Bloedsinn. Dass die Teile zusammengehoeren, wird ja alleine schon durch das Konstrukt der Relation ausgedrueckt. Und mit einer Route hat die Strassenstueckellei ja ueberhaupt nichts zu tun.
Jede Relation immer route zu markieren, waere so, als ob man alle Linienobjekte immer als highway bezeichnen wuerde, d.h. eine Eisenbahn wuerde man als highway=railroad eintragen.

Gruss
Torsten

in http://wiki.openstreetmap.org/wiki/DE:Relations steht unter dem Stichwort etablierte Relationen:
route Bus, Fahrrad-Routen, Wander-Routen, Autobahnen, Land-/Kreisstraßen

Also was ist dein Einwand, einen Weg in einer Relation mit type=route zusammenzufassen.
Irgendeinen Typ muss eine Relation ja haben.

Edbert (EvanE)

Bei den Route-Relationen (vielleicht mit Ausnahme der Autobahnen), geht es darum, unterschiedliche Elemente in einer Relation zu sammeln, die hintereinander angeordnet die Route ergeben. Beim Beispiel einer Bundesstrasse: Ueber die gesamte Laenge werden alle Strassen als B123 bezeichnet. Im einen Dorf heisst die Strasse mit Namen aber Hauptstrasse, im naechsten Ort heisst sie Bundesstrasse, im dritten Ort hat sie wieder einen anderen Namen. Man hat also eine vielzahl echt unterschiedlicher Strassen, die nur ueber die Route miteinander verbunden sind.

Beim Zusammenfassen von Teilwegen geht es aber darum, dass man ein Element in der Wirklichkeit hat, dass nur aus datentechnischen Gruenden in der Datenbank in Teilstuecken abgelegt ist.

Aber dafuer muss ja kein bestehender Typ vergewaltigt werden. Es gab und gibt ja die verschiedensden Vorschlaege zu dem Thema, aktuell z.B. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways

Bislang hat sich aber noch keine zwingende Notwendigkeit zum Zusammenfassen ergeben (es brint halt keinen echten Mehrwert), so dass sich auch noch keiner der verschiedenen Vorschlaege wirklich durchsetzen konnte.

Gruss
Torsten

Das halte ich für eine gute Idee, da es sich bei den begrenzenden Wegen ja tatsächlich um “Grenzen” handelt, was z. B. vom Mapnik dann auch so dargestellt werden kann (s. z. B. die kleine “143” im Norden auf http://www.openstreetmap.org/?lat=51.74009&lon=6.09531&zoom=15&layers=B000FTF)). Seltsamerweise werden die Jagennummern auch um die Ecken gerendert, was etwas unschön ist, wohl aber ein Problem des Renderers. Ich werde das jetzt ersteinmal so fortführen. Vielleicht gibt es ja in einiger Zeit ein boundary=forest_section o. Ä. Vielleicht schlage ich das mal vor.

Ich denke, dass das Datenbanktechnisch die beste Lösung wäre, weil sonst doppelte Datenhaltung entsteht. Im Reichswald gibt es mehrere Wanderrouten, die werden aber leider auch noch nicht vom Mapnik gerendert.

Übrigens, hier http://www.openstreetmap.org/?lat=51.75287&lon=6.1114&zoom=15&layers=B000FTF hat jemand multipolygone mit landuse=farm eingetragen, was zum gleichen Problem mit den Straßennamen führt. Hier sieht man sehr schön die Segmente Offenbar gibt es dafür keine Patentlösung.

Danke und viele Grüße,
Florian

Sehe ich keinen Bedarf, da das mit boundary=civil mMn genau genug abgedeckt ist.

landuse=farm ist nur für Flächen definiert.
Also einfach die Flächen einzeichnen und mit landuse=farm taggen.
Da sehe ich, anders als in deinem Fall, keine Notwendigkeit für Relationen.

Übrigens pflügt der Bauer nicht die Straße, genauso wenig wie Bäume auf der Fahrbahn wachsen.
Von daher enden die Flächen für landuse=… vor den Wegen/Straßen.
Etwas anderes ist es, wenn Straßen/Wege Wald oder landwirtschaftliche Fläche durchschneiden
(wie im Reichswald). Dann kann landuse=… über die Straße/den Weg hinweg führen.
Die Grenze ist aber niemals identisch mir der Straßenmitte.

Edbert (EvanE)

Die Grenze kann schon in der Mitte liegen wenn es überhaupt eine gibt Grundbuchtechnisch… Meist sind diese Wälder Staatswälder und diese verpachten einzelne Parzellen an andere Leute. Aus organisatorischen Gründen werden diese Parzellen durchnummeriert, aber die amtlichen Grenzen ist eine andere Geschichte.

Aber wie du auch schon sagtest stehen die Bäume nicht bis zur Mitte der Straße also beginnt die Landnutzung Forst erst 1,2-3m oder mehr von der mitte Weg entfernt. Außer bei Forstwegen die gehören zum Forst, die Parzelle beginnt aber erst nach diesen 1,2-3m. Also müsste man einen kleineres Rechteck in das Rechteck aus den Wegen zeichnen, weil es dort in 1,2-3m erst die Parzelle beginnt. Die Wege gehören nicht zu Parzelle…

Ich find das nur total kompliziert mit hunderttausend Relationen und lauter zerstückelten Wegen… Wenn da ein zweiter Mapper kommt der nicht weiss wie der Trick funktioniert dann macht er das bestimmt kaputt.

Gruß Michael

PS: Die größte Nummer war jetzt 149 die ich gesehen hab also mindestens 149 Relationen! für a bisserl Wald. Wenn ich das bei unserm Staatsforst dem Ebersberger Forst machen würde bräuchte ich mindestens geschätzte 400 Relationen g er hat ja nur 90 km²

Da zwischen Strasse und angrenzender Flaeche aber auch kein Vakuum ist, ist es aber durchaus logisch, die Flaeche bis zur linienfoermigen Strasse einzutragen. Wie so oft bei OSM gibt es nunmal auch hier zwei Meinungen.

Und landuse=farm gibt uebrigens nicht nur die exakte Flaeche an, die vom Bauer gepfluegt wird, Randstreifen, Knicks und aehnliches werden da nicht extra unterschieden. landuse=residential beschraenkt sich ja auch nicht nur auf die reinen Wohnflaechen innerhalb der Gebaeude, sondern es umfasst die kompletten, VORWIEGEND zu Wohnzwecken genutzten Gebiete.

Gruss
Torsten

@miche101, @de_muur

Die Representation von Straßen/Wegen in OSM als Linie ist eine grobe Vereinfachung der Realität.
Straßen/Wege sind sowohl in Realität als auch grundbuchtechnisch gesehen Flächen.
Zu dieser Fläche gehören die Fahrbahn, Grenzstreifen, Rad-/Fußwege, ggfs. Graben/Stützmauern usw.
Diese Flächen gehören idR entsprechenden staatlichen Einheiten, die diese Flächen zuvor erwerben mussten.

Seht euch einfach mal eine Liegenschaftskarte oder die deutsche Grundkarte an.

Die Grenze zwischen Straßen/Wegen und Landnutzung scheint in OSM nur deshalb ein Vakuum zu sein,
da in den OSM-Daten die Breite der Fläche zugunsten einer einfacheren Representation unterschlagen wird.
Wenn man also (wie so oft betont) die Realität abbilden will, gibt es keinen Spielraum bis zur Straßenmitte.

Was die Relationen betrifft ist es die Frage, was günstiger ist:

1. viele Relationen innerhalb einer großen Fläche oder
2. viele Einzelflächen mit einer Relation für die Gesamtfläche

PS: Mein Beispiel sollte plakativ sein und unterschlug daher Hecken und andere Randbereiche der Flächen.

Edbert (EvanE)

Natürlich ist da kein Vakuum wenn man es aber wirklich seeeeeeehr genau nimmt, wie das hier in dem Betrag auch der Fall ist, findet hier eine andere Landnutzung statt. Diese Landnutzung: Fläche des Forstweg, Straße usw. gibt es noch nicht im OSM. Im OSM werden Wege als Linie dargestellt, aber dadurch wächst nicht der Wald?! Das der Renderer bei hohen Zoomwerten weiße Lücken aufweißt ist Problem des Renderer.

Außer natürlich man nimmt nicht so genau, aber dann macht man nicht solche Relationstricks und zerhackt unnötig die Wege… Wenn man es schon es nicht genau macht dann sollt man es wenigstens einfach zum editieren machen.

@EvanE
Seh ich genauso…

Dass Strassen in OSM als Linien und nicht als Flaechen erfasst werden, ist kein Renderer-Problem sondern hat zwei Ursachen:
Zum einen ist es historisch bedingt. Als man mit OSM angefangen hat, konnte sicherlich keiner vorstellen, was fuer Details Leute anhand der Luftbilder in die Karte malen wollen.
Zum anderen dient die OSM-Datenbank ja auch nicht nur als Malprogramm fuer Landkarten, sondern die Daten sollen auch anderweitig benutzt werden (z.B. Routing). Und fuer solche andere Nutzungen ist die eindimensionale Erfassung von Strassen wesentlich zweckmaessiger.

Betrachte das Problem Strasse und angrenzende Flaeche doch mal von der anderen Seite: Wenn man die Flaeche bis ganz an die Strasse heran zeichnet, dann drueckt man dadurch aus, dass die Flaeche durch die Strasse begrenzt ist. Diese Sichtweise stimmt voellig mit der Realitaet ueberein. Und wem das so nicht genau genug ist, der kann ja fuer die Strasse zusaetzlich die Breite angeben. (Wobei eigentlich eher die Fahrbahnbreite ueblich ist und nicht die Breite der kompletten Strasse.)

Soweit ist eigentlich alles stimmig, obige Erlaeuterung hat nur einen klitzekleinen Haken: Letztendlich wird in der Datenbank ja die Grenze nicht durch das Nachbarelement sondern duch die geografische Lage der Grenzpunkte definiert. Was fuer ein Element daneben liegt, weiss ein Element selber ja gar nicht.
Allerdings kann man diesem ansatz immer ncoh zu gute halten, dass der dabei erzeugte Fehler deutlich kleiner als die typische Genauigkeit der OSM-Daten ist.

Wenn man zwischen Flaeche und Strasse absichtlich einen Freiraum laesst, dann macht man ja aber auch bewusst einen Fehler, weil man fuer die freigelassene Flaeche keine Landnutzung in die Datenbank eintraegt. Der Fehler durch das Nichteintragen ist letztendlich genauso gross wie der Fehler, den man macht, wenn man die angrenzenden Flaeche bis zur Strassenmitte erweitert. Also was gewinnt man???

Irgendwo hatte hier mal jemand den Ansatz vorgestellt, den Raum rund um die Strassen als Grasflaeche oder als Buschland oder was auch immer da gerade so rumwaechst einzutragen. Quasi so als Hintergrund/Untergrund fuer die Strasse. Ich finde die Idee eigentlich nicht ganz falsch, im Falle des Waldes hier, waere der Hintergrund fuer die Wege aber immer noch Wald, so dass sich da nichts aendern wuerde.

Gruss
Torsten

Die Genauigkeit ist mir nicht so wichtig, wie es jetzt den Anschein genommen hat. Ich halt wie mein GPS-Logger was sind schon a paar meter Mir ist viel wichtiger das Verhältnis der Punkte zueinander, aber um das hier geht es nicht in dem Betrag.

Wo ich nicht übereinstimmen kann ist das ich eine Fläche verfälschen soll nur damit kein leerer Raum entsteht… weil die Datenbank oder der Renderer es vielleicht nicht schön finden. Wenn ich verfälsche dann wirds zum “Malprogramm fuer Landkarten”.

Grenzen werden bei uns immer über Punkte definiert… durch Grenzsteine, -pflöcke, -nägel, -stäbe, Meißelzeichen Festpunkte usw… Ich weiss nicht worauf du hinaus willst Grenzpunkte usw. werden in OSM noch nicht erfasst, dafür gibts ja das Vermessungsamt.

Rund um die Strassen als Grasfläche, Buschland oder anderes zu zeichnen finde ich wiederum Richtig wenn das der Fall ist. Straßen und Flächen zu verbinden finde ich meist falsch außer man kann auf der Fläche fahren/gehen… z.B. Parkplatz usw… Landwirtschaftliche Zugmaschinen oder Panzer gelten nicht

Gruß Michael

Zwar hier ziemlich OT, aber wie kommst du darauf? Siehe:
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurvey_point

Die grosse Quizfrage ist doch: Was gewinnt man, wenn man zwischen der Flaeche und der Strasse einen Freiraum laesst?

Fuer den anderen Ansatz sprechen ja verschiedene Vorteile (schoenere Karten; einfacheres Handling, wenn man den Verlauf noch mal korregieren muss).

Es kann ja bei OSM jeder das so eintragen, wie er will. Und abgesehen von der Optik hat das in diesem Fall ja auch keinerlei negative Auswirkungen, wenn es jeder irgendwie anders macht.

Interessant werden uebrigens die Faelle, wo die angrenzende Strasse nicht nur eine einfache Linie sondern ein ganzes LinienBuendel ist (Graben, Radweg, Knick und dann endlich die Fahrbahn). Aber diese Linienbuendel an sich sind ja noch ein ungeloestes Problem, so dass man sich jetzt nicht totdiskutieren muss, is wohin in einem solchen Fall welche Flaeche zu zeichnen waere.

Gruss
Torsten

Ja des sind ja Festpunkte von den man Bezug nimmt, der Nullpunkt sozusagen. Der kann irgendwo liegen und dient nicht als Punkt für eine Grenze… Bei einem Kohlekraftwerk gibt so einen Stein nur a bisserl größer der als Koordinaten Nullpunkt xyz für den Bau gedient hat und heute noch da steht.

Das Handling find ich von unverbundenen Flächen wesentlich einfacher, weil ich oft Punkte hinzufüge und dann ist ja nicht automatisch bei allen anderen Objekten das auch passiert, die aufeinander liegen. Zumindest im JOSM so…

Wie das dann Aussieht ist nicht schlimm hat sogar was… und wenn kann ich es immernoch zusammenfügen. Außerdem sieht man das erst ab 17 Zoomstufe… da stören mich noch viele andere Dinge des Renderergebnisses da ist das vernachlässigbar. Es gibt noch viel zu tun

Vor allem viel zu Mappen

Gruß Michael