Schatten Ringe als Anker beim Zeichnen großer OSM-Polygon Strukturen.

Tut mir leid, so ganz habe ich das noch nicht verstanden. Welches Problem soll gelöst werden und wie genau gehst du vor? Hoffentlich lädst du die Kreise nicht in die Datenbank hoch. 😉

SammysHP wrote:

Tut mir leid, so ganz habe ich das noch nicht verstanden. Welches Problem soll gelöst werden und wie genau gehst du vor? Hoffentlich lädst du die Kreise nicht in die Datenbank hoch. 😉

Ach ja natürlich, dieses Problem: http://forum.openstreetmap.org/viewtopic.php?id=52639

SammysHP wrote:

Tut mir leid, so ganz habe ich das noch nicht verstanden. Welches Problem soll gelöst werden und wie genau gehst du vor? Hoffentlich lädst du die Kreise nicht in die Datenbank hoch. 😉

Hat er mit einem beschönigenden Kommntar doch. Ich bin über den einen Fall durch eine OSMI-Fehlermeldung gestolpert. Ich hab das zuerst für einen schlechten Witz gehalten und das Ganze entsprechend den Best-Practice-Empfehlungen zurückgebaut. Das hat ihm offensichtlich aber gar nicht gefallen und hat es prompt reverted, wobei er sich sich im Cangeset-Kommentar sich auf die fehlende Diskussion bezieht ( - wo war übrigends die Diskussion vor diesen eigenwilligen Edits?).

Ich hole diese Diskussion nach, indem ich hier mal geocodecs Version meiner korrigierten Version gegenüber stelle und für sich selbst sprechen lasse:

geocodec

41 MP-Relationen, davon 26 für landuse=forest
140 ways, alle Mitglieder von Relationen
3673 nodes

meine Version

2 MP-Relationen, davon 1 für landuse=forest
59 ways, davon 50 Mitglieder von Relationen. Und - oh Wunder - das Ganze funktioniert einwandfrei mit lauter vollständigen topologisch geschlossenen Ringen.
3673 nodes - Selbst auf dem einzigen Gebiet, wo zusammengestückelte MP mit geringeren Speicherbedarf punkten könnten, ein klarer Vorteil für geschlossene Ringe.

Ich habe mehrere Thread von geocodec hier und in AT verfolgt, kann aber nicht das eigentliche "Problem" erkennen.

Selbst in den Beispielen sehe ich keine falschen Renderungen. Und aus diesem Grung nicht die Notwendigkeit, grossflächige MP krampfhaft und "auf Teufel komm raus" mit diesen abenteuerlichen Konstrukten vereinfachen zu wollen.

Klar, Aufsplitten an Strassen, Flüssen und zur Not auch an willkürlichen Linien "quer durch den Wald" ist ok - aber diese Kornkreise????

@geocodec: belege doch mal "Das Problem" mit klaren und erkennbaren Screenshots und nicht mit Links auf MP, die angebliche Probleme zeigen - ich sehe da nix!

gruss
wambacher

Dh. die Kreise waren in den OSM Daten drin? Das geht natürlich nicht.

Wenn aufsplitten, dann an natürlichen Grenzen wie Straßen etc.

wambacher wrote:

Klar, Aufsplitten an Strassen, Flüssen und zur Not auch an willkürlichen Linien "quer durch den Wald" ist ok - aber diese Kornkreise????

Das Gute an den Kornkreisen so wie ich es verstehe (aber das steht nirgendwo, sondern ich rate das) wäre, dass man sofort erkennt, wenn irgendwo eins der MP kaputt ist, weil man so eine Kreislinie dann in der Renderung sieht. Dadurch dass man einen Kreisbogen sieht, sieht man, wo etwas kaputt ist.

Wird ein (Multi)polygon zu unhandlich, ziehe ich notfalls auch einfach in der Mitte eine Linie und teile es dort.

Die Sache mit den Kreisen habe ich leider immer noch nicht verstanden. 🙁

gormo wrote:

Das Gute an den Kornkreisen so wie ich es verstehe (aber das steht nirgendwo, sondern ich rate das) wäre, dass man sofort erkennt, wenn irgendwo eins der MP kaputt ist, weil man so eine Kreislinie dann in der Renderung sieht. Dadurch dass man einen Kreisbogen sieht, sieht man, wo etwas kaputt ist.

Ich hab mal die Relation 6003616 und dann auch noch die Relation 6003614 kaputtgemacht. Das würde z.B. passieren, wenn ich deren gemeinsamen Weg 399669298 lösche:

Man siehts schon, aber obs das rechtfertigt...

Den anderen im österreichischen Forum genannten Grund (Probleme beim Rendern unförmiger MPs in manchen Zoomstufen, weswegen eine Kreisform erstrebenswert ist) kann ich nicht nachvollziehen: In der üblichen Verarbeitungskette osm2pgsql -> postgis -> mapnik ist osm2pgsql die letzte Instanz, die weiss, dass eine Fläche mal ein MP war und mapnik ist die erste Instanz, die weiss, was eine Zoomstufe ist. Es gibt Probleme beim Markieren alter Kacheln bei grossen Flächen. Man will ja nicht eine ganze Grenze neue malen, blos weil einer einen Grenzstein verschoben hat. Dieses Problem kann man aber mit Geduld lösen und hängt auch nicht von der Form ab.

Grüße, Max

Ich hätte ehrlich maximal einen Kreis erwartet, aber zich verschiedene überlappende?!? Könnten von mir aus ja auch Vierecke sein.

Die Grundidee ist ja nicht schlecht, aber geocodecs Alleingänge (Ich mach dann mal ...) und Umgangston (hat OSM wissenschaftliche Mitarbeiter ???) finde ich nicht wirklich förderlich. Deshalb halte ich mich bei dem Thema am liebsten (und abgesehen von diesem Post) komplett raus.

Bei allen Renderern, die den Rand von Flächen zusätzlich malen, wären die Kreise übrigens sichtbar. Beim osm-Mapnik-Stil beträfe das zur Zeit unter anderem farmland, commercial, retail, industrial, residential, building. Da hätte man die Kreise auch im Kartenbild. "In der fertigen OSM Karte sind diese natürlich unsichtbar" gilt also nur für manche Flächenarten in manchen Kartenstilen.

Diese Ränder sind natürlich auch dann sichtbar, wenn die Flächen anders geteilt werden. Nur sind sie weniger auffällig, oder haben sogar Sinn, wenn sie irgendwelchen Wegen, Schneisen, Bächen... folgen.

Danke fürs Ausprobieren, maxbe!

Ich glaube nicht, das es die Verwirrung rechtfertigt, die es stiftet.

So langsam verstehe ich es. Und bin der Meinung, dass es nicht der richtige Weg für die Qualitätssicherung ist. In der Datenbank hat es jedenfalls nichts zu suchen.

