Es wird hier ja nicht eine irgendwie bestimmte Information dargestellt. Der Renderer richtet sich nicht nach irgendeinem Unterschied der Eigenschaften. Er richtet sich nur danach, dass es unterschiedliche Datensätze sind. Dann müssten wir auch bei allen Straßen und Wegen Querstriche machen, wenn ein neuer OSM-Way anfängt.
Diesen Einwand verstehe ich nicht.
-
Wenn zwei Wälder mit unterschiedlichen Eigenschaften aneinandergrenzen (wie in meinem Beispiel), wieso soll dann der Grenzverlauf dazwischen keine irgendwie bestimmte Information sein?
-
Wenn zwischen zwei aneinandergrenzenden Ackerflächen der „Absatz“ (ohne Weg etcetera) on the ground deutlich sichtbar ist, wieso soll das dann keine irgendwie bestimmte Information sein? Zur Orientierung im Gelände kann so eine Ackergrenze in der Karte sogar eine sehr wertvolle Information sein und ich finde es schade, das Osmand das nicht rendert.
Ich bleibe dabei: Wenn gleichartige Flächen aneinandergrenzend separat gemappt sind, kann das eine relevante und on-the-ground sichtbare Information darstellen und sollte daher auch gerendert werden.
Zu deinem Einwand mit den Straßen und Wegen: Ja, von mir aus kann der Renderer da gern Querstriche machen, sofern man die Abgrenzung nicht ohnehin anhand einer Änderung der Darstellung im Rendering sieht (wenn sich z.B. ein tracktype ändert). Ich sehe allerdings einen kleinen Unterschied zwischen Linien und Flächen.
–ks
Die ganzen Formulierungen im Wiki sind erst im Verlauf des letzten Jahres so im Wiki erschienen. Davor standen dort so Fomulierungen wie: “The landuse tag is mostly used for larger areas and not at parcel granularity; as described above, a single shop in a residential area does not warrant an extra ‘commercial’ landuse” und “It is perfectly ok for a (small) road to lead through a residential area. Nevertheless some mappers split residential areas into blocks that do not contain any streets; others restrict such splitting to major thoroughfares, and still others draw one big residential area around a whole town.”
Und genau das ist unser Problem. Jeder kann die Wiki nach seinem Gusto umschreiben. Dabei wird dann einfach ignoriert, was in der ursprünglichen Bedeutung mit überwiegend oder predominantly ausgesagt wird. Dazu dann noch etwas “könnte, sollte” und ähnliche schwammige Dinge, die jeder Beliebigkeit Tür und Tor öffnen, und schon kann man behaupten, irgendetwas wäre selbstverständlich, obwohl genau das nicht der Fall ist.
Ich bin immer skeptisch, wenn ellenlange Erklärungen jüngeren Datums in der Wiki erscheinen. Erinnert mich irgendwie an seitenlange Schreiben von Rechtsanwälten, denen wirklich stichhaltige Argumente für ihre Auffassung der Rechtslage fehlen.
Ja. Nur ist mit meinem Workflow das erzeugen der detailierten landuses ein Kinderspiel (Tracer von Häuserumrissen auf Siedlung+Vegetation des Alkis-NRW-Atlas umgebogen). Hingegen das mittig anordnen der Waldwege echt mühsam, hier warte ich auch ein österreichisches(?) Plugin, dass vor mehreren Monaten angekündigt war. Nur weiß ich jetzt nicht mehr wie das heißen sollte bzw. auf welcher Seite dessen Fortschritt dokumentiert wurde. Jemand einen Tipp? (Das schnellste wäre, ein Knoten im Weg zu erzeugen, dann zwei Knoten des Landuses und der des Wegs markieren und Shift+b. Das Pulgin sollte das oder etwas sehr ähnliches automatisch können.)
Den fehlenden Fußweg hatte ich erst auf der gerenderten Karten entdeckt, aber noch nicht eingezeichnet.
Ich hatte mal in einem Ort angefangen, die residentials zu verbinden, aber das fand ich nicht schön (und war nebensächlich auch mehr arbeit).
http://www.openstreetmap.org/#map=19/51.06410/7.21347
Deswegen hatte ich die residentials danach getrennt gelassen.
ja klar, definitiv ein Problem, vor allem solche könnte/sollte Formulierungen. Zufriedener machen mich dann Formulierungen wie “es gibt diese Ansicht und diese Ansicht, beide sind derzeit akzeptiert” wenn das zutreffend ist. Das wichtig ist für mich nicht, dass es bei Themen wie diesem hier eine “Wahrheit X oder Y” gibt die im Wiki stehen muss. Denn offensichtlich gibt es da verschiedene Ansichten. Es sollte aber eine Wahrheit des Diskussionsstandes genau festgehalten sein. Egal ob aus irgendwelchen Gründen eine Seite “mehr recht” haben sollte, gibt es dann etwas nach dem sich alle Betroffenen richten können.
Hieße in diesem Fall: MapsMe könnte man darauf verweisen dass es diese Fälle laut Wiki gibt und sie ihr Rendering daran anpassen müssen. Wenn nichts dazu drin steht, werden sie mit Sicherheit sagen “falsch getaggt, nich unser Problem”. Habs mal als issue eingereicht, mal sehen.
Dann ist es eine bestimmte Information. Wenn aber überhaupt nicht geprüft wird, ob es unterschiedliche Eigenschaften gibt und einfach aufgrund der Darstellung in der Datenbank und nicht aufgrund der damit repräsentierten Information etwas gezeichnet wird, dann finde ich das falsch.
Jede Datenbank enthält mehr Daten, als mit ihr dargestellt werden sollen. Diese Daten sollten von Renderern nicht benutzt werden. Wenn ein Renderer darauf reagiert, dass die ID eine Primzahl ist oder dass das “to” einer Abbiegerelation vor dem “from” steht, dann ist das falsch.
Das ist jetzt ziemlich fundamentalistisch … hat aber auch praktische Auswirkungen:
Wenn man in Skandinavien Riesen-Wald-MPs aufteilt, dann hat man es sehr oft mit “inner”-Teilen zu tun, die nur über Stichstraßen angebunden sind. Da ist es sinnvoll, zur Auftrennung gerade Linien zwischen benachbarten “inner” zu ziehen, die dadurch ja in den neuen MPs nicht mehr auftauchen. Aber dann pappt irgendein Renderer da Linien mitten in die Wälder ohne dass die dargestellten Daten dafür irgendeine Begründung liefern würden.
Ich habe inzwischen begriffen, dass du es falsch findest. Ich habe aber auch schon Beispiele dafür genannt, wo es richtig sein kann (aneinandergrenzende Äcker, gleich getaggt, aber die Grenze ist eine Geoinformation, deren Kartendarstellung für den Anwender absolut sinnvoll ist).
Und wer entscheidet, welche Daten „diese“ sind? Wer zieht die Grenze zwischen darstellungswürdigen und nicht darstellungswürdigen Daten? Der Maintainer des Renderers, der sich an seinen Anwendern orientiert. Da kann man keine Festlegungen für Daten treffen, die auf keinen Fall dargestellt werden.
Du verstehst, worum es mir geht? Man kann durch das Aufteilen gleicher Flächen sinnvolle Information abbilden. Zum Beispiel die ansonsten nicht darstellbaren, aber on the ground klar sichtbaren Abgrenzungen zwischen Ackerflächen. Deshalb akzeptiere ich deine Aussage nicht, die rendertechnische Darstellung dieser Aufteilung sei falsch. Sie mag von dir unerwünscht sein, weil du Flächenaufteilung gern auch dort nutzt, wo sie keine Information transportiert, sondern nur der Bequemlichkeit des Mappers dient. Aber dadurch wird sie nicht „falsch“. Warum wohl wird empfohlen, Wälder nicht einfach „mitten durch“ zu teilen, sondern zum Beispiel entlang von Wegen?
Es sollte einigermaßen klar sein, dass dies überhaupt nichts mit dem von mir Dargestellten zu tun hat. Mir geht es darum, dass man Informationen, die relevant sein können, nicht einfach mit der Begründung weglassen (oder gar ihre Darstellung pauschal als „falsch“ bezeichnen) kann, dass sie es nicht immer auch tatsächlich sind.
–ks
Wir haben aber nur die Wahl zwischen “Sie sind immer relevant” und “Sie sind nie relevant”.
Das liegt daran, dass eine Eigenschaft der Datenbank gerendert wird statt einer Eigenschaft der Daten (Tags etc.). Es gibt auf die Frage “Warum ist da eine Trennlinie?” keine Antwort auf Ebene der Daten “Weil der Acker rechts und der links sich soundso unterscheiden”. Es gibt nur eine Antwort auf Ebene der Implementation “Weil da zwei Datensätze sind”.
Ich halte es nicht für einen Fehler, wenn die Renderer sich nach den Vorstellungen von Mappern richten und ich mappe wie gesagt solche künstlichen Trennungen künftig auch nicht mehr. Ich halte es aber für einen Fehler, wenn OSM so mit Datenstrukturen umgeht. Der direkte Durchgriff von der Applikation auf die Implementation wird sich auf die Dauer immer rächen.
Genau. Zwei Datensätze. Nicht einer, sondern zwei. Wieso soll man das nicht im Rendering erkennen dürfen, dass das zwei Datensätze sind anstelle eines einzigen? Wieso wäre das ein Fehler?
Noch ein Beispiel: Doppelhäuser mappen wir auch als zusammengewachsene buildings. Datentechnisch exakt derselbe Fall, und gleiches Tagging (solange keine unterschiedlichen Adressen dran sind). Würdest du es auch hier die Haarlinie zwischen den Häusern als Rendererfehler betrachten? Wenn nein, wieso dann bei aneinandergrenzenden Äckern? Oder Wäldern?
Ich sehe eher den Fall, den du als Standard anzunehmen scheinst, als Sonderfall: Dass die Trennung überhaupt nichts Reales abbildet, sondern nur zwecks Übersichtlichkeit der Datenebene vorgenommen wurde. Für den Fall könnte man sich einen Relationstyp überlegen, der dem Renderer sagt: „Ja, hier sind zwei Datensätze, aber tu bitte so, als sei es nur einer“.
–ks
Ich finde: Mühe und Aufwand wären besser (im Sinne von: Der Kartennutzer hat mehr davon) aufgewendet worden für eine weniger schlampige Abgrenzung des Waldes nach außen, also an Nicht-Wald-Flächen, als die (offenbar völlig willkürliche) Aufteilung von Waldgebieten durch normale Waldwege.
Was die Frage des Mappens von Wohngebieten angeht, hilft vielleicht ein Blick in die Welt realer Kartenzeichner. Auch da gibt es für Wohn-, Garten- und Gewerbegebiete unterschiedliche Symbolik. Natürlich mappt man ein Dorf, in dem bisher weder Häuser noch Straßen genau eingezeichnet sind, erstmal “flächig” mit landuse=residential. Das Feinmapping (Häuser, Wohn- und Gewerbegebiete, Gartenflächen, Friedhöfe, Parks, größere Grasflächen, Industrie…) kommt dann peu à peu… diese in den unterschiedlichen Zoomleveln darzustellen, ist eine Forderung an den Renderer (technisch: Verdrängung), nicht Mapper. Das gilt auch dann, wenn in OSM-Musterhausen mal jedes Carport und jede TG-Einfahrt eingetragen sein wird.
Du hast:
überlesen.
Entweder verstehe ich das Beispiel nicht oder: jein.
Nein, habe ich nicht. Ich habe begründet, warum ich es nicht sinnvoll finde.
Mir geht es doch lediglich um folgenden Punkt:
Wenn zwei gleichartige (also gleich getaggte) Datensätze aneinandergrenzen, statt einen einzigen zu bilden, kann das vom Mapper bewusst als Information so gemacht worden sein (Beispiele dafür habe ich ausreichend geliefert – Gebäude, Äcker, Forststücke). Dann ist es sinnvoll, wenn der Renderer die Abgrenzung zwischen den zwei Datensätzen auch als solche darstellt. Wer nun große Flächen durch willkürliche Linien aufteilt, muss deshalb damit rechnen, dass ein Renderer einen Sinn hinter dem Verlauf der Aufteilung vermutet und diesen Verlauf in der Karte darstellt. Deshalb wird ja auch allgemein dazu geraten, große Flächen nicht „mittendurch“, sondern entlang von Wegen zu teilen, wo eine eventuell gerenderte Trennlinie nicht auffällt. Dieses Verhalten kann man dem Renderer aber nicht als Fehler ankreiden – und wenn doch, dann ist die Darstellung aneinandergeklebter Doppelhäuser auch ein Fehler, wenn sie nicht wie ein einziges aussehen.
Wir haben noch keine Struktur, aus der der Renderer erkennen kann, ob die zwei Flächen separat oder als eine gemeinsame gerendert werden sollen, und bis wir die haben, finde ich es sinnvoll, solche Trennlinien darzustellen. Weil sie, wie gesagt, einen Sinn haben können und der Renderer nicht entscheiden kann, ob im konkret vorliegenden Fall ein Sinn vorliegt oder nicht.
–ks
Ich kann nicht nachvollziehen, wieso es ein Problem sein sollte, wenn Doppelhäuser mit einer Trennlinie angezeigt werden. Mir erschließt sich auch nicht, wieso es sinnvoll und richtig sein sollte, in Wäldern zwei “inner”-Flächen mit einer willkürlichen Linie zu verbinden. Natürlich gibt es das immer wieder, dass man zwei Waldstücke an einer willkürlichen Stelle aneinandergrenzen lässt. Doch sollte meiner Meinung nach Ziel sein, diese Stellen Stück für Stück so zu ändern, dass Trennlinien nur an tatsächlichen Trennlinien “on the ground” verbleiben, z.B. an Bestandsgrenzen oder Wegen oder an nicht sichtbaren aber klar definierten administrativen Grenzen (Grenzen, Forstbezirke, etc.). Dies bedeutet nicht, dass ein Wald an jeder Bestandsgrenze zwingend geteilt werden muss, auch klassische Papier-Topo-Karten zeigen nicht jede Bestandsgrenze. Ich korrigierte bereits bei Ackerflächen willkürlich gezogene Trennlinien, da ich weiß, dass diese als Linie in der Standardkarte angezeigt werden. Ich achte auch bei Wiesen/Weiden darauf, dass solche Linien auch einen Realitätsbezug haben, obwohl sie in der Standardkarte nicht angezeigt werden. Bei Wäldern habe ich bislang darauf nicht geachtet, habe mir aber vorgenommen, das zukünftig zu tun.
Niemand hat behauptet, dass das ein Problem ist. Im Gegenteil, es ist genau richtig. Das ist mein Argument dafür, wieso es kein Fehler des Renderers sein kann, ebenso auch eine willkürliche Trennlinie im Wald als Linie darzustellen. Woher soll er wissen, dass diese Linie – im Gegensatz zu der bei Doppelhäusern – keine inhaltliche Bedeutung hat und nur der Bequemlichkeit dient? Und separat gemappte Waldflächen können ja, ebenso wie separat gemappte Häuser, eine Bedeutung haben (z.B. einzelne Forststücke).
–ks
Ich halte das als **Zielsetzung **auch für richtig. Bezweifle aber die Umsetzbarkeit in stark zergliederten Regionen weil man sonst nur noch landuses mappen kann, besonders wenn man dann noch Multipolygone vermeiden will. Ich halte eine ängstliche Vermeidung von MP’s mittlerweile wieder für falsch. Habe damals gegen sie Stellung bezogen, um kilometergroße Ackerflächen-MP’s (farmland) zu vermeiden, in denen gleich mehrere Dörfer als “inner”-Flächen eingeschlossen waren, mit denen uns einige “Landschaftsmaler” beglückt haben.
Ich kann nicht erkennen, das jemand ernsthaft gefordert hätte Carports, oder Grundstücks-Zu- und Abfahrten aus residential-Flächen auszuschneiden.
Bei Freiflächen gilt ganz einfach: Alles hinter dem Gartenzaun gehört dazu.
Der private Gemüsegarten beim Haus → Ja
Die Streuobstwiese am Ortsrand → Nein
Interessant, dass Du nur Straßen “die durch das Wohngebiet hindurchführen” dem Wohngebiet zuschlagen möchtest, diejenigen, die es (nur) tangieren demnach nicht - dort darf das Wohngebiet also durchaus am Straßen- bzw. Gehwegrand enden, ohne das Schlimmes zu befürchten wäre.
Um beim Thema zu bleiben: habe kürzlich Wald geteilt, bzw. eine Ecke abgeschnitten:
http://www.openstreetmap.org/#map=19/51.39768/9.37894
Anlass war der Wunsch die tree_row südlich des track darzustellen.
Im Westen verläuft der track - wie ein path - durch den scheinbar ungestörten Wald.
Tatsächlich zerschneidet der Fahrweg den Forst, die neue Darstellung im Osten ist realitätsnäher, bzw. genauer.
Gewählt habe ich die Methode “C”, dies bedeutet die Fläche zwischen den Waldflächen wird mit grass gefüllt, um dem verbreiteten horror vacui (vgl. http://de.wikipedia.org/wiki/Horror_vacui_(Kunst) ) entgegenzuwirken.
Auf dieser Quasi-Grundierung entfaltet sich dann der expandierende highway.
Noch genauer wäre die Methode “B” - Auch die grass-Fläche wird zweigeteilt, ihre jeweiligen inneren Kanten sind die äußeren Kanten des Schotterbelages des tracks.
Die Methode “C” finde ich optimal.
Da geht ein Weg / Straße über eine “Gras-Fläche”, die von der Straßenmeisterei / Forstbetrieb ja auch bearbeitet wird. Nördlich an der Straße würde ich aber den “Radweg” mit ins “Straßenbegleitgrün” einbeziehen, da diese bestimmt auch von der Gemeinde bearbeitet wird.
Die Methode “C” ist so ähnlich, wie mit den einzelnen Grundstücksgrenzen im anderen Thema.