Hoffentlich, denn dafür gibt es ja wieder die mit Aufhängehöhen gemappten Hundekottütenspender.
Wieso? Wenn die opendogshitmap.org minütlich aktualisiert wird brauchen wir das unbedingt! 
bye
Nop
Finde ich nicht gut. Denn wenn die Ordnungshüter die Karte verwenden und mit den durch mein Handy erzeugten Bewegungsmustern abgleichen, da ich als Hundesteuerzahler als potentieller Handlungsstörer infrage komme, kann das für mich ganz schön teuer werden. Es sei denn, die Hundekottütenspender sind endlich mal vollständig gemappt.
Projekt der Woche?
Hat leider alles nix mit Multipolygonen zu tun, aber die diskutieren wir ja ernsthaft bei den verschwundenen Seen weiter. 
Naja, die ernsthafte Diskussion ist an dem Punkt angelangt:
- Wir sind uns einig, wie eine bessere, verständlichere Anwendung aussehen müßte.
- Es interessiert niemanden und es wird sich nix ändern.
Also wieso nicht ein wenig Spaß haben?
bye
Nop
Au Mann! Ich lach mich noch schlapp hier! 
Warte mal ein wenig. Ich verschnaufe gerade nur
zu 1. Wenn wir uns einig sind, dann sollten wir auch für eine verständlichere Anwendung sorgen.
zu 2. Es interessiert doch einige und wenn man will, kann man was ändern.
Ich schaue mir gerade verschiedene MP an, um zu ergründen, ob die sinnvoll angelegt sind und ob man Muster bei typischen Fehlern erkennen kann, aus denen man dann allgemeingültig Empfehlungen, Warnungen, howto’s oder so basteln kann, damit der ganze Datenhaufen auch vernünftig weiter zu bearbeiten/verwenden ist.
Immer schön den Endanwender im Auge behalten 
Große MP aufzuteilen, befürworte ich auch. Sonst sucht man sich bei MP-Fehlern (offene Ringe, doppelte Members usw.) zum Krüppel.
Die Schnittlinien sind ein Renderer-Problem und mir offen gesagt wurscht, weil ich davon ausgehe, dass die Renderer-Entwickler das eines Tages in den Griff kriegen werden.
In einem Heimwerker-Forum wurde diskutiert, ob man Löcher besser zwischen die Kacheln oder mitten in die Kacheln bohrt. Diese 2 Ansätze gibt es im Grunde auch bei Multipolygonen. Ich gehöre zu denen, die am liebsten mitten in die Kacheln bohren. D.h. ich lege die Wald-MP-Grenzen mitten durch den Wald, wo weit und breit nichts ist, was stören könnte. Nutzt man eine Straße als Grenze, dann hat man das Problem, dass beim Aufteilen der Straße (wegen Brücken, Geschwindigkeitsbeschränkungen, verschiedener tracktypes o.ä.) die Multipolygone eine Vielzahl an Außengliedern bekommen, was der Intention zur Vereinfachung widerspricht.
Außerdem verlaufen Straßen oft durch kleine Wiesen oder an deren Rand. Wenn man die Wiesen am Rand eines MP als “inner” einfügt, dann meckern bestimmte Validatoren, und es dauert nicht lange, bis jemand in der Wahnvorstellung das MP reparieren zu müssen irgendwas zerstört.
Mit den Querwaldein-Grenzen hat man alle diese Probleme nicht.
Thema Harz: Das ist AFAIK ein Gebirge. Da es bestimmt nicht nur mit Wald bedeckt ist, sondern auch mit Wiesen usw., kann man nicht einfach die Waldflächen zu einer Relation name=Harz zusammenfassen. Das gleiche Problem hatte ich im Leithagebirge, wo es eine Waldfläche mit name=Leithagebirge gab. Als ich begann, den Wald genauer zu zeichnen, hab ich fürs Leithagebirge eine eigene, gob umrissene Fläche (ID 94453497) angelegt mit natural=mountain_range. Überraschend rendert Mapnik sogar den Namen, allerdings falsch (an der Umrandung, obwohl area=yes gesetzt ist.) Es wird allmählich Zeit, wichtige natural=* wie valley, ridge und mountain_range zu proposen.
Das Aufteilen an Straßen hatte ich so interpretiert, dass man einen parallelen way zu der Straße zeichnet. So zumindest praktiziere ich es schon länger. Natürlich nur, wenn der Wald wirklich geteilt wird.
Dann trete ich einen Schritt beiseite um die Optimisten nach vorn zu lassen. Ich würde mich freuen wenn Du tatsächlich was bewegen kannst - ich habe die Hoffnung aufgegeben. Ob OSM verständlich und für Otto Normalverbraucher nutzbar ist, interessiert einfach viel zu wenig Leute - insbesondere unter denjenigen, die das Format der Dinge festlegen.
bye
Nop
Ein neuer Typ area (zusätzlich zu way und node) wäre wünschenswert. Das ändert aber nichts an diesem Problem. Es wäre lediglich für die Auswerter einfacher Flächen von Wegen zu unterscheiden. Das bisherige area=yes wäre dann überflüssig und eine Vermischung von Weg- und Flächentags wäre endlich vorbei.
Ich denke eher, es ist an euch Kritikern, ein Schema zu entwickeln, was eine gleichbleibende Funktionalität mit sich bringt und einfacher zu verstehen ist.
Meiner Meinung nach liegt es primär an den Editoren, das Thema für jeden verständlich zu machen. Bei CAD ist das recht trivial und man bekommt von der technischen Struktur nichts mit. Man zeichnet bspw. in ein Rechteck einen Kreis und sagt dem Programm, dass es den Kreis von der Fläche abziehen soll. Ähnlich sollte es auch bei OSM sein und der Editor sollte selbstständig die Relation anlegen und die Tags richtig setzen. Eine Auswahl der Fläche sollte auch über einen Klick in die Fläche erfolgen und in den Eigenschaften sollten dann die Eigenschaften der ausgewählten Fläche angezeigt werden, unabhängig davon, wo sie getagt sind.
Zusätzlich kann der heutige Modus als Expertenmodus erhalten bleiben.
Das Problem ist, daß sich ohne ersichtlichen Grund das Handling einer Fläche komplett ändert. Die jetztige API ist nur darauf ausgelegt, es für den API-Server möglichst leicht zu machen - die Komplexität trifft die Mapper, Editoren und Renderer. Denn die müssen aus den Einzelteilen wieder ein Gesamtbild machen, ändern, und wieder für die API auseinanderbrechen. Sozusagen “Alle für Einen”, weil mit sehr primitiven Mitteln wesentlich komplexere Dinge beschrieben werden sollen. Die Fehlerquote ist auch entsprechend hoch.
- Normales Polygon: Der Way ist das Polygon, die way-id identifiziert das Polygon
- Multipolygon: Der way ist das Polygon, über eine Relation werden andere Ways als Löcher assoziiert, die way-id identifiziert das Polygon
- Advanced Multipolygon: Die Relation ist das Polygon, die relation-id identifiziert das Polygon
Hier ist dreimal dieselbe Sache mit unterschiedlichen Mitteln dargestellt - und das macht das Ganze so unverständlich.
Was ich mir spontan als bessere Variante vorstellen könnte: Trennung von Geometrie und Information und Darstellung der Objekte in einer versändlichen Hierarchie, also sowas wie:
Geometrie (ohne Tags):
Objekte (mit Tags)
- : hat
- : hat
- : hat outer-, hole-
Gruppierungen
- :
Damit ist ein polygon nur noch der einfachste Fall eines multipolygons und es ändern sich nicht je nach Komplexität das gesamte Handling.
Die heutige DB sollte sich ohne Datenverlust automatisch auf so eine Struktur übernehmen lassen - zumindest alles was ein Renderer versteht. Und da wo jemand was besonders abgefahrenes konstruiert hat - müßte es so oder so von Hand repariert werden.
bye
Nop
Es ist ja auch dringends davon abzuraten, fuer den rand der Flaechen den selben Way zu benutzen, der auch fuer ein anderes Objekt genutzt wird. Denn besser verstecken koennte man die Information fuer die Gelegenheitsmapper gar nicht.
Also fuer den Flaechenrand immer einen eigenen Way benutzen, ob der die selben Nodes benutzen sollte wie die Strasse oder leicht daneben liegt ist Geschmackssache.
Wenn man entlang der Strassen schneidet, dann braucht mal solche an die Strassen angrenzenden Objekte ja auch nicht mehr per Multiplogon-Relation aus dem Wald ausschneiden. Denn sie liegen ja durch den Schnitt gar nicht mehr mitten im Wald. Durch geschicktes Schneiden kann man sich also haeufig auch noch die Relation sparen, und schon wird das ganze Konstrukt wieder eine Nummer einfacher. Was will man mehr?
Gruss
Torsten