Ich schließe mich der Meinung an. Es wurde eigentlich alles bereits gesagt. Die Kreise sind nicht sinnvoll in den Daten.
Die Qualitätssicherung für multipolygone erfolgt nicht über das Betrachten des Rendering sondern über Qualitätssicherungstools wie z.B. OSMI, JOSM Validator oder viele andere. Außerdem gilt nicht in jedem Fall: "In der fertigen OSM Karte sind diese natürlich unsichtbar".
Wenn große MPs getrennt werden müssen/sollen, dann an natürlichen Grenzen (Straßen, Flüsse,...).

geocodec wrote:

In der fertigen OSM Karte sind diese natürlich unsichtbar.

Das Argument ist keins. Das gilt nämlich nur, wenn der Kartenstil keinen Flächenrand zeichnet. Tut er das, sieht man es. Will da einer bloß für den Renderer mappen?

Klumbumbus wrote:

Wenn große MPs getrennt werden müssen/sollen, dann an natürlichen Grenzen (Straßen, Flüsse,...).

Dem stimmen, glaube ich, viele zu, ich z.B.

@geocodec: Zu einem Editwar gehören immer zwei!

Klumbumbus wrote:

Wenn große MPs getrennt werden müssen/sollen, dann an natürlichen Grenzen (Straßen, Flüsse,...).

Hier wünsche ich mir in Josm ja noch eine Funktion, mit der ich eine Linie, z.B. entlang einer Straße ziehen kann, die dann das Polygon teilt...

Das würde das Zerteilen von Flächen um einiges einfacher machen...

Ansonsten halte ich von den Kreisen überhaupt nix.

Sven

streckenkundler wrote:

Hier wünsche ich mir in Josm ja noch eine Funktion, mit der ich eine Linie, z.B. entlang einer Straße ziehen kann, die dann das Polygon teilt...

ContourMerge + Utils2 = Linie zeichnen, mit ContourMerge den Straßenverlauf annehmen lassen, wieder trennen (wir wollen ja keine Flächen mit Wegen verbinden) und an dieser Linie das Multipolygon trennen (wobei ich mir nicht sicher bin, ob das auch für Multipolygone geht oder nur für normale Polygone).

...oder mittel parallele kopie (Shift+P) eine kopie der Straße an den straßenrand ziehen, die tags entfernen und diese linie dannn für das (multi-)polygon verwenden.

@SammysHP und @Klumbumbus

Ich glaub, mein Anliegen ist hier etwas OT... Das geht schon in die Richtung, ist mit aber noch etwas zu aufwendig... Ich schreib mal extra was zusammen...
Sven

OT: Ich glaube, wir geben es mit Geocodec auf. Wenn er in Österreich rumwüten will, von mir aus - ich kann da urlaubsmäßig einen Bogen drum machen. Wenn sich die österreichische Community von ihm auf der Nase rumtanzen lässt, können wir es ihr nicht verbieten.

Klar können wir das. OSM ist international und es ist völlig egal, woher die Nutzer kommen und wo sie etwas machen.

Das Problemchen das ich zu lösen versuche, sind eher solche Polygone:
https://www.openstreetmap.org/relation/ … 62/14.7231

Von mir aus sind meine "Ring Kreise" (Kornkrese möchte ich diese nicht nennen) eher, als Hilfsmittel zum Auflösen von Monster Polygonen gedacht. Nach Abschluss der Arbeiten kann man diese auch wieder entfernen. Deren Optimale Größe und Form müsste noch gefunden werden.

Interessant fände ich default Schatten Kreise in ungemappten Landschaften mit großen einheitlichen Flächen. Mit der Zeit würden sich diese sich auflösen, und schließlich in Micromapping Strukturen völlig verschwinden.

edit: typo

Klumbumbus wrote:

...oder mittel parallele kopie (Shift+P) eine kopie der Straße an den straßenrand ziehen, die tags entfernen und diese linie dannn für das (multi-)polygon verwenden.

genauso mache ich das, führt das Polygon aber durch einen Ort hat man eine zusätzliche Linie am Gehsteig. https://www.openstreetmap.org/relation/ … 3/-1.99260 Das Risiko dass ein solche Polygon bricht ist sehr groß. Handelt es sich um ein Monsterpolygon verschwinden gleich ganze Landschaften.
Meiner Meinung nach sollte man Polygone sofern es sich bei diesen um Flächenmerkmale handelt, möglichst klein halten.

Bei Umrisspolygonen wie bei einem Nationalpark geht das natürlich nicht. Hier hilft das freistellen des Polygons in eine separate Linie insofern, als dadurch die Struktur stabiler wird und nicht so leicht kleine Lücken entstehen.

geocodec wrote:

Das Problemchen das ich zu lösen versuche, sind eher solche Polygone:
https://www.openstreetmap.org/relation/ … 62/14.7231

Wo ist da das Problem? Wenn es zu groß sein sollte, dann kann es doch z.B. an L91, L92 und L113 getrennt werden.

geocodec wrote:

Interessant fände ich default Schatten Kreise in ungemappten Landschaften mit großen einheitlichen Flächen. Mit der Zeit würden diese Ringe dann natürlich weniger und weniger.

Was sollen irgendwelche Kreis in ungemappten Gebieten?

Klumbumbus wrote:

geocodec wrote:

Das Problemchen das ich zu lösen versuche, sind eher solche Polygone:
https://www.openstreetmap.org/relation/ … 62/14.7231

Wo ist da das Problem? Wenn es zu groß sein sollte, dann kann es doch z.B. an L91, L92 und L113 getrennt werden.

Wenn das so einfach ist Bitte nur zu,
aber dann erwarte ich mir auch von Ihnen dass Sie mir in der Bereinigung und Verfeinerung der in diesem Bereich sehr grob gezeichneten Linienzüge bis hinunter auf die residental Gebäudeebene folgen.

Bitte schon mal ein Paar Tage Urlaub einplanen.

herzlichst geocodec

edit: +Verfeinerung

Nakaner wrote:

Das Argument ist keins. Das gilt nämlich nur, wenn der Kartenstil keinen Flächenrand zeichnet. Tut er das, sieht man es.

Klumbumbus wrote:

Wenn große MPs getrennt werden müssen/sollen, dann an natürlichen Grenzen (Straßen, Flüsse,...).

Egal wo man trennt, müssen wir definieren, dass kein Flächenrand existiert, wenn zwei gleichartige Flächen aufeinandertreffen. Es ist dann Aufgabe des Renderers, dafür zu sorgen, dass dort kein Flächenrand gezeichnet wird.

Wenn wir dies nicht so defininieren, dürfen wir nicht trennen, egal wie groß das Multipolygon dabei wird, sofern die Flächen nicht real getrennt sind. Straßen etc. als optionale Trennung müssten dann tabu sein. Wenn man die Straße als real trennend ansieht, wäre die Trennung ok, allerdings gilt dies dann unabhängig davon, ob das Multipolygon andernfalls zu groß würde.

