Das waere - ungeachtet der eigentlichen Themas dieses Threads - wirklich wuenschenswert. Selektiv nur landuses, naturals, buildings, highways/paths einblenden koennen mit einem Click: das wuerde mir bei der alltaeglichen Arbeit extrem helfen. Manchmal ist weniger eben mehr.
“Fehler” nicht, aber manches erscheint mit Verlaub absolut unnötig und auch unsinnig:
http://www.openstreetmap.org/browse/relation/3170443
Die drei nördlichen Flächen bestehen aus normalen geschlossenen Ways und sind zu einer Outers-Relation zusammengefasst, ohne das es es Inners gibt? So was hat nicht mal der User M…k aus der Oberlausitz gebracht.
Da die Relation seit dem 28.8. nicht mehr angefasst wurde, kommt die Ausrede “Work in Progress” wohl nicht in Frage.
Na Ja, der Bauer dem die 3 Felder gehört hat seinen Namen nicht für die ODBL Freigegeben.
Das wäre doch ein Grund für die Zusammenfassung ohne weiter sinnvolle Tags auf der multipolygon ebene.
Eine gewisse Akribie kann ich dem Kollegen nicht absprechen. Eine Fläche die bei mir 4 Nodes bekommt, mapt er mit
32.
Christoph
btw, wo ich einmal dabei bin, ist mir natürlich vom kleinen Urlaubsort aus ein Riesen Polygon über den Weg gelaufen (ein Wald und derer gibts bei den Österreichern grosse).
Ist es im Sinne der Editierbarkeit eigentlich legitim eine Waldfläche ohne Namen zu splitten in handhabbare kleinere MPs ?
Christoph
Ich bezweifle, dass soetwas der Grund dafür ist. Und selbst wenn könnte man es als einfache Flächen lassen wenn man es eh nicht einträgt (davon abgesehen, dass sich auch das ohne Multipolygon lösen liesse).
Das Problem hier ist nicht “Atom-genaues Mappen” vs. “schnell mal hingekritzelt” sondern “unnötig kompliziert” vs. “so einfach wie möglich, so kompliziert wie nötig”. Bei letzterem ist übrigens letzteres die “Datentechnisch sauberere Abbildung” (was auch immer genau ihr damit meint).
Ja, du darfst sogar Waldflächen mit Namen aufteilen, wenn du es richtig machst (ich kenne mich damit nicht aus, aber das geht bestimmt). Und du darfst es sogar in einfache Polygone aufteilen falls das sinnvoll möglich ist 
Ich gebe die 100 %tig recht. Kompliziert ist doof.
Nur eine formale “Handhabe” der Art “Du machst das Falsch” ist nicht gegeben.
Allerdings spricht nix dagegen, den Kollegen freundlich auf eine überflüssige Kompliziertheit aufmerksam zu machen.
Immerhin gibt es einen guten Grund, OSM Lebt nur, solange es Mapper gibt, die die Daten verstehen.
Nachdem ich gerade überlegt habe ein MP zu splitten ist mir aufgefallen, das das durchaus aufwendig sein kann.
Einen Weg kann JOSM Splitten, aber ein MP nicht. Alle Inner und Outer müssen dann ja richtig zugeordnet werden. Das übt …
Vor allem, wenn es einem nötig erscheit, sollte man es tun!!! Viele Nutzer verbinden einen Namen eines Waldgebietes damit, daß diese Fläche dann auch als Polygon/ Multipolygon zusammen zubleiben hat.
Diese Ansicht ist in meinen Augen Falsch. Die Verwendung von Polygonen/ Multipolygonen (so man sie denn so in OSM Nennen möge) sollte zunächst allein der räumlichen Natur der Verteiung der Objekte erfolgen (und nur dieser?!!) und nicht als erstes des Inhaltes. OSM bietet genühend Möglichkeiten, Räumliche und inhaltliche Beziehungen zu verbinden (Relationen!).
Grundtenor sollte sein:** “So einfach wie möglich.”** Eine Erfassung eines Objektes als (komplexe) Relation, daß auch als einfaches Objekt erfasst werden kann, ist keine einfache Erfassung. Ich verweise hier auf: http://forum.openstreetmap.org/viewtopic.php?id=22490.
Das heist für mich im Allgemeinen *): bei Flächen möglichtst geschlossene Linienzüge zu verwenden, bei Objekten, die als einfache gechlossene Linienzügen dargestellt werden können, sind diese als einfache Linienzüge darzustellen. Relationen sind nur wenn nötig zu verwenden und möglichst als Relation von geschlossenen Linienobjekten. Es gibt keine taglosen Objekte in Relationen.
*): Administrative Grenzen zähle ich nicht dazu.
Sven
Ja da ist Handarbeit angesagt.
Der Validator erkennt aber falsche Inner, die nach dem Aufteilen nicht mehr innerhalb eines Outer liegen. So bleiben einem einige Fehler erspart. Voraussetzung ist natürlich, dass das MP komplett geladen ist. Sonst wäre zu wenig zum Prüfen vorhanden.
Edbert (EvanE)
Wenn es da weiße Lücken gibt, könnte das auch bedeuten, dass der Renderer die Straße zu schmal zeichnet
Ironie ein Ansonsten ist in der Realität der Streifen zwischen dem Acker und der Straße in D meistens grün/grau. Ich glaube, da hilft nur, dass die Standardkarte einen grünen (und im Winter weißen) Hintergrund zeigt. Ironie aus
Wenn M…k der User ist der in Ostdeutschland nach dem Lizenzwechsel wegen nicht Zustimmung
große Lücken hinterließ: Jener der ich meine IST in neuer Inkarnation geokyf. Zumindest schrieb
das letzterer mal, weis aber nicht mehr wo, ist länger her. Von der manischen mapping Menge passt es.
Ansonsten bin ich gegen MP. Die sollte man nur nutzen wo es unumgänglich ist.
Die Dinger sind unwartbar[1]. Bei sowas wie Grenzen ist es gut. Shared Nodes haben
ihre Probleme, sind meist ok. Shared ways (MP) sind da noch mal eine Kategorie
problematischer.
Aber ich hab’ gerade keine Zeit weiter aktiv gegen MP zu arbeiten:-)
[1] Da meine ich in erster Linie die mit vielen outer Wegstückchen die auch noch
in vielen weiteren MP genutzt werden. Ein außen geschlossenes Polygon das
paar inner hat geht ja noch. Aber auch die scheinen öfter nicht so nötig: steht man
auf einer Lichtung im Wald und wird angerufen, sagt man da nicht ‘Bin gerade im Wald’?
Die Lichtung ist also teil vom Wald, stehen aber halt keine Bäume (landuse vs. landcover?)
Das Problem wird da: ab welcher Größe wird die Lichtung zur großen Wiese, zum Tal?
Ich glaube es gibt auch kein “gegen oder für MP” arbeiten. Wenn wir offensichtlich der Meinung sind, das wir die nächste Komplexitätsstufe erreicht haben, müssen wir die Basis erweitern.
Mit den vorhandenen Mitteln können wir sicher noch einige Zeit erfolgreich weitermachen. Insbesondere wenn wir uns “zusammennehmen” und wartbare Dinge bauen, also gerade im MP Umfeld uns “Zurücknehmen”.
Was meine ich mit Basis erweitern (andere haben da bestimmt bessere Ideen als ich)
Flächenobjekte (ist glaube ich schon Thema)
Mengenreduktion durch Filter in den Editoren (oder noch besser ein selektiveres API, auf dem iPhone mit Go Map wären weniger Daten manchmal gut)
Verbesserte Editoren (Frage sind die MPs nicht wartbar, weil sie MPs sind, oder weil die Editoren nur die Basissachen bei MPs unterstützen ).
Ich fände gerade die API Diskussionen interessant, wo wir das eigentlich diskutiert ?
Christoph
Steht hier - aber unter Diskutieren verstehe ich was anderes. Ist verd. wenig los hier, fast schon tote Hose. 
Gruss
walter
Hallo Walter
Nun ja, scheint alles nicht so dringend zu sein.
Eine API-Umstellung ist eine ziemlich große Sache, da ja alle Programme, die auf die API zugreifen, angepasst werden müssen. Dies gilt umso mehr, als die Einführung eines neuen Datentyps für Flächen (das Einzige, was mir dringend / wichtig erscheint) einen harten Schnitt darstellt. Damit geht dann nur alte oder neue Version. Wenn man jetzt noch bedenkt, wie lange der Umstieg auf 64-Bit IDs in den diversen Programmen gedauert hat (was ja vorab ohne Probleme ging), macht man das nur, wenn man es für unvermeintlich hält.
PS-1:
Ich hatte selber damit gerechnet, dass API 0.7 bald nach Abschluss der Lizenz-Umstellung (also in diesem Jahr) angegangen würde. Dem ist offensichtlich nicht so.
PS-2:
Es ist ja - trotz dringendem Wunsch - durchaus noch nicht klar, wie ein Flächendatentyp zu realisieren wäre.
Edbert (EvanE)
genau, das ist auch für mich das Allerwichtigste - und auch das Schwierigste.
Gruss
walter
- Fehlposting
Im Wiki findet zum Thema Aereas hier noch was statt:
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas
Jochen hat auf seinem SOTM Vortrag, die (grossen Dank an Peda) auch geschnitten vorliegen,
http://osm.won2.de/sotm/d3t1-1610-Jochen_Topf-Towards_an_Area_Datatype_for_OSM.mp4
Werbung dafür gemacht.
Der Vortrag ist eine gute Zusammenfassung des Ist mit Aufforderung das Soll noch zu definieren.
Ich finde diese ganzen Diskussionen um Areas ehrlich gesagt etwas albern. Alle beschriebenen Ansätze laufen letztendlich mehr oder weniger auf das Multipolygon hinaus, was ja damit eigentlich abgeschafft werden sollte.
Wenn man Flächen nur noch als Multipolygone zulassen würde, wären alle im link erwähnten Probleme schlagartig behoben. Natürlich außer denen, die von Leuten verursacht werden, die nicht begreifen (wollen), dass ein Vieleck von mehreren Kanten begrenzt wird.
Das einzige Problem, das durch einen Multipolygon-Zwang behoben würde, wäre die Unklarheit, ob ein bestimmtes Tag einen Way zur Fläche macht. Aber davon abgesehen ist die Einführung eines eigenen Area-Datentyps vor allem deshalb interessant, weil damit API-Support für die Verhinderung ungültiger, z.B. selbst-überschneidender Flächen sowie die Möglichkeit zum teilweisen Download von Flächen (aber trotzdem noch mit der Information, wo innen ist) realisiert werden können. Auch eine bessere Konfliktbehandlung wäre wünschenswert. Das alles leisten Multipolygone, so wie sie derzeit umgesetzt sind, nicht. Und das sind auch die eigentlichen technischen Herausforderungen bei der Sache.
Glaubst Du dran? Die API erlaubt seit Jahren Wege aus nur einem Knoten, Wege mit mehrfachen identischen Knoten, leere Tagschlüssel und -werte, selbstreferenzierende Relationen, … also Konstrukte, die noch viel einfacher zu erkennen und zu verhindern wären. (Allerdings würden mehrere Editoren ganz oder teilweise ausfallen, wenn solche Objekte von der API abgelehnt würden.)
Ich finde den Vortrag von Jochen Topf gut, und stellt die Grundlagen einleuchtend dar: einerseits Polygone ohne innere Flächen, dann Polygone mit Löchern (See im Wald - Problem) und dann Multipolygon als Relation. Hier muß man ganz klar unterscheiden zwischen solchen, die ein einzelnes Objekt definieren: Fläche, Linie, Punkt und solche die eine Sammlung von Objekten repräsentieren: Multipolygone, Grenzen, ect.
Richtig. Mit wenigen Tools (z.B. Clip) ließen sich diverse Geometriefehler (Invalid Geometry) vermeiden. Ich wundere mich ohnehin, daß es Clip bei JOSM nicht gibt.
Das wäre z.B. die richtige Aufgabe um diesen Fehler zu vermeiden: Eine Inner-Fläche grenzt an mindestens zwei Punkten an die Außengrenze. Das kleine MP mit Grünland und Wasser muß aus dem Großen Waldpolygon ausgeschnitten werden. So, wie es jetzt ist, ist es eine fehlerhafte Geometrie, Die wäre es sowohl beim echten Polygon als auch bei einer Multipolygon-Relation. PS: Der Fehler ist schon beseitigt, OSMI ist nur noch nicht alktualisiert.
auf Datentyp Fläche hoffend,
Sven