Wenn zwei gleichartige Flächen per Definition keinen Flächenrand dort bilden, wo sie aufeinantertreffen, könnten wir auch z.B. entlang von Längen- und Breitengraden oder Tilegrenzen trennen. Praktikabel wäre dies aber wohl nur, wenn der Editor dies automatisch macht. Wenn man die Flächen über geeignete grafische Werkzeuge im Editor bearbeiten würde, könnte der Editor diese Trennung vor dem Benutzer auch weitgehend verbergen.

geocodec wrote:

Das Problemchen das ich zu lösen versuche, sind eher solche Polygone:
https://www.openstreetmap.org/relation/ … 62/14.7231

Wieder nur ein nichtssagender Link 🙁

Ich sehe ein MP für den Wald und erkenne, dass alle Inner sauber gerendert werden. (sauber = keine Bäume).

Dazu kommen viele Flächen, die leider als "Wiese mit Bäumen" dargestellt werden, was sicher nicht gewollt ist. Dies ist aber einzig und allein Folge der Tatsache, dass diese Wiesen keine Inner des umgebenden Waldes sind. Klar, gefallen tut mir das auch nicht, aber es ist technisch gesehen korrekt.

Also nochmals: Wo ist das Problem?

wambacher

ps: Ich meine inzwischen, dass sich das Problem zwischen Tastatur und Rückenlehne befindet.

wambacher wrote:

Dazu kommen viele Flächen, die leider als "Wiese mit Bäumen" dargestellt werden, was sicher nicht gewollt ist. Dies ist aber einzig und allein Folge der Tatsache, dass diese Wiesen keine Inner des umgebenden Waldes sind. Klar, gefallen tut mir das auch nicht, aber es ist technisch gesehen korrekt.
.

Ich sehe diese Ringe als Hilfsmittel und nicht als geplantes Endprodukt.
So ähnlich wie Autobauer die Karosserie eines Fahrzuges erst zum Schweißen in einen Rahmen spannen, dieses Werkzeug anschließend wieder entfernen.

Ring oder "Kornkreise" bringen das Zeichnen von OSM-Strukuren definitiv in eine menschliche Form. Dass solche Hilfsmittel anschließend entfernt gehören steht für mich außer Zweifel.

Vernünftig gemacht könnte man mit dieser Technik eine völlig neue Zeichnerschicht ansprechen, durch die kleinzellige Struktur mit nur geringem Risiko. Das täte dem OpenStreetMap Projekt sehr gut.

Dem OSM Projekt würde es gut tun, wenn solcher unnötiger Müll nicht in die Datenbank kommt. Wenn es dir bei der Arbeit hilft, kannst du es ja gerne offline nutzen, aber nicht hochladen. Deine künstlerische Begabung solltest du besser auf deviantart o.ä. ausleben.

Doofe Frage dazwischen: Was soll einklich „Schatten Kreise“ heißen? Was ist daran Schatten?

--ks

kreuzschnabel wrote:

Doofe Frage dazwischen: Was soll einklich „Schatten Kreise“ heißen? Was ist daran Schatten?

--ks

"Schatten", da solche Linien zwar jeweils als noch zu klärende Struktur, in große zuammenhängende OSM Flächen importiert würden, aber im Grundzustand kein Merkmale als vielleicht ein Note aufweisen würden.
Daher verhalten sich diese Linien gerendert als unsichtbar, ich sage dazu Schatten.

Neulinge würden beim Bearbeiten von großen Flächen auf solche Grund-Strukturen treffen, und könnten an diese anschließend gut ihre ID Polygone anhaften. Das würde Neulingen beim Zeichnen sicher Halt geben.

Manche mögen dazu auch Malen nach Zahlen sagen. Ich finde wenn wir dadurch neue Zeichner gewinnen können welche sonst Mandalas ausmalen, Gut.

geocodec wrote:

... Daher verhalten sich diese Linien gerendert als unsichtbar, ich sage dazu Schatten. ...

Aber genau das trifft ja nicht zu. Je nachdem wie das übergeordnete Objekt gerendert wird, sind sie sehr wohl sichtbar. Aber das wurde ja bereits mehrfach ausgeführt.

Gruß Klaus

toc-rox wrote:

geocodec wrote:

... Daher verhalten sich diese Linien gerendert als unsichtbar, ich sage dazu Schatten. ...

Aber genau das trifft ja nicht zu. Je nachdem wie das übergeordnete Objekt gerendert wird, sind sie sehr wohl sichtbar. Aber das wurde ja bereits mehrfach ausgeführt.

Gruß Klaus

Dem kann ich nicht folgen. Kein Flächen Merkmal würde an einer solchen "Kornkreis oder Mandala Linie" enden.

Durchtrennt eine solche Hilfsline eine Wiese, so dockt an beiden Seiten der Linie -ordentlich gemappt- das Flächenmerkmal Wiese an.

Wenn die Ringe für Dich eh nur eine Krücke für die Zeit der Konsolidierung dieser großen Polygone sind (d.h. bis man sie klein gekriegt hat), dann habe ich da nicht so viel dagegen. Ich würde mir eben nicht die Mühe machen, da so einen Kreis zu zeichnen, sondern würde, wenn ich keine Zeit mehr habe oder keine Lust, eine grade Linie ziehen.

Solange diese Kreise nicht für dauerhafte Verwendung gedacht sind: mach doch was du willst ;-)

Kreise halte ich für die denkbar schlechteste Idee hier, da es diesen Datentyp in OSM überhaupt nicht gibt, und man daher angenäherte Kreise mit bis zu unendlich vielen Nodes erhält, und da die Kreise überhaupt nichts damit zu tun haben, was man vor Ort vorfindet. Würde ich sofort löschen, da klar Spam (entspricht nicht dem was dort ist). Ob man auf einem bestimmten Rendering was davon sieht oder nicht, spielt dabei keine Rolle, hängt im Einzelnen aber davon ab, wie die Renderregeln sind.

Grundsätzlich sollte man landuses und Flächen wie landcover m.E. an Straßen und Wegen aufsplitten, zumindest in der idealen "Endfassung" (temporär, aus Zeit- und Lust-mangel kann man natürlich auch erstmal gröber rangehen), weil die Straßen einen anderen landuse haben als die Flächen an deren Rand. Die Flächen sollten dort aufhören, wo sie aufhören, d.h. dass zwar auch wieder näherungsweise der Rand einer parallelen Straße ungefähr folgt, im Detail jedoch der Rand normalerweise vor und zurückspringt, ausgefranst ist, etc., also eine eigene Form hat, die nur grob der Straße folgt, aus diversen lokalen Gründen aber im Detail etwas anders verläuft.

Wenn man die Flächen klein genug wählt hat man die genannten Probleme weitgehend gar nicht mehr, und braucht auch keine Krücken bzw. Kreise.

geocodec wrote:

toc-rox wrote:

geocodec wrote:

... Daher verhalten sich diese Linien gerendert als unsichtbar, ich sage dazu Schatten. ...

Aber genau das trifft ja nicht zu. Je nachdem wie das übergeordnete Objekt gerendert wird, sind sie sehr wohl sichtbar. Aber das wurde ja bereits mehrfach ausgeführt.

Gruß Klaus

Dem kann ich nicht folgen. Kein Flächen Merkmal würde an einer solchen "Kornkreis oder Mandala Linie" enden.

Durchtrennt eine solche Hilfsline eine Wiese, so dockt an beiden Seiten der Linie -ordentlich gemappt- das Flächenmerkmal Wiese an.

Erstes Beispiel, nach 30 Sekunden Suche gefunden: http://www.openstreetmap.org/#map=18/52.07100/7.56153

Zwei Flächen mit landuse=farmland stoßen mit einer Haarlinie aneinander. Sind es zwei physische Äcker, ist das Rendering so absolut sinnvoll und gliedert die Karte viel besser als wenn dort nur ein durchgehendes Braun wäre. Ich würde es begrüßen, wenn alle aneinanderstoßenden landuse so gerendert würden, ohne daß man eine Trennlinie explizit einzeichnen muss. Denn aus dem Mapping ergibt sich ja, dass dort zwei unterschiedliche Flächen aneinandergrenzen.

Deine Schattenkreise ergäben da keinerlei Sinn.

Und die aus den Schattenkreisen folgende Forderung, gleichartige aneinanderstoßende Flächenelemente fugenlos zu rendern (eben damit man die Kreise im Rendering nicht sieht), nimmt uns auf der anderen Seite die Möglichkeit, einzelne Wiesen oder Äcker genau so aneinandergrenzend zu mappen und eine übersichtliche Karte daraus gerendert zu bekommen. Oder man müßte dem Renderer die Info mitgeben, ob die Außengrenze der Fläche physikalisch vorhanden oder nur logistisch erforderlich ist. Das verkompliziert wieder die Dateneinpflege, und die ist kompliziert genug.

--ks

Die Vorgehensweise als solches ist ja ganz interessant, aber sollte meiner Meinung nach ein proof of concept bleiben und nicht Einzug in die Datenbank erhalten.

geocodec wrote:

Neulinge würden beim Bearbeiten von großen Flächen auf solche Grund-Strukturen treffen, und könnten an diese anschließend gut ihre ID Polygone anhaften. Das würde Neulingen beim Zeichnen sicher Halt geben.

Neulinge sollten intuitiv mit den Daten arbeiten können, dazu gehört, dass sich Strukturen an der Realität orientieren. Diese großformatigen Kreise kommen in der realen Welt aber praktisch nicht vor. Die ersten Gedanken, die ich als Bearbeiter hätte:
Da hat jemand einen Teilchenbeschleuniger als Wald getagt oder versehentlich ein Silo "etwas" vergrößert. Kurz gesagt: Sie wirken unnatürlich und meine erste Assoziation ist: Da ist was falsch. Auf die Idee mich an diese Kreissegmente anzuheften käme ich nicht und hätte sie ohne diese Diskussion hier, beim Bearbeiten vermutlich entfernt.

Malen nach Zahlen funktioniert auch ohne Mandalas.

kreuzschnabel wrote:

Erstes Beispiel, nach 30 Sekunden Suche gefunden: http://www.openstreetmap.org/#map=18/52.07100/7.56153

Zwei Flächen mit landuse=farmland stoßen mit einer Haarlinie aneinander. Sind es zwei physische Äcker, ist das Rendering so absolut sinnvoll und gliedert die Karte viel besser als wenn dort nur ein durchgehendes Braun wäre. Ich würde es begrüßen, wenn alle aneinanderstoßenden landuse so gerendert würden, ohne daß man eine Trennlinie explizit einzeichnen muss. Denn aus dem Mapping ergibt sich ja, dass dort zwei unterschiedliche Flächen aneinandergrenzen.

Deine Schattenkreise ergäben da keinerlei Sinn.

Und die aus den Schattenkreisen folgende Forderung, gleichartige aneinanderstoßende Flächenelemente fugenlos zu rendern (eben damit man die Kreise im Rendering nicht sieht), nimmt uns auf der anderen Seite die Möglichkeit, einzelne Wiesen oder Äcker genau so aneinandergrenzend zu mappen und eine übersichtliche Karte daraus gerendert zu bekommen. Oder man müßte dem Renderer die Info mitgeben, ob die Außengrenze der Fläche physikalisch vorhanden oder nur logistisch erforderlich ist. Das verkompliziert wieder die Dateneinpflege, und die ist kompliziert genug.

--ks

OK, das ist tatsächlich nicht gut.
In meiner Arbeitsweise löse ich bereits meine Hilfslinien an Schnittstellen mit gleichem Flächenenmerkmal auf.
Die Idee vereinfachtes Zeichnen mittels Editor ID und einfacher Ring Polygone -angedockt an Hilfslinien-, kann ich so leider vergessen.

edit:typo
Schade

Ref: https://www.openstreetmap.org/relation/ … 59/14.6807

Der nächste Aspekt ist, daß ein Polygon, dessen Umriß auch in kleinen Segmenten schon so kreisförmig aussieht, daß die von dir geplante Warnfunktion („hier fehlt was“) erfüllt wird, in OSM kein kleiner Datensatz ist, da er nicht als Kreis (definierbar durch Mittelpunkt und Radius, 3 Zahlen), sondern als Polygon aus n Punkten gespeichert wird, und ein Acht- oder Sechzehneck erfüllt deine Forderung nach einer Außengrenze, der man auch bei kleinem Ausschnitt ihre Kreisnatur ansieht, noch nicht. Es werden also -zig Umfangspunkte benötigt und müssen abgelegt werden – für ein Element, das überhaupt nichts on the ground abbildet.

--ks

geocodec wrote:

Ring oder "Kornkreise" bringen das Zeichnen von OSM-Strukuren definitiv in eine menschliche Form.

geocodec wrote:

Das würde Neulingen beim Zeichnen sicher Halt geben.

Manche mögen dazu auch Malen nach Zahlen sagen. Ich finde wenn wir dadurch neue Zeichner gewinnen können welche sonst Mandalas ausmalen, Gut.

OSM ist weder ein Kunstwerk noch ein Spielfeld für spirituelle Wegfindung.

Ich habe vor einigen Tagen begonnen, das große Waldmultipolygon am rechten Ufer der Lavant von Bad St. Leonhart im Lavanttal bis Wolfsberg, zu zerkleinern, da es kaputt war und nur schlampig über einen ganzen Landstrich gezeichnet war.

Der Defekt war in meinem Fall, dass der äußere Ring nicht geschlossen war. Anstatt aber einfach das Loch wieder zu schließen, habe ich das MP dabei von Ost nach West zurückgedrängt. Ich bin gerade dabei von Ost nach West viele kleine Wälder zu zeichnen. Das Monster-MP wird dabei mit schlampig gezeichneten Verbindungslinien valide gehalten.

Ein Nebeneffekt ist ein weißer Fleck auf der Karte, aber vorher war der, als das Monster-MP invalide war, noch viel größer.

https://www.openstreetmap.org/relation/ … 81/14.8185

aktueller Stand:

EDIT: Bild ergänzt

geocodec wrote:

wambacher wrote:

Dazu kommen viele Flächen, die leider als "Wiese mit Bäumen" dargestellt werden, was sicher nicht gewollt ist. Dies ist aber einzig und allein Folge der Tatsache, dass diese Wiesen keine Inner des umgebenden Waldes sind. Klar, gefallen tut mir das auch nicht, aber es ist technisch gesehen korrekt.
.

Ich sehe diese Ringe als Hilfsmittel und nicht als geplantes Endprodukt.
So ähnlich wie Autobauer die Karosserie eines Fahrzuges erst zum Schweißen in einen Rahmen spannen, dieses Werkzeug anschließend wieder entfernen.

Ring oder "Kornkreise" bringen das Zeichnen von OSM-Strukuren definitiv in eine menschliche Form. Dass solche Hilfsmittel anschließend entfernt gehören steht für mich außer Zweifel.

Vernünftig gemacht könnte man mit dieser Technik eine völlig neue Zeichnerschicht ansprechen, durch die kleinzellige Struktur mit nur geringem Risiko. Das täte dem OpenStreetMap Projekt sehr gut.

Ist dir eigentlich klar, dass deine Antwort nichts, aber auch garnichts mit meinen Bemerkungen zu tun hat?

Nakaner wrote:

EDIT: Bild ergänzt

Https will wohl gerade nicht (unbekanntes Zertifikat):

wambacher wrote:

Nakaner wrote:

EDIT: Bild ergänzt

Https will wohl gerade nicht (unbekanntes Zertifikat):

Ich habe mein Zertifikat von Let's Encrypt signieren lassen.

wambacher wrote:

Https will wohl gerade nicht (unbekanntes Zertifikat):

Doch, hier gehts. 😉

Nakaner wrote:

Ich habe vor einigen Tagen begonnen, das große Waldmultipolygon am rechten Ufer der Lavant von Bad St. Leonhart im Lavanttal bis Wolfsberg, zu zerkleinern, da es kaputt war und nur schlampig über einen ganzen Landstrich gezeichnet war.

Der Defekt war in meinem Fall, dass der äußere Ring nicht geschlossen war. Anstatt aber einfach das Loch wieder zu schließen, habe ich das MP dabei von Ost nach West zurückgedrängt. Ich bin gerade dabei von Ost nach West viele kleine Wälder zu zeichnen. Das Monster-MP wird dabei mit schlampig gezeichneten Verbindungslinien valide gehalten.

Ein Nebeneffekt ist ein weißer Fleck auf der Karte, aber vorher war der, als das Monster-MP invalide war, noch viel größer.

Es mit dieser Methode zu versuchen zeigt, Du hast den Mut eines Löwen. Zugleich zeigt das wie unzulänglich die Polygon Methode (also das Zeichnen mit überwiegend geschlossenen Ringen) bei komplexen Flächen ist.

Respekt über Deine Arbeit.

kreuzschnabel wrote:

Erstes Beispiel, nach 30 Sekunden Suche gefunden: http://www.openstreetmap.org/#map=18/52.07100/7.56153

Zwei Flächen mit landuse=farmland stoßen mit einer Haarlinie aneinander. Sind es zwei physische Äcker, ist das Rendering so absolut sinnvoll und gliedert die Karte viel besser als wenn dort nur ein durchgehendes Braun wäre. Ich würde es begrüßen, wenn alle aneinanderstoßenden landuse so gerendert würden, ohne daß man eine Trennlinie explizit einzeichnen muss. Denn aus dem Mapping ergibt sich ja, dass dort zwei unterschiedliche Flächen aneinandergrenzen.

Deine Schattenkreise ergäben da keinerlei Sinn.

Und die aus den Schattenkreisen folgende Forderung, gleichartige aneinanderstoßende Flächenelemente fugenlos zu rendern (eben damit man die Kreise im Rendering nicht sieht), nimmt uns auf der anderen Seite die Möglichkeit, einzelne Wiesen oder Äcker genau so aneinandergrenzend zu mappen und eine übersichtliche Karte daraus gerendert zu bekommen. Oder man müßte dem Renderer die Info mitgeben, ob die Außengrenze der Fläche physikalisch vorhanden oder nur logistisch erforderlich ist. Das verkompliziert wieder die Dateneinpflege, und die ist kompliziert genug.

--ks

OK, das ist tatsächlich nicht gut.
Die Idee vereinfachtes Zeichnen mittels Editor ID und einfachen Ring Polygonen -angedockt an Hilfslinien-, kann ich so leider vergessen.
Es entstehen bei überlagerten Polygonen dünne Linien in der Landschaft. http://www.openstreetmap.org/#map=18/52.07100/7.56153

Lösung:
Erstaunlicherweise erzeigt meine Arbeitsweise https://www.openstreetmap.org/relation/ … 5/14.62815 also Mappen mit reinen Multipolygonen dieses Fehlerbild (feine Streifen in der Landschaft) nicht. Anschlüsse gelingen unter Verwendung von reinen Multipolygonen sauber.

Fazit meine Schattenkreise nur in Verbindung mit reinen Multipolygonen.

und so schaut das Endprodukt aus:
https://www.openstreetmap.org/#map=14/46.7278/14.6397

edit: +gif

geocodec wrote:

Erstaunlicherweise erzeigt meine Arbeitsweise https://www.openstreetmap.org/relation/ … 5/14.62815 also Mappen mit reinen Multipolygonen dieses Fehlerbild (feine Streifen in der Landschaft) nicht. Anschlüsse gelingen unter Verwendung von reinen Multipolygonen sauber.

Nein, das liegt daran, dass bei landuse=meadow (im Gegensatz zu z.B. landuse=farmland) im Standardstil generell keine Umrisse gezeichnet werden, egal ob einfaches Polygon oder Multipolygon. Das ist auch kein Fehlerbild sondern so gewollt. Aber eigentlich ist das alles vollkommen egal, denn wir mappen nicht für den Renderer und in anderen Kartenstilen kann die Anzeige schon wieder komplett anders sein.

Wenn dir die Kreise beim editieren helfen, kannst du sie gerne (temporär) verwenden, aber bitte nicht in die Datenbank hochladen.

geocodec wrote:

Lösung:
Erstaunlicherweise erzeigt meine Arbeitsweise https://www.openstreetmap.org/relation/ … 5/14.62815 also Mappen mit reinen Multipolygonen dieses Fehlerbild (feine Streifen in der Landschaft) nicht. Anschlüsse gelingen unter Verwendung von reinen Multipolygonen sauber.

Fazit meine Schattenkreise nur in Verbindung mit reinen Multipolygonen.

Da hast du leider das falsche Fazit gezogen. Das was du als "Fehlerbild" bezeichnet, ist nicht auf den Unterschied von Polygonen und Multipolygonen zurückzuführen. Der verwendete Style zeichnet die Außenlinien von farmland etwas dunkler als die Füllung. Bei meadow unterscheiden sich Außenlinie und Innenfläche farblich nicht voneinander. Deswegen gibt es in deinem Beispiel auch nicht die Probleme mit der Darstellung. Würdest du deine Methode auf farmland anwenden, würden deine Schattenkreise sehr in der Karte sichtbar werden - egal ob Polygon oder Multipolygon.

Bevor du auf den Gedanken kommst "Ok, dann verwende ich die Schattenkreise halt nur für Wälder": Bedenke bitte, dass die Karte auf openstreetmap.org nicht das Maß aller Dinge ist. Beispielsweise verwendet die opentopomap für Wälder eine leicht unterschiedliche Darstellung für Außenkontur und Fläche.

Zwei kleine Anmerkungen zu diesem Thread von mir:

1. Ich werde jetzt nicht so weit gehen, nach solchen Hilfskreisen zu suchen, aber wenn ich beim Mappen welche entdecke, dann werde ich die selbstverständlich löschen, denn Hilfsmittel gehören nicht in unsere Datenbank. (Ebensowenig wie unsere geschätzten "Bing Hires Imagery"-Polygone, so nützlich die sein mögen.)

Und 2.

slhh wrote:

Wenn wir dies nicht so defininieren, dürfen wir nicht trennen, egal wie groß das Multipolygon dabei wird, sofern die Flächen nicht real getrennt sind. Straßen etc. als optionale Trennung müssten dann tabu sein.

OSM ist ja keine extakte Wissenschaft; nur weil irgendwo mal was nicht ganz sauber ist, löst sich nicht gleich das ganze Projekt in einem Logikwölkchen auf. Wir dürfen mit dem Daumen im Wind arbeiten, und wir dürfen mit großen Polygonen anders verfahren als mit kleinen. Wir dürfen pragmatisch sein - das ist, was uns stark macht.

Bye
Frederik

zerda wrote:

Beispielsweise verwendet die opentopomap für Wälder eine leicht unterschiedliche Darstellung für Außenkontur und Fläche.

Och, bis die mal wieder neu gerendert wird :-)

--ks

nop.

geocodec wrote:

Die Angelegenheit ist komplexer als gedacht.
Ich verwende diese Kreise künftig nun ausschließlich als Hilfsmittel zum Verkleinern von großen Polygonen. Im finalen Kartenprodukt haben diese nichts verloren. Dort wo ich dringend einen Teiler benötige, werde ich das eine oder andere Fragment belassen.

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Übriges: Es heißt OpenStreetMap, nicht Openstreetmap, und es handelt sich um einen Geodatenbank und kein "Kartenprodukt".

Nakaner wrote:

geocodec wrote:

Die Angelegenheit ist komplexer als gedacht.
Ich verwende diese Kreise künftig nun ausschließlich als Hilfsmittel zum Verkleinern von großen Polygonen. Im finalen Kartenprodukt haben diese nichts verloren. Dort wo ich dringend einen Teiler benötige, werde ich das eine oder andere Fragment belassen.

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Übriges: Es heißt OpenStreetMap, nicht Openstreetmap, und es handelt sich um einen Geodatenbank und kein "Kartenprodukt".

Immer hübsch nachsetzen.
Das ist schade.

geocodec wrote:

Nakaner wrote:

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Übriges: Es heißt OpenStreetMap, nicht Openstreetmap, und es handelt sich um einen Geodatenbank und kein "Kartenprodukt".

Immer hübsch nachsetzen.
Das ist schade.

Wäre es dir möglich, auf das Sachargument „Deine Kringel haben nämlich viel zu viele Nodes“ noch kurz einzugehen, bevor ihr euch nur noch Torten ins Gesicht werft?

--ks

kreuzschnabel wrote:

geocodec wrote:

Nakaner wrote:

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Übriges: Es heißt OpenStreetMap, nicht Openstreetmap, und es handelt sich um einen Geodatenbank und kein "Kartenprodukt".

Immer hübsch nachsetzen.
Das ist schade.

Wäre es dir möglich, auf das Sachargument „Deine Kringel haben nämlich viel zu viele Nodes“ noch kurz einzugehen, bevor ihr euch nur noch Torten ins Gesicht werft?

--ks

Keine Ahnung was mit "zu vielen Nodes" gemeint ist.
Ich habe die Zahl so gewählt dass die Linie in der maximalen Zoom Stufe gerade nicht in Ecken zerfällt.

Übrigens inzwischen finde ich, solche Hilfs- Ringe, sollten sich nicht mehrfach überschneiden.

Und natürlich sollten diese Ringe abschließend wieder restlos aus der OSM-Datenbank verschwinden.
edit: +gif

@geocodec: Nimm doch mal einen "Acker" und wende dort deine Kreise an. Anschließend bitte auf die gerenderte OSM-Karte schauen. Vielleicht wird dir dann so manches klar ...

Gruß Klaus

toc-rox wrote:

@geocodec: Nimm doch mal einen "Acker" und wende dort deine Kreise an. Anschließend bitte auf die gerenderte OSM-Karte schauen. Vielleicht wird dir dann so manches klar ...

Gruß Klaus

Ganz habe ich den Sinn von Teiler beim Flächenmerkmal "Acker" nicht verstanden. Für Hecken und Mauern gibt es den TAG barrier.

geocodec wrote:

Ich habe die Zahl so gewählt dass die Linie in der maximalen Zoom Stufe gerade nicht in Ecken zerfällt.

Du meinst "in der maximalen Stufe, die aktuell von openstreetmap.org gerendert wird".

OSM ist aber eine Datenbank. Du hast garkeinen Einfluss, wer was wie rendert. Daher solltest du so wenig unnötigen, rein technischen Ballast wie möglich in die OSM-Datenbank schreiben. Und ein Kreis als Trennlinie mit viiiielen Nodes ist mehr Ballast als 2 Nodes.

gormo wrote:

geocodec wrote:

Ich habe die Zahl so gewählt dass die Linie in der maximalen Zoom Stufe gerade nicht in Ecken zerfällt.

Du meinst "in der maximalen Stufe, die aktuell von openstreetmap.org gerendert wird".

OSM ist aber eine Datenbank. Du hast garkeinen Einfluss, wer was wie rendert. Daher solltest du so wenig unnötigen, rein technischen Ballast wie möglich in die OSM-Datenbank schreiben. Und ein Kreis als Trennlinie mit viiiielen Nodes ist mehr Ballast als 2 Nodes.

Ich meine maximaler Zoom Stufe beim Editieren. Das Problem beim Editieren ist, dass wir uns dabei jeweils in einem nur sehr kleinen Ausschnitt von OSM bewegen. Eine gekrümmte Linie gibt hier immer noch ihre Außen und Innen- Information Preis.

Ich sehe OSM ebenfalls als Datenbank. Datenbanken leben von Inhalten. In Bezug auf Sparsamkeit stelle ich eher das klassische Zeichnen mit überlagerten Linien in Frage. Ich finde überlagerte Linien führen unser OSM direkt in die Sackgasse. Beispiel: http://www.openstreetmap.org/relation/3 … 9/14.74242

Dringendst sollte auch das OSM- Polygon Modell mit einer eindeutigen und aussagekräftigen, Außen und Innen Information nachgerüstet werden.

Edit: +Ref

geocodec wrote:

Ich meine maximaler Zoom Stufe beim Editieren. Das Problem beim Editieren ist, dass wir uns dabei jeweils in einem nur sehr kleinen Ausschnitt von OSM bewegen. Eine gekrümmte Linie gibt hier immer noch ihre Außen und Innen- Information preis.

Mein Editor (JOSM) zeigt mir auch an, wo außen und wo innen ist. Außerdem kennt er keine Zoomstufen.

Ich glaube immernoch nicht, dass deine Schattenringe einen Vorteil gegenüber einfachen Linien haben. Aber solange du das nicht großflächig ausrollst sondern immer nur für den Wald, den du grade fixst: mach es doch einfach. Nachdem du mit einem Wald fertig bist, sieht man die Ringe ja eh nichtmehr.

gormo wrote:

geocodec wrote:

Ich meine maximaler Zoom Stufe beim Editieren. Das Problem beim Editieren ist, dass wir uns dabei jeweils in einem nur sehr kleinen Ausschnitt von OSM bewegen. Eine gekrümmte Linie gibt hier immer noch ihre Außen und Innen- Information preis.

Mein Editor (JOSM) zeigt mir auch an, wo außen und wo innen ist. Außerdem kennt er keine Zoomstufen.

Ich glaube immernoch nicht, dass deine Schattenringe einen Vorteil gegenüber einfachen Linien haben. Aber solange du das nicht großflächig ausrollst sondern immer nur für den Wald, den du grade fixst: mach es doch einfach. Nachdem du mit einem Wald fertig bist, sieht man die Ringe ja eh nichtmehr.

Genauso habe ich das geplant, diese Ringe sind meine Stützwerkzeug für einen kurzen Zeitraum.

Der Aufforderung solche Strukturen keinesfalls in die OSM Datenbank zu laden, kann ich nicht folgen. Für eine saubere Auflösung eines großen Polygon´s, benötige ich als ehrenamtlicher OSM Mitwirkender, durchaus mehrere Tage.

geocodec wrote:

Der Aufforderung solche Strukturen keinesfalls in die OSM Datenbank zu laden, kann ich nicht folgen. Für eine saubere Auflösung eines großen Polygon´s, benötige ich als ehrenamtlicher OSM Mitwirkender, durchaus mehrere Tage.

Wenn mir so etwas über den Weg läuft, "korrigiere" (= lösche) ich das. Andere werden vielleicht auch so denken und weg ist deine "Stütze". Außerdem produzierst du haufenweise unnötige Nodes. Diese müssen von tausenden Systemen verarbeitet werden. Wenn du Pech hast, wird genau in diesem Moment eine neue Karte für ein Garmin generiert. Das Garmin hat dann ordentlich damit zu tun, diese sinnlosen Nodes zu rendern. Außerdem wächst dadurch unnötigerweise die Datenbank, weil Daten niemals gelöscht, sondern lediglich ausgeblendet werden. Je stärker du dein Verfahren nutzt, desto mehr unnötige Daten produzierst du.

SammysHP wrote:

geocodec wrote:

Der Aufforderung solche Strukturen keinesfalls in die OSM Datenbank zu laden, kann ich nicht folgen. Für eine saubere Auflösung eines großen Polygon´s, benötige ich als ehrenamtlicher OSM Mitwirkender, durchaus mehrere Tage.

Wenn mir so etwas über den Weg läuft, "korrigiere" (= lösche) ich das. Andere werden vielleicht auch so denken und weg ist deine "Stütze". Außerdem produzierst du haufenweise unnötige Nodes. Diese müssen von tausenden Systemen verarbeitet werden. Wenn du Pech hast, wird genau in diesem Moment eine neue Karte für ein Garmin generiert. Das Garmin hat dann ordentlich damit zu tun, diese sinnlosen Nodes zu rendern. Außerdem wächst dadurch unnötigerweise die Datenbank, weil Daten niemals gelöscht, sondern lediglich ausgeblendet werden. Je stärker du dein Verfahren nutzt, desto mehr unnötige Daten produzierst du.

Hier kommen wir zu einer grundsätzlichen Problematik.
Was ist OSM?
Meiner Meinung nach ist OSM inzwischen eine kollaborative Datensenke diverser kommerzieller Navigationsdienstleister, die ihre Daten als Kompost, und OSM als Acker zum Anbauen ihrer proprietären Produkte betrachten.
Unliebsame Ehrenamtliche sind für diese Unkraut. Pseudo ehrenamtliche Editoren gießen und jäten diverse Pflänzchen, in der Hoffnung Ehrenamtliche sind so dumm ihre wertvollen lokalen Geoinformationen unentgeltlich preiszugeben.
Mapnik ist dabei gerade so gut gemacht, dass dieses Projekt direkt nicht verwertbar ist.

Daher brauche ich mich von kommerziell mitwirkenden, hier nicht beflegeln lassen. Bin diesen aber trotzdem für Ihre bereitgestellten Daten dankbar!.

edit: typo

Dann hast du das entweder falsch verstanden oder stehst mit deiner Meinung ziemlich alleine hier. 😉

Hä? Kannst du da mal etwas konkreter werden?

geocodec wrote:

Meiner Meinung nach ist OSM inzwischen eine kollaborative Datensenke diverser kommerzieller Navigationsdienstleister, die ihre Daten als Kompost, und OSM als Acker zum Anbauen ihrer proprietären Produkte betrachten.

Welche Dienstleister wären das, und welche ihrer proprietären Produkte bauen sie hier an? Ich sehe da nur eine Datenbank voller sinnvoller Geoinformationen.

geocodec wrote:

Unliebsame Ehrenamtliche sind für diese Unkraut.

Wieso sollten sie das sein?

geocodec wrote:

Pseudo ehrenamtliche Editoren

Wen meinst du damit?

geocodec wrote:

gießen und jäten diverse Pflänzchen, in der Hoffnung Ehrenamtliche sind so dumm ihre wertvollen lokalen Geoinformationen unentgeltlich preiszugeben.

Wieso wäre das eine Dummheit? Das ist doch der Witz des ganzen Projekts. Wem es nicht paßt, der braucht nicht mitzumachen.

geocodec wrote:

Mapnik ist dabei gerade so gut gemacht, dass dieses Projekt direkt nicht verwertbar ist.

Was hat Mapnik mit den Projektzielen von OSM zu tun?

geocodec wrote:

Daher brauche ich mich von kommerziell mitwirkenden,

Wen genau meinst du damit?

geocodec wrote:

hier nicht beflegeln lassen.

Wer hat dich „beflegelt“? Deine hier geschilderte Praxis wird lediglich von den meisten für unsinnig gehalten, da man große MPs auch mit wesentlich weniger Datenvolumen sinnvoll aufteilen kann. Witterst du dahinter eine Verschwörung, gegen die sich die armen kleinen Lokalmapper zur Wehr setzen müssen? Dann will ich dir den Spaß nicht verderben.

--ks

kreuzschnabel wrote:

geocodec wrote:

hier nicht beflegeln lassen.

Wer hat dich „beflegelt“? Deine hier geschilderte Praxis wird lediglich von den meisten für unsinnig gehalten, da man große MPs auch mit wesentlich weniger Datenvolumen sinnvoll aufteilen kann.

Ja, und das Ganze wird mit harter Sprache hinterlegt:

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Das man sich da "beflegelt" fühlt, kann ich nachvollziehen, wenn man seinen Tonfall-Filter noch nicht auf jeden OSM-Nutzer eingestellt hat.

@geocodec: Hier will dir (hoffentlich) niemand was böses, aber einige verstecken das ganz gut ;-)

gormo wrote:

Ja, und das Ganze wird mit harter Sprache hinterlegt:

Du lädst bitte keine, ich wiederhole, keine Kreissegmente in OSM hoch, außer es handelt sich um rundliche Wälder. Deine Kringel haben nämlich viel zu viele Nodes.

Das man sich da "beflegelt" fühlt, kann ich nachvollziehen, wenn man seinen Tonfall-Filter noch nicht auf jeden OSM-Nutzer eingestellt hat.

Das ist hart in der Sache, aber keineswegs persönlich angreifend, kränkend oder beleidigend. Zwar entschieden formuliert, aber sachlich. Wer das als flegelhaft empfindet, ist in Internetforen noch nicht weit herumgekommen und sollte sich eventuell Antimimosan verschreiben lassen :-)

--ks

Über was man sich alles streiten kann...

Für mich sieht es so aus, als ob geocodec einen Weg für sich gefunden hat, Multipolygone zu zerteilen. Das Anliegen an sich ist doch gut und es ist ja auch legitim, wenn man sich die Arbeit vereinfacht. Geocodecs Verfahren hat für mich einiges mit der etablierten schrittweisen Verfeinerung gemeinsam, wobei man sich bei ähnlichen Fragestellungen lieber an Dreiecke statt Kreise hält. Andererseits hat jeder seine eigene Arbeitsweise und wenn jeder seinen oder ihren Weg samt Zwischenschritten in die DB schreibt, würde bei zig-tausend oder Millionen OSM-Mappern die DB bald nur noch Müll sein. Deswegen gibt es doch durch Anleitungen, Wiki und allgemeine Übung gewachsene Standards, die für alle gelten.
@geocodec: Aus dem Thread entnehme ich, dass Deine Lösung experimentell angefangen hat und noch verfeinert wird, z. B. durch die Erkenntnis, dass sich die Kreise nicht überlappen sollten. Das Einfachste und Konstruktivste wäre doch, wenn Du deine Zwischenergebnisse (die Kreise) für Dich lokal speicherst (mit dem von Dir verwendeten JOSM geht das doch auch) und erst dann, wenn Du fertig bist und *Dein* Hilfsmittel - die Kreise - wieder gelöscht hast, in die Datenbank hoch lädst. Nebenbei kannst Du in Ruhe Deine Verfahrensweise verbessern und wenn sie ausgereift ist, stellst Du sie mal im Forum oder einem Blogbeitrag vor. Dann gibt es keinen Stress wegen Datenmüll und die Anderen gehen unbelasteter und offener an Deine Ideen heran.

Im Übrigen kann ich nicht behaupten, hier im Forum schon mal unflätig gemaßregelt worden sein. Wer normal fragt, bekommt auch normale Antworten.

So,
auch wenn ich jetzt einfach Dinge wiederhole, die bereits andere gesagt werden.
Ich finde es scheisse, Formen in die Datenbank zu packen, die nichts mit der Realität zu tun haben. Vor Allem dann, wenn sie nur für Mapnik gemappt werden. Ich auch einen Style, der einige deiner Konstruktionen rendert. LASS ES!
Zweitens lassen sich deine Nodes nicht mehr restlos aus der Datenbank entfernen.
Drittens:

geocodec wrote:

Meiner Meinung nach ist OSM inzwischen eine kollaborative Datensenke diverser kommerzieller Navigationsdienstleister, die ihre Daten als Kompost, und OSM als Acker zum Anbauen ihrer proprietären Produkte betrachten.
Unliebsame Ehrenamtliche sind für diese Unkraut.

Für mich sind "unliebsame Ehrenamtliche" auch Unkraut. Sind diese für mich für Vandalismus und Editwars verantwortlich, helfen nicht diesem Projekt und stiften Unruhe. DU, sowie alle anderen, die hier Daten hinzufügen, haben zugestimmt, dass JEDER diese Daten verwenden darf - und auch damit Geld verdienen darf. Gefällt dir das nicht, dann geh bitte woanders hin.

Ehrenamt hört sich sehr schön und wichtig an, aber im Endeffekt ist es weder ein Amt, das du hier begleitest, noch erwachsen dir daraus irgendwelche Verpflichtungen. Bei einem Gemeinschaftsprojekt muss man Rücksicht nehmen, und du nimmst diese nicht in ausreichender Art und Weise. Heute ist es sehr modern, immer und überall die "Ehrenamtskeule" auszupacken, aber auch ein Ehrenamt beschützt keinen vor Kritik! (die in meinen Augen absolut angebracht ist.)

Deine Idee mag ja nett und selbstlos gewesen sein, die Ausführung tangiert aber andere Nutzer und das sollte unterbleiben! Niemand möchte, dass du das mappen sein lässt oder OSM verlässt. Wenn du deine Kreise lokal verwendest und nicht hochlädst, ist doch alles OK.

Auch wenn ich den Ton etwas bissig finde, muss ich hier ngt (#70) doch im Wesentlichen zustimmen.

kreuzschnabel wrote:

Erstes Beispiel, nach 30 Sekunden Suche gefunden: http://www.openstreetmap.org/#map=18/52.07100/7.56153

Zwei Flächen mit landuse=farmland stoßen mit einer Haarlinie aneinander. Sind es zwei physische Äcker, ist das Rendering so absolut sinnvoll und gliedert die Karte viel besser als wenn dort nur ein durchgehendes Braun wäre. Ich würde es begrüßen, wenn alle aneinanderstoßenden landuse so gerendert würden, ohne daß man eine Trennlinie explizit einzeichnen muss. Denn aus dem Mapping ergibt sich ja, dass dort zwei unterschiedliche Flächen aneinandergrenzen.

Mit landuse markieren wir IMO recht pauschal und explizit grobflächig die Landnutzung. Einzelne Äcker sollten damit nicht umschrieben werden, genausowenig wie einzelne Grundstücke bei landuse=residential.

Wenn einzelne Äcker als solche erkennbar sind, dann muss man die geeigneten Trennelemente (Hecke, Graben, Bach, Weg etc.) eintragen. Besonders bei Farmland kann sich die Grenzziehung, wenn die Äcker nicht durch physische Elemente getrennt sind, eh von Saison zu Saison ändern.