Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 29.09.2011 02:02, schrieb Garry: So einfach ist das leider nicht. Mein Standpunkt ist das die highway-ways in erster Linie Routingdaten sind die nichts direkt mit Flächendaten zu tun haben - Also wenn ich eine Fläche als MP erfasse und eine Flächengrenze ein highway ist, hat der highway doch nur /in/direkt etwas mit der Fläche zu tun. Das siehst Du doch schon daran, dass die Flächentags an das MP vergeben werden und nicht an den highway. mit der wesentlichen Aussage dass (landuse-)Flächen nicht mit highways, sondern nur mit den Flächendaten der Strasse (also dann highway= road)verknüpft werden dürfen. Meines Wissens gibt es dazu keinen Konsens. Und wie wir stets feststellen, ist es mit einem nicht [...] dürfen, also einem Verbot aus dem Wunschdenken eines einzelnen heraus, nicht getan. Wenn Du es umformulierst und schreibst, Flächendaten sollten wiederum mit Flächendaten verknüpft werden, klingt das, so als Empfehlung, schon besser.. Außerdem hoffe ich, Du meintest hier: landuse=road .. highway=road als area gibt es schon und meint etwas anderes (und zwar die /Verkehrs/fläche eines unbestimmten Straßentyps) Evtl. könnte man wieder versuchen, das Argument ins Feld zu führen, dass Routing-Layer und Landuse-Layer getrennt voneinander bearbeitbar sein sollten, damit die einen nicht die Arbeit der anderen kaputt machen - ich empfände eine solche strikte Trennung dann aber auch etwas künstlich, weil dann die einen von der Arbeit der anderen auch weniger profitieren können (wenn ich als Flächenerfasser, keinen highway als Flächengrenze benutzen darf, muss ich sie neu erfassen). Wohlgemerkt hat der Wunsch nach getrenntem Editing nichts damit zu tun, dass Routing- und Landuse-Layer sonst nicht zu trennen wären. Ließe man die Daten weiterhin verknüpft, benutzt also highways als Flächengrenzen, ist es überhaupt kein Problem, Routing- und Landuse-Layer auseinanderzuhalten, ja sogar sie getrennt zu erzeugen, z.B. mit Osmosis (indem einfach nach Tag landuse=* inkludiert oder exkludiert wird). Noch eine Bemerkung zu den vielen Beschwerden über Flächenedits, welche den Routing-Layer verunglimpfen. Oft ist das auch wieder ein Editing Problem - z.B. habe ich in the wild erlebt, wie durch Editing-Features, die eigentlich der Bequemlichkeit dienen, Wege mit Flächenstil weitergezeichnet wurden, die vorher schon längst geschlossen waren - oder umgekehrt: Flächen erzeugt wurden, indem ein bestehender /highway/ zu einem closed way verlängert, dann aber nicht getrennt und extra getaggt wurde - da gibt es dann Wege auf Flächengrenzen, die gar nicht existieren. All das ist aber kein Grund, die Flinte ins Korn zu werfen und zu meinen: kill the convenient editing-features. Es wird immer Leute geben, die sich im Lernprozess befinden oder etwas besonders schnell erledigen, und auf diese Weise editing-features so benutzen, dass etwas Unerwartetes dabei herauskommt. Damit muss man leben, ich würde da keinem Mapper Absicht unterstellen. Gleichfalls bin ich nicht der Meinung, dass wir aufgrund dessen, das andere Fehler in die eigenen Daten bringen können, versuchen sollten, wo es nur geht, Abhängigkeiten zu reduzieren, bis wir zum Schluss bei der Regel angelangt sind: jeder darf einen Node setzen, aber nicht dort, wo schon einer ist. Das OSM-Technotop macht doch schon vor, wie es richtig geht: Analyzers und Tools schreiben, welche die Daten validieren, und Fehledits entdecken - das dann fixen. Für letzteres braucht man eine Vorstellung davon, /wie/ ein optimales Abbild aussieht und auch nur damit kann eigentlich ein Validator geschrieben werden. Die Probleme bei der Verwendung von closed/overlapping ways bei der Flächenerfassung wurden in den letzten beiden Monaten auf dieser Liste zur Genüge dargestellt. Nun kann man sich fragen, ob es sinnvoll ist, einen highway in einer bestimmten Rolle eines MP zu verwenden, oder nicht. IMHO spricht nichts dagegen. Wobei ich mit Dir einer Meinung bin, dass /wenn/ ein landuse=road vorhanden ist, oder eingezeichnet wird, die Flächengrenze dieses landuses wiederverwendet werden sollte, um die nächste Fläche anzudocken, und nicht die highway-Linie. Falls zu diesem Zeitpunkt im MapView schon ein landuse=* an den highway grenzt, legt man das eben um - das ist mit MPs wesentlich einfacher, als wenn die Flächen über closed ways erfasst sind, weil nur Mitgliedschaften geändert werden müssen, und keine basisgeometrischen Wege gelöscht/geändert werden müssen (was fehleranfälliger wäre). Wenn ich etwas ergänzen/die Genauigkeit verbessern möchte dann sollte das dadurch möglich sein dass ich vorhandenes idealerweise einfach nur etwas zurechtrücken muss ohne in eine Struktur einzugreifen mit der ich mich erst intensiv auseinandersetzen muss, einen komplexen Editor benötige und einen grösseren Schaden durch kleine Fehler anrichten kann. D.h. eine Detailverbesserung an Flächen und Linien muss mit
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Garry, Am 29.09.2011 13:35, schrieb Garry: Mit Multipolygon-Relationen sind die Eigenschaften nicht in einer Linie sondern in den Relationen, welche die Linie benutzen. Das Editoren mit Multipolygonen wesentlich besser umgehen könnten, habe ich bereits geschrieben.. Ja - könnten - das erfordert aber deutlichen zusätzlichen Aufwand für die Programmierer - Es wird weniger einfache Tools geben um z.B. mit kleinen Anwendungen für Mobilgeräte online unterwegs die Daten zu modifizieren. Diese Bedenken teile ich eigentlich nicht - gerade MPs machen die Bearbeitung einer Flächengrenze und damit von Flächen vor Ort möglich, die sonst aufgrund ihrer immensen Größe gar nicht auf das mobile Gerät passen würden.. Weiterhin wird die Datenmenge, die transferiert wird, minimiert, wenn nur geometrische Daten der bounding box geladen werden müssen, die der Nutzer auf dem mobilen Gerät gerade sieht. Siehe Debatte zur dt. Grenze - wenn ich mich mit einem PDA in der Nähe von Görlitz aufhalte, muss ich, wöllte ich dort den Verlauf korrigieren, eben nicht die gesamte Grenze transferieren. Ich bin also etwas optimistischer und schätze, dass mehr Tools möglich sind, auch für low-fat Geräte. Flächendaten der angrenzenden Flächen können beliebig genau sein. Es verbietet sich daher schon aus der Sicht des technischen Zeichnens diese mit Linien zu verknüpfen die den Verlauf einer Strasse als Fläche nur symbolisieren und keine Aussage darüber treffen was alles zu dieser Fläche dazugehört (Entwässerungsgräben, Schutzflächen,...) ich wäre für auch, nicht schon .. - es verbietet sich daher auch aus der Sicht .. Dein Argument, dass Flächengrenzen bel. genau sein _können_, verstehe ich vollkommen (siehe Küstenfraktale z.B.). Nur kann ich eine Flächengrenze erst dann genau erfassen, wenn ich auch genaue Quellen habe und _bis_ dahin, ist es IMHO besser und sauberer, wenn ich die topologische Information ausdrücke und nicht die letztlich geographisch exakte, zu der ich in Ermangelung an Quellen keine Aussage treffen kann. Wir drehen uns hier im Kreis, ich erinnere an eine mail, die wir dazu hatten, indem ich Dich fragte, ob Du auch noch zwischen Bord und Pflasterstein Platz lassen möchtest, weil es geographisch nicht korrekt ist - schließlich ist da noch Sand dazwischen. Die Frage muss sein, welchen Sachverhalt der Realität man abbilden möchte. Will ich den Sachverhalt, dass ein Wald an die Straße grenzt (was nur eine grobe Aussage zur Lagebeziehung ist, und immer sein wird, aber das kann ich eben modellieren) oder möchte ich den Sachverhalt ausdrücken, dass zwischen etwas und etwas anderem immer noch ein drittes etwas ist (das ist Leibniz - egal wie klein der Raum wird, ich kann ihn immer nochmal in zwei Teile teilen). Letzteres können wir mit OSM nicht modellieren, da wir dazu unbegrenzte Genauigkeit bräuchten, eine Grenze zu erfassen - die haben wir nicht. Wir haben vielleicht morgen eine bessere Genauigkeit und übermorgen wieder eine bessere, aber das wird nichts daran ändern, dass wir auch solche groben Aussagen wie der Wald grenzt an die Straße brauchen, um uns in der Welt zurechtzufinden. Natürlich ist diese Aussage nie genau, weil sich immer noch etwas genaueres finden lässt, dass an die Straße grenzt - egal welche Definition Du verwendest. Aber diese Aussage ist ein Abbild der Realität, so wie unsere kognitiven Fähigkeiten uns das erlauben. Wir kommen in OSM nicht umher, eine Struktur zu benutzen, um sowohl die etwas gröberen Abbilder, als auch die sehr detailierten (aber immer noch begrenzt genauen) Abbilder der Realität, welcher MapperInnen zusammentragen, zu verwalten. Diese Struktur ist, wenn es um Flächen geht, schon vorhanden, sie heißt Multipolygon. Sie wird bereits mal dort und mal da in begrenztem Kontext eingesetzt, sie aber als /das/ verbindende Element zwischen MICRO- und MACROmapping Welten zu begreifen, fehlt. Eine konsequente MP-Verwendung ist z.B. bei den politischen Grenzen, sprich polit. Flächen zu erkennen - da werden Teile von Teilen von Teilen gemappt und ihre Beziehungen untereinander eben auch. Man mappt Gemeindegrenzen zum einen, ein Vorgang der sich völlig losgelöst betrachten lässt, und mappt danach die Beziehungen der Grenzsegemente zu größeren Flächen. Für Aussagen zur Bodennutzung geht das genau so: Man mappt die Grenze zwischen Brandschutzstreifen und Entwässerungsgraben und setzt deren Grenzsegmente danach in Beziehung zu größeren (sprich gröberen) Sinneinheiten (Straße, Wald, Gebiet, etc.). Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 29. September 2011 17:02 schrieb Christian Müller cmu...@gmx.de: Wir drehen uns hier im Kreis +1, und die Mails werden nicht kürzer. Wer soll das alles lesen? , ich erinnere an eine mail, die wir dazu hatten, indem ich Dich fragte, ob Du auch noch zwischen Bord und Pflasterstein Platz lassen möchtest, weil es geographisch nicht korrekt ist - schließlich ist da noch Sand dazwischen. wenn wir einzelne Pflastersteine mappen würden, dann klar ja. Wenn man die Pflasterung mappt gehört Sand und Stein zusammen. Aber die wenigsten würden auf die Idee kommen, den Grasstreifen daneben absichtlich auch noch miteinzuschließen. Die Frage muss sein, welchen Sachverhalt der Realität man abbilden möchte. Will ich den Sachverhalt, dass ein Wald an die Straße grenzt (was nur eine grobe Aussage zur Lagebeziehung ist, und immer sein wird, aber das kann ich eben modellieren) wie schon erläutert ist das durch die Lage bereits klar (Stichwort Geodatenbank). Wenn Du den Wald an seiner Grenze erfasst hast und feststellen willst, ob eine Straße innerhalb der nächsten 50 m ist, dann musst Du nur die Ausdehnung des Walds um 50 m erweitern (in Deiner Abfrage, nicht in der OSM-Datenbank) und sehen, ob sich Straßen darin befinden. Wenn Dich auch Straßen interessieren, die innerhalb von 30 oder 100 m liegen, dann kannst Du auch das abfragen: Du entscheidest selbst, bis zu welchem Abstand die Straße noch am Wald läuft. Im übrigen dürfte das nicht gerade eine häufig nachgefragte Eigenschaft sein, ob sich in der Nähe einer Straße ein Wald befindet. Wo uns das mehr interessiert (z.B. Wohngebiete) haben wir schon längst einen workaround (highway=residential) geschaffen. oder möchte ich den Sachverhalt ausdrücken, dass zwischen etwas und etwas anderem immer noch ein drittes etwas ist (das ist Leibniz - egal wie klein der Raum wird, ich kann ihn immer nochmal in zwei Teile teilen). Letzteres können wir mit OSM nicht modellieren, da wir dazu unbegrenzte Genauigkeit bräuchten, eine Grenze zu erfassen - die haben wir nicht. das stimmt so nicht: wenn klar ist, was alles zu einem bestimmten Flächentyp gehört, (s. oben Pflasterung vs einzelne Pflastersteine), dann kann man nicht immer noch etwas erfinden, was dazwischen passt, sondern dann gehört es zum Modell, dass die Bordsteinkante mit der Kante der gepflasterten Fläche verbunden ist. Wir kommen in OSM nicht umher, eine Struktur zu benutzen, um sowohl die etwas gröberen Abbilder, als auch die sehr detailierten (aber immer noch begrenzt genauen) Abbilder der Realität, welcher MapperInnen zusammentragen, zu verwalten. Diese Struktur ist, wenn es um Flächen geht, schon vorhanden, sie heißt Multipolygon. nein, ein Multipolygon hat nichts damit zu tun, wie detailliert oder grob die Daten sind. Sie ist in diesem Kontext nur eine etwas elegantere Methode, überlappende Ways zu vermeiden und dafür einen einzelnen Way mehrfach zu verwenden (weiterhin ermöglichen sie, mehrere Flächen als eine zu definieren und Flächen abzuziehen). Sie wird bereits mal dort und mal da in begrenztem Kontext eingesetzt, sie aber als /das/ verbindende Element zwischen MICRO- und MACROmapping Welten zu begreifen, fehlt. weil das damit auch nichts zu tun hat. M.E. sollten wir uns auf das Micro konzentrieren, da das Macro sich aus dem Micro errechnen lässt. Eine konsequente MP-Verwendung ist z.B. bei den politischen Grenzen, sprich polit. Flächen zu erkennen - da werden Teile von Teilen von Teilen gemappt und ihre Beziehungen untereinander eben auch. die Beziehungen ergeben sich aus den tags (admin_level) in Kombination mit der räumlichen Konfiguration. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 29.09.2011 17:26, schrieb Martin Koppenhoefer: wenn wir einzelne Pflastersteine mappen würden, dann klar ja. Wenn man die Pflasterung mappt gehört Sand und Stein zusammen. Was, wenn ein anderer Mapper das anders sieht? Was, wenn jemand Sand und Stein getrennt mappen möchte? Aber die wenigsten würden auf die Idee kommen, den Grasstreifen daneben absichtlich auch noch miteinzuschließen. Das kommt darauf an, wovon die wenigsten reden. Wenn sie von der Straße reden und den Grasstreifen als zugehörig empfinden, schließen sie den absichtlich mit ein - wo Grenzen liegen, legt die Abstraktionsebene des Wortes fest, dass Du verwendest, um ein Ding der Realität zu identifizieren. Und je weiter sich die Abstraktion vom Sandkorn entfernt, desto schwieriger wird es, sich über das gleiche zu unterhalten - es ist nicht klar, ob der Grasstreifen daneben mit einzuschließen ist, oder nicht, nur weil /Du/ eine eigene Auffassung dazu hast. Für /Dich/ ist es klar und wenn Du daheim an deinem eigenen kleinen Abbild der Realität bastelst, würde es auch niemanden interessieren, ob deine Auffassung zur Auffassung eines anderen passt. OSM = viele Auffassungen. Die Zähflüssigkeit mit der auch nur ein einziger Konsens gefunden wird, demonstriert Dir, wieviele tatsächlich auf die Idee kommen würden, den Grasstreifen daneben mit einzuschließen. Die Frage muss sein, welchen Sachverhalt der Realität man abbilden möchte. Will ich den Sachverhalt, dass ein Wald an die Straße grenzt (was nur eine grobe Aussage zur Lagebeziehung ist, und immer sein wird, aber das kann ich eben modellieren) wie schon erläutert ist das durch die Lage bereits klar (Stichwort Geodatenbank). Wie schon erläutert, täuschst Du dich da. Geometrische Lage und Topologie sind nunmal verschiedene Dinge und wenn Du letzteres aus ersterem Ableiten möchtest, musst Du rechnen und brauchst Regeln, teils sehr aufwendige. Das führt uns wieder zu deiner ureignen Auffassung der Siedlungsfläche - dem einzigen Ding, dass Du nicht feingranular erfassen willst, weil man es nicht automatisch zusammenrechnen kann. Was Dich aber nicht davon abhielt, zu behaupten, alles andere sei einfach zusammenfassen. Wenn Du den Wald an seiner Grenze erfasst hast und feststellen willst, ob eine Straße innerhalb der nächsten 50 m ist, dann musst Du nur die Ausdehnung des Walds um 50 m erweitern (in Deiner Abfrage, nicht in der OSM-Datenbank) und sehen, ob sich Straßen darin befinden. Wenn Dich auch Straßen interessieren, die innerhalb von 30 oder 100 m liegen, dann kannst Du auch das abfragen: Du entscheidest selbst, bis zu welchem Abstand die Straße noch am Wald läuft. Ja, super und dabei kommt dann totaler Müll raus: Einmal verschiebe ich dann eine Grenze, die auf dem Weg liegt, ein andern Mal eine Grenze die daneben liegt. Sorry, wenn sich im ersten Schritt nicht darauf geeinigt wurde, /wie/ ein Sachverhalt der Realität abzubilden ist, kann ich den Fehler nicht damit korrigieren, dass ich ein /offset/ benutze. Ein Datenbrei lässt sich mit einem /offset/ nunmal nicht verbessern. Damit wird nur verschoben, was ursprünglich schon zusammengemanscht wurde - bei der Erfassung, durch die vielen unterschiedlichen Auffassungen von MapperInnen, durch unklare Dokumentation im Wiki, etc.. Ich kann nicht, in der Phase der Auswertung, höhere Genauigkeit from nowhere erzeugen, als das, was in den Ausgangsdaten steckt. .. schon längst einen workaround (highway=residential) geschaffen. workaround - Du sagst es. oder möchte ich den Sachverhalt ausdrücken, dass zwischen etwas und etwas anderem immer noch ein drittes etwas ist (das ist Leibniz - egal wie klein der Raum wird, ich kann ihn immer nochmal in zwei Teile teilen). Letzteres können wir mit OSM nicht modellieren, da wir dazu unbegrenzte Genauigkeit bräuchten, eine Grenze zu erfassen - die haben wir nicht. das stimmt so nicht: wenn klar ist, was alles zu einem bestimmten Flächentyp gehört Das ist NIE klar, weil auch deine Defintion immer eine begrenzt genaue, oder bewußt ungenaue ist. Z.B. durch Worte überwiegend, vorrangig, grob, in etwa oder auch Straße, Wald, etc. das sind nunmal alles begrenzt genaue Begriffe. Und alle Versuche das penibel genau zu spezifizieren, enden in einem Haufen, den Du immer größer machst - jedes Mal, wenn jemand mit einem aber ankommt. Du kannst keine sinnvolle Granularität festlegen, mit der jeder glücklich ist - zeigen Dir das nicht mittlerweile die Jahre deiner Beharrlichkeit und der Fakt, dass nicht jeder auf der Granularität mappt, auf der Du mappst? Was Du machen kannst, ist den Leuten eine Struktur an die Hand zu geben, die nach oben und nach unten (granularity-wise) funktioniert, _ohne_ selbst zu wissen, wo die Granularität liegt, die jemand (Joe mapper) mit einer Instanz dieser Struktur erzeugt. , (s. oben Pflasterung vs einzelne Pflastersteine), dann kann man nicht immer noch etwas erfinden, was dazwischen
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 29. September 2011 20:46 schrieb Christian Müller cmu...@gmx.de: Am 29.09.2011 17:26, schrieb Martin Koppenhoefer: Und würdest Du nicht auch zustimmen, dass ein 'outer' ein gröberes Gebiet umreißt, als seine 'inners'? Und das 'inners' von 'inners' eines outer noch fein granularer sind? Nein, dem würde ich nicht zustimmen. die Beziehungen ergeben sich aus den tags (admin_level) in Kombination mit der räumlichen Konfiguration. Das ist nur zum Teil richtig. Die Beziehungen ergeben sich schon daraus, dass eine Flächengrenze für jedes admin_level wiederverwendet wird, wenn da mehrere drüber laufen. admin_level ist eigentlich eine redundante Information -1 - die Bundesgrenze z.B. wäre genauso gut dadurch ermittelbar, dass ihre Flächengrenzen X-fach wiederverwendet werden (wobei Bundeslandgrenzen im inneren nur (X-1)-fach wiederverwendet werden, usw.) admin_level ist genau das, was Du sonst ablehnst: Etwas, dass man einfach errechnen könnte. -1, wenn es überall gleich viele admin_levels geben würde und alles erfasst ist, und es keine Ausnahmen wir Enklaven gäbe, dann stimmte das vielleicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 29.09.2011 21:05, schrieb Martin Koppenhoefer: Am 29. September 2011 20:46 schrieb Christian Müllercmu...@gmx.de: Am 29.09.2011 17:26, schrieb Martin Koppenhoefer: Und würdest Du nicht auch zustimmen, dass ein 'outer' ein gröberes Gebiet umreißt, als seine 'inners'? Und das 'inners' von 'inners' eines outer noch fein granularer sind? Nein, dem würde ich nicht zustimmen. Natürlich nicht, schon aus Prinzip nicht .. dass ihre Flächengrenzen X-fach wiederverwendet werden (wobei Bundeslandgrenzen im inneren nur (X-1)-fach wiederverwendet werden, usw.) admin_level ist genau das, was Du sonst ablehnst: Etwas, dass man einfach errechnen könnte. -1, wenn es überall gleich viele admin_levels geben würde und alles erfasst ist, und es keine Ausnahmen wir Enklaven gäbe, dann stimmte das vielleicht. Wenn die Enklaven als inners erfasst sind, stimmt es vollständig - und der Erfassungsstand der Gemeindegrenzen ist sehr gut. .. UND das war die Vorraussetzung, die Du für deine Bodennutzung auf einer sehr feinen Granularität auch getroffen hast: Das überall alles gleichmäßig erfasst ist .. Weil aber der Erfassungsstand nicht überall gleich ist, erfasst man die Beziehung, anstatt sie zu errechnen.. Bei admin_levels, bei unterschiedlichen Granularitäten der Bodennutzung, usw. und so fort. Noch klarer kann ich es Dir nicht machen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 03:57 schrieb Christian Müller cmu...@gmx.de: Ein Wald endet an der Straßenfläche oder dem Ufer eines Flusses! ggf. kann das so sein Wenn die Straßenfläche in OSM durch eine Linie repräsentiert wird, und es zudem nicht gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird wer entscheidet, dass das nicht gewünscht ist? Manche Mapper machen das ja jetzt schon, hier und auf anderen Listen wurde jedenfalls schon öfters darüber diskutiert und es gibt durchaus eine Gruppe von Leuten, die gerne auch Straßenflächen zumindest stellenweise mappen wollen. , /dann/ ist es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu identifizieren. Man könnte auch argumentieren, dass dort in der Karte noch Flächen fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress und nie eine endgültige Situation. All das ändert nichts daran, dass an jeder Flächengrenze mindestens zwei Flächen teilnehmen (von überlappenden Flächen, Enklaven, einmal abgesehen). und auch abgesehen von fehlenden Flächen, die vorübergehend dazu führen können, dass eine Fläche auch mal nirgends angeschlossen werden kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 05:36 schrieb Christian Müller cmu...@gmx.de: Am 27.09.2011 11:49, schrieb Martin Koppenhoefer: Weshalb diskutieren wir darüber eigentlich - einen closed way derselben Länge / desselben Detailgrads müsste schließlich auch in den Editor geladen werden, um ihn zu bearbeiten - das wiederum _immer_ komplett. Ich sehe hier den Bezug nicht, den Du zum aktuellen Thema herstellen möchtest. wenn wir von einer Nachricht zur nächsten den Bezug vergessen bringt die Diskussion wirklich nichts. Der Bezug war: im Zweifel lieber fragmentieren als zusammenfassen. Eine weitere Frage ist, ob, wenn es solche Monster gibt, nicht schon vorher etwas falsch gelaufen ist.. Schließlich müssen sie ja erstmal da sein, bevor ich sie auseinandersplitte. ganz genau Von Mythen war bei mir keine Rede, schau einfach mal nach Japan in die Wälder und versuche, einen der Riesenwälder in kleinere Stücke zu teilen. Link? Ich habe mal ein enorm großes Waldstück geteilt, welches basisgeometrisch erfasst war - ich kann nicht behaupten, dass das einfacher war. Wenn Du Dich dort betätigen willst, da wären Dir vermutlich einige dankbar, im Prinzip ist wohl ganz Japan betroffen, ein Beispiel ist glaube ich hier: http://www.openstreetmap.org/?lat=35.104lon=134.106zoom=10layers=M Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund eines Konfliktes? das verstehe ich nun nicht Es wäre vielleicht besser, die (echten) Probleme mit Multipolygonen beim Namen zu nennen. Das Konzept /Multipolygon/ ist gut, die Editorumsetzung dürftig. Warum schließt Du dich dieser Sichtweise nicht einfach an, wenn es in deiner Gegend ohnehin schon usus ist, sie zu benutzen? wie bereits verschiedentlich erwähnt bin ich kein Gegner der Multipolygone --- im Gegenteil nutze ich sie fast täglich. Ich hatte lediglich einen Hinweis angebracht, dass man aufpassen sollte, diese nicht zu groß und komplex werden zu lassen, weil sonst a) die Bearbeitung schwierig und langwierig wird b) im Laufe der Zeit unzählige Versionen der Relation entstehen, weil jede kleine Änderung eine neue Version entstehen lässt c) das Rendern und andere Weiterverarbeitung unnötig aufwändig werden Lieber fragmentieren als zusammenfassen war dazu die Empfehlung. Je größer und gröber man das anfängliche Polygon macht, um so komplexer wird tendenziell (je nach Kontext) das entstehende Multipolygon-objekt im Laufe der Zeit. Ich habe das hier verschiedentlich beobachtet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 00:33 schrieb Garry GarryD2@gmx. Multipolygone führen dazu dass ähnliche Flächengrenzen zusammengefasst werden damit es übersichtlich aussieht (weil nur noch eine statt viele Linie im Editor zu sehen ist) aber in Wahrheit die realen Flächengrenzen verfälscht. Ein Wald endet nicht an der Mittellinie einer Strasse oder eines Flusses! Das ist Quatsch und das weißt du vermutlich auch selbst. Die Benutzung von Multipolygonen und das zusammenlegen von Flächengrenzen und Linienobjekten (Straßen,...) sind zwei verschiedene Dinge. Es gibt genügend Mapper, die auch “normale“ Flächen an Straßen etc. anpappen - diejenigen, die dies ablehnen (wie ich) werden wohl auch bei der Nutzung von MPs nicht plötzlich damit anfangen. Diese Frage taugt also nicht als Argument gegen MPs. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 11:31, schrieb Martin Simon: Die Benutzung von Multipolygonen und das zusammenlegen von Flächengrenzen und Linienobjekten (Straßen,...) sind zwei verschiedene Dinge. +1 full ack. Evtl. lässt sich das sogar erweitern: Das Zusammenlegen von Flächengrenzen zum einen Flächengrenzen mit Linienobjekten zum anderen sind auch verschiedene Dinge - über die sich auch getrennt reden lässt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Martin, Am 28.09.2011 10:45, schrieb Martin Koppenhoefer: wenn wir von einer Nachricht zur nächsten den Bezug vergessen bringt die Diskussion wirklich nichts. Der Bezug war: im Zweifel lieber fragmentieren als zusammenfassen.(*) lecker. Ich weiß nicht, ob die Möglichkeit, bestimmte Bezüge nicht herstellen zu können, rechtfertigt, anderen das Vergessen vorzuwerfen. Es macht keinen Sinn, im Kontext dieser (*)-Regel, von einem Unterschied zwischen MP und closed ways zu sprechen, denn sie passt durchaus auf beide dieser Arten, Flächen zu erfassen. MP bilden da /keine/ Ausnahme. Deshalb habe ich die Frage gestellt, weshalb Du (*) überhaupt als Argument bringst - es ist kein Argument für oder gegen eine bestimmte Mappingpraxis, wenn alle Praxen Möglichkeiten der Fragmentierung bieten. closed way-Flächen können bel. fragmentiert werden, man zerreißt dabei i.d.R. das Original. MP-Flächen können fragmentiert werden, ohne das Original zu zerreißen, sie fragmentieren UND fassen zusammen. Ein Argument gegen MP-Flächen ist, dass solche MP, die sehr viele Flächengrenzen zu einer Fläche zusammenfassen, so groß werden können, dass .. sie nicht mehr handhabbar sind. .. und deshalb sollte man sie nicht nutzen.. Erstens trifft das nur für MPs zu, die größer sind als ihr closed way-Pendant (die also schon zusammenfassen..) und zweitens bedeutet die Möglichkeit, dass man zusammenfassen /kann/, nicht, dass man zusammenfassen /muss/. Drittens /ist/ die Nicht-Verwaltbarkeit von wirklich umfangreichen MPs hauptsächlich ein usability-Problem, dass sich u.a. schon dadurch lösen lässt, dass umfangreiche MP in Kind-Relationen ausgelagert werden können. Z.B. durch Gruppierung der 10.000+ outer ways in Kind-Relationen, die dann als 'outer' an einer Eltern-Relation teilnehmen. Die /Möglichkeit/ mit MPs komplexe Flächen mit 10.000+ Grenzsegmenten zu bilden, bietet Lösungen für Probleme, welche mit closed ways überhaupt nicht, oder mindestens genauso schwer, zu lösen sind. Weshalb sollte man also closed ways, welche in solchen Grenzbereichen ebenso versagen, in ein besseres Licht rücken, als MPs, die zwar die /Möglichkeit/ bieten, in solche Bereiche vorzudringen, aber erst dort schwer zu handhaben sind? Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Du schriebst: Beim Splitten eines ways, entsteht eine neue Version des kompletten Multipolygons. /So/ entstünden schnell /Unmengen/ an Versionen von riesigen Objekten. Ich schrieb: /Dies/ ist ein usability Problem. /Das/ /Unmengen/ von Objekten erzeugt werden, liegt doch nicht am Datenmodell - dieses zwingt den Programmierer deines Editors mitnichten, jedes Mal eine neue Version eines MP zu erzeugen, wenn ein way member gesplittet wird. Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund eines Konfliktes? das verstehe ich nun nicht Manchmal in JOSM, und das betrachte ich pers. auch als Krankheit, kannst Du eine Relation mit dem Rel.-Dialog öffnen. Du kannst dort lustig ways hinzufügen und entfernen. Da dieser Dialog natürlich nicht modal arbeitet, kannst Du im MapView, während der Dialog noch geöffnet ist, die Basisgeometrien ändern, sprich ways splitten oder löschen, die an der Relation teilnehmen. Da das ganze Prozedere nicht synchronisiert stattfindet, kann, wenn der Relationen-Dialog geschlossen wird, dieser eine andere Version der Relation vorhalten, als das im Editor geladene Dataset - Konflikt wird erzeugt. Üblicherweise verschwindet aber nach Lösung des Konflikts die ungewünschte Version der Relation wieder. Evtl. könnte der Relationen-Dialog selbst Observer des DataSets sein, um das zu vermeiden. Aber dies und das Erzeugen von Unmengen neuer Versionen in einem Editor sind für mich editor-spezifische Details. ... dass man aufpassen sollte, diese nicht zu groß und komplex werden zu lassen, weil sonst a) die Bearbeitung schwierig und langwierig wird +/- 1 Das ist momentan evtl. richtig, je nach tatsächlicher Komplexität. Dies trifft aber z.T. auch auf riesige closed ways und dergleichen zu. Das ist, in beiden Fällen, zunächst ein usability-Problem, welches sich mit MPs einfacher lösen lässt, als mit closed ways - letztere lassen sich im Editor nicht getrennt laden (obwohl das denkbar ist, schließlich ist ein Weg auch nur eine Knotenliste, welche sich als Relation interpretieren lässt). b) im Laufe der Zeit unzählige Versionen der Relation entstehen, weil jede kleine Änderung eine neue Version entstehen lässt Das verstehe ich nach wie vor nicht, und
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 10:26, schrieb Martin Koppenhoefer:
.. und es zudem nicht
gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird
wer entscheidet, dass das nicht gewünscht ist?
ich nicht, deshalb habe ich dazu keine Aussage getroffen. vielleicht
Joe Mapper ;-)
Wenn die Datenlage gut ist (Luftbilder), würde ich das auch gutheißen.
Nur ist da natürlich wieder auszudiskutieren, /wie/ - Konsens fürs
tagging usw. muss gefunden werden - Garry sprach schon an, welches
Verwechslungspotenziale bestehen: Verkehrsfläche vs. Gesamtfläche der
Straße (mit Entwässerungsanlagen, Schallschutzbauten, etc.)..
Wenn die entsprechende landuse=road Seite im Wiki nach aktuellem
Wissensstand (des Projekts) erklärt, was genau damit gemappt werden
soll, ist schonmal viel getan - ansonsten wird das Tag irgendwann so
unklar verwendet, wie landuse=residential (eine neblige Sammlung der
Verständnisse und Interpretationen aus verschiedenen Themenbereichen und
Kontexten, nicht nur notwendigerweise auf die Bodennutzung Bezug nehmend).
, /dann/ ist
es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu
identifizieren.
Man könnte auch argumentieren, dass dort in der Karte noch Flächen
fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und
daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an
seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche
oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress
und nie eine endgültige Situation.
+1 full ack. Gerade deswegen fand und finde ich es unsinnig, immer und
überall Platz zu lassen - wenn jemand später mehr Detail ergänzen
möchte, wird der sich nicht daran stören, dass da schon etwas
(ungenaueres) ist. /Wie/ er dann sein Detail ergänzt, ist seiner
eigenen Einschätzung überlassen ( werden die Grenzen des groben Gebiets
verschoben und eine neues erzeugt ('outer'-Rolle)? oder wird sein
Detail /als Teil/ eines der vorhandenen, groben Gebiete erfasst
('inner'-Rolle)? )..
All das ändert nichts daran, dass an jeder Flächengrenze mindestens zwei
Flächen teilnehmen (von überlappenden Flächen, Enklaven, einmal abgesehen).
[..] abgesehen von fehlenden Flächen, die vorübergehend dazu
führen können, dass eine Fläche auch mal nirgends angeschlossen werden
kann.
+1
Gruß,
Christian
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 16:19 schrieb Christian Müller cmu...@gmx.de: Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Ich schrieb: /Dies/ ist ein usability Problem. /Das/ /Unmengen/ von Objekten erzeugt werden, liegt doch nicht am Datenmodell - dieses zwingt den Programmierer deines Editors mitnichten, jedes Mal eine neue Version eines MP zu erzeugen, wenn ein way member gesplittet wird. nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht bereits beim Splitten im Editor). Manchmal in JOSM, und das betrachte ich pers. auch als Krankheit, kannst Du eine Relation mit dem Rel.-Dialog öffnen. Du kannst dort lustig ways hinzufügen und entfernen. Da dieser Dialog natürlich nicht modal arbeitet, kannst Du im MapView, während der Dialog noch geöffnet ist, die Basisgeometrien ändern, sprich ways splitten oder löschen, die an der Relation teilnehmen. ach so, das meinst Du. Das ist in der Tat eher ein Editor-Problem (evtl. könnte der Editor Änderungen in der Karte in den Fenstern der geöffneten Relationen jeweils live nachführen). Konflikte durch parallele Edits (verschiedener Mapper) entstehen allerdings auch (weiterer Punkt) um so eher, je ausgedehnter ein Objekt ist. c) das Rendern und andere Weiterverarbeitung unnötig aufwändig werden Aberglaube. Es ist ein anderer Aufwand, nicht mehr oder weniger unnötig als der, den man ohne MP betreibt. IIRC werden MPs z.B. von Renderern ohne zu Murren gehandhabt. Zudem ist es möglich, simple Tools zu schreiben, welche Dir Multipolygone in closed ways konvertieren - probiere das mal anders herum. Bestimmte Arten der Weiterverarbeitung profitieren durch MP. ich meine nicht beim Importieren des MP in den Editor. Wenn ein Wald sich über 2500 km² hinzieht, mit allen kleinen Lichtungen und anderen inner ways, dann musst Du beim Rendern das komplette Monster in jedem einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen bzw. kleinere Versionen, schneller zu rendern, weniger potentielle Konflikte). Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann, aber wenn man von vornherein riesige Flächen erzeugt ist es sehr wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon was rausschneidet. Je mehr das machen, um so eher wird das ein Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance größer, dass der nächste Mapper so weitermacht und irgendwann aus diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil von vornherein kaum Vergröberung drin ist). Mit Deinem Plädoyer für Multipolygone bei Grenzen rennst Du offene Türen ein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Martin, Am 28.09.2011 19:40, schrieb Martin Koppenhoefer: nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht bereits beim Splitten im Editor). Ah, ok - Du beziehst Dich in der Tat auf den Versionszähler /eines/ Multipolygons und nicht darauf, dass /mehrere/ Multipolygone entstehen - das kam in der ursprünglichen mail nicht so rüber - meine Frage an Dich muss also anders lauten: Wo liegt für Dich das Problem, wenn der Versionsstand eines Multipolygons bei 249.000 steht? Schließlich beschäftigen wir uns beim Editieren eigentlich nur mit dem aktuellen Stand. Und beim Editieren ohne MP entstehen schließlich auch Unmengen an Versionsständen (z.B. von ways oder nodes). , dann musst Du beim Rendern das komplette Monster in jedem einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen bzw. kleinere Versionen, schneller zu rendern, weniger potentielle Konflikte). Folgen wir dieser Argumentation, ohne zu Betrachten, wie 'teuer' die Beantwortung der Inklusionsfrage von Z18-Tiles bezüglich MP-Monstern wirklich ist. Das einzige, was Du dann erreichst, ist, dass die Renderzeit für Kacheln auf hoher Zoomstufe sinkt, auf niedriger aber enorm steigt. Was wir aber eigentlich wollen, ist das beides vernünftig läuft. Also MP-Monster für niedrige Zoomstufen, und normale MPs als inners von inners von inners (..) vom MP-Monster. Es ist nicht ganz wahr, dass für jede Z18-Kachel das ganze Monster jedes Mal von neuem betrachtet wird - Du musst für die meisten Kacheln nur wissen, ob sie innerhalb oder außerhalb des Monsters liegen. Das wird im Zusammenhang mit ein paar Rechteck-Bäumen als cachende Datenstruktur für die Bounding-Boxes dieser Monster i.d.R. vernachlässigbar. Dazu unten mehr. Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann, aber wenn man von vornherein riesige Flächen erzeugt ist es sehr wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon was rausschneidet. Je mehr das machen, um so eher wird das ein Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance größer, dass der nächste Mapper so weitermacht und irgendwann aus diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil von vornherein kaum Vergröberung drin ist). Auf welchem Zoomlevel entsteht denn da ein Bild? Auf einem ganz bestimmten.. Es ist nicht immer auf einfache Weise möglich, per render-regel ein microgemapptes Gebiet sinnvoll auch für niedrigeren Zoom zu erzeugen. Ich sehe das, mal nur für die Renderinggeschichte, so: Wenn es einen 2500 km² großes Multipolygon als Wald gibt und eine Kachel für niedrigen Zoom gerendert werden soll, dann reicht es ggf. aus (hängt vom Zoom ab), nur den outer-way zu betrachten, und die 'inner' zu ignorieren. Das heißt, ich muss mir dieses Waldgebiet nicht erst zusammenbauen, bzw. mehrere Fetzen davon rendern, im Falle dass es an jeder Straße aufgetrennt vorliegt (evtl. werden ja auch manche Straßen auf einem niedrigen Zoom nicht angezeigt). Mehrere Fetzen auf einem niedrigen Zoom zu rendern ist aufwendiger, als den großen Batzen zu rendern: weil dann alle innenliegenden Grenzen mitberechnet werden müssen, nicht nur die wichtige, entscheidende, außen umliegende Grenze des Gebietes. Umgekehrt, wenn wir uns auf Z18 befinden, und das Tile liegt komplett innerhalb eines Polygons, dann ist auch nur dieses kleinste umliegende MP für eine Färbung interessant. Für den Fall, dass die kleineren Strukturen des großen Waldgebietes als 'inner's und 'inner's von 'inner's gemappt sind, muss also für das Z18-Tile nicht der große Batzen betrachtet werden. Angenommen das kleinste umliegende MP ist aber dieses 2500 km² Waldgebiet, dann stellt sich für die meisten Z18-Tiles nur die Frage, ob sie innerhalb oder außerhalb der Fläche liegen. Dieses Problem hast Du sowohl mit einem closed way, als auch mit einem MP und die Inklusionsfrage ist mittels gecachten bounding-boxen des MP in annehmbarer Zeit lösbar. Dein Ansatz, nach bottom-up Manier erst kleine Gebiete zu erfassen, ist in der Praxis gerade für große, unbesiedelte Gebiete nicht brauchbar - da existieren oft nur grobe Satfotos mittels derer man grob ein riesiges Gebiet erfassen kann - und das ist besser als gar nichts, bzw. besser, als darauf zu warten, dass in 10 Jahren dasselbe Gebiet auf Z16 detailiert erfasst ist. Das wir beide zusammenbringen können (den, der von unten auf Z16 mappt, und den, der mittels Grobfoto auf Z8 mappt) verdanken wir der Schachtelungsmöglichkeit von MPs. Die Frage also, ob Du für ein Z18-Tile ein MP-Monster (sehr grobe Daten), ein normales MP (detailierte Daten) oder
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 16:38, schrieb Christian Müller:
Am 28.09.2011 10:26, schrieb Martin Koppenhoefer:
.. und es zudem nicht
gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird
wer entscheidet, dass das nicht gewünscht ist?
ich nicht, deshalb habe ich dazu keine Aussage getroffen. vielleicht
Joe Mapper ;-)
Wenn die Datenlage gut ist (Luftbilder), würde ich das auch
gutheißen. Nur ist da natürlich wieder auszudiskutieren, /wie/ -
Konsens fürs tagging usw. muss gefunden werden - Garry sprach schon
an, welches Verwechslungspotenziale bestehen: Verkehrsfläche vs.
Gesamtfläche der Straße (mit Entwässerungsanlagen, Schallschutzbauten,
etc.)..
Wenn die entsprechende landuse=road Seite im Wiki nach aktuellem
Wissensstand (des Projekts) erklärt, was genau damit gemappt werden
soll, ist schonmal viel getan - ansonsten wird das Tag irgendwann so
unklar verwendet, wie landuse=residential (eine neblige Sammlung der
Verständnisse und Interpretationen aus verschiedenen Themenbereichen
und Kontexten, nicht nur notwendigerweise auf die Bodennutzung Bezug
nehmend).
So einfach ist das leider nicht. Mein Standpunkt ist das die
highway-ways in erster Linie Routingdaten sind die nichts direkt mit
Flächendaten zu tun haben -
mit der wesentlichen Aussage dass (landuse-)Flächen nicht mit highways,
sondern nur mit den Flächendaten der Strasse
(also dann highway= road)verknüpft werden dürfen.
, /dann/ ist
es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu
identifizieren.
Man könnte auch argumentieren, dass dort in der Karte noch Flächen
fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und
daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an
seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche
oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress
und nie eine endgültige Situation.
+1 full ack. Gerade deswegen fand und finde ich es unsinnig, immer
und überall Platz zu lassen - wenn jemand später mehr Detail ergänzen
möchte, wird der sich nicht daran stören, dass da schon etwas
(ungenaueres) ist. /Wie/ er dann sein Detail ergänzt, ist seiner
eigenen Einschätzung überlassen ( werden die Grenzen des groben
Gebiets verschoben und eine neues erzeugt ('outer'-Rolle)? oder wird
sein Detail /als Teil/ eines der vorhandenen, groben Gebiete erfasst
('inner'-Rolle)? )..
Genau das ist der Punkt.
Wenn ich etwas ergänzen/die Genauigkeit verbessern möchte dann sollte
das dadurch möglich sein dass ich vorhandenes idealerweise einfach
nur etwas zurechtrücken muss ohne in eine Struktur einzugreifen mit der
ich mich erst intensiv auseinandersetzen muss, einen komplexen Editor
benötige
und einen grösseren Schaden durch kleine Fehler anrichten kann.
D.h. eine Detailverbesserung an Flächen und Linien muss mit
Basisoperationen möglich sein ohne dass im Hintergrund ein komplexes
Programm arbeitet
das tausende von Überprüfungen vornehmen muss um sicherzustellen dass
ich nicht irgendwelche Daten zerstöre die ich übehaupt nicht bearbeiten
möchte.
Z.B. wenn ich eine Waldgebiet bearbeite möchte ich nicht einen Jakobsweg
zerstören, mich aber auch nicht damit befassen nur weil dessen Verlauf
nach einer groben Annäherung mit der Kante einer Waldgrenze gekoppelt
wurde. Hier entsteht also ein Konflikt durch Kopplung der Daten wenn ich
nur genaue Walddaten
oder nur genaue Jakobswegdaten habe. Wenn ich nur eins von beidem habe
kann ich nichs an den Daten verbessern weil ich nicht garantieren kann
dass ich den anderen Teil der Daten dadurch nicht verschlechtere.
Garry
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 26. September 2011 22:13 schrieb Christian Müller cmu...@gmx.de: Am 23.09.2011 13:01, schrieb Martin Koppenhoefer: Nicht, dass ich Multipolygon-relationen nicht auch sinnvoll finde und sie so oft es Sinn macht auch anlege und nutze, aber je größer man die anfangs grob gezeichneten Gebiete (z.B. Wälder) anlegt, um so größer ist die Chance, dass 100 Versionen später daraus unübersichtliche Monster geworden sind, die Otto-Normal-Mapper überhaupt nicht mehr anfasst (die brauchen schon einige Minuten bis sie überhaupt in den Editor geladen sind, und dieser wird dann u.U. so langsam, dass man nicht mehr vernünftig arbeiten kann). Von welchem Editor sprichst Du denn? JOSM geht mit so etwas effizienter um, als mit closed- bzw. overlapping ways. Damit Du ein Multipolygon sinnvoll aufteilen kannst, musst Du es zuallererst mal in den Editor laden. Alleine das dauert schon ewig bei sehr großen Mulitpolygonen. Ab einer gewissen Größe (wie Frederik treffend beschrieben hat) geht es praktisch gar nicht mehr (weil der Editor zu langsam wird). Und: Du trägst nicht gerade zur Verbreitung von Multipolys bei, indem Du Monster und Mythen kreirst, damit sie in dem unrecht schwachen Licht stehen bleiben, welches sie derzeit karg beleuchtet.. Von Mythen war bei mir keine Rede, schau einfach mal nach Japan in die Wälder und versuche, einen der Riesenwälder in kleinere Stücke zu teilen. Auch bei der Datenverarbeitung sind diese Monster extrem ungünstig (s. Japan), weil man z.B. für die kleinste Render-Kachel immer gleich einen riesigen Bereich (zig-tausende von Nodes) betrachten muss. Wenn man dagegen von vornherein nach der Maxime im Zweifel lieber fragmentieren als zusammenfassen arbeitet, ist das für die kommende Entwicklung gesünder. Ja, klar.. Weil lieber fragmentieren als zusammenfassen != zig-tausende Nodes. Klingt nicht gerade überzeugend. Ich erkläre es nochmal langsam: Milliarden Nodes haben wir sowieso in der Datenbank. Ein Problem wird es dann, wenn sehr viele Nodes alle zu einem Objekt gehören (weil um dieses zu bearbeiten, zumindest für manche Bearbeitungen wie Teilungen, alle geladen werden sollten). Solange die Nodes alle in verschiedenen kleineren Objekten liegen ist das kein Problem: man bearbeitet einfach lokal das kleine Stück, das gerade im Editor liegt, und braucht sich um den Rest, der entfernt in einem anderen Objekt liegt, nicht scheren. Ein Gebiet, welches sauber mittels multipolys gemappt ist, ist datenverarbeitungstechnisch einfacher zu handhaben und vor allem auf wesentlich vielfältigere Art und Weise, als das jetzt der Fall ist. Als das jetzt der Fall ist? In meiner Umgebung gibt es sehr viele Multipolygone, wo bist Du denn, dass das alles überlappende Ways sind? Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. Außerdem, ungleich deiner auf Unkenntnis beruhenden Behauptung, dürften multipolygon-gemappte Gebiete klar Nodes einsparen, anstatt, wie von Dir behauptet zig-tausende zu produzieren. Du könntest mal wieder ein bisschen Gas rausnehmen aus Deinem Schreibstil. Diese permanente Besserwisserei nervt ein bisschen. Ich habe nie geschrieben, dass man mit Multipolygonen mehr Nodes produzieren würde, und darum geht es mir auch nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 26.09.2011 22:13, schrieb Christian Müller: Hi, Am 23.09.2011 13:01, schrieb Martin Koppenhoefer: Nicht, dass ich Multipolygon-relationen nicht auch sinnvoll finde und sie so oft es Sinn macht auch anlege und nutze, aber je größer man die anfangs grob gezeichneten Gebiete (z.B. Wälder) anlegt, um so größer ist die Chance, dass 100 Versionen später daraus unübersichtliche Monster geworden sind, die Otto-Normal-Mapper überhaupt nicht mehr anfasst (die brauchen schon einige Minuten bis sie überhaupt in den Editor geladen sind, und dieser wird dann u.U. so langsam, dass man nicht mehr vernünftig arbeiten kann). Von welchem Editor sprichst Du denn? JOSM geht mit so etwas effizienter um, als mit closed- bzw. overlapping ways. Und: Du trägst nicht gerade zur Verbreitung von Multipolys bei, indem Du Monster und Mythen kreirst, damit sie in dem unrecht schwachen Licht stehen bleiben, welches sie derzeit karg beleuchtet.. Zu unrecht? Eigene Erfahrungen und Rückmeldungen von anderen anfangs begeisterten Multipolygonusern sprechen da eine andere Sprache! Ziel sollte doch sein dass in OSM jeder die Daten die ihn interessieren leicht anfassen und verbessern kann und nicht dass es im Editor scheinbar aufgeräumt aussieht weil tausende von Eigenschafte in eine Linie gepackt sind! Multipolygone führen dazu dass ähnliche Flächengrenzen zusammengefasst werden damit es übersichtlich aussieht (weil nur noch eine statt viele Linie im Editor zu sehen ist) aber in Wahrheit die realen Flächengrenzen verfälscht. Ein Wald endet nicht an der Mittellinie einer Strasse oder eines Flusses! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 00:32, schrieb Garry: Ziel sollte doch sein dass in OSM jeder die Daten die ihn interessieren leicht anfassen und verbessern kann +1 und nicht dass es im Editor scheinbar aufgeräumt aussieht weil tausende von Eigenschafte in eine Linie gepackt sind! Das ist ja momentan mit overlapping ways der Fall - und auch ein Grund, warum viele overlapping ways ablehnen - weil im Editor eben nicht unmittelbar ersichtlich, dass da in der Tat mehrere Linien sind. Mit Multipolygon-Relationen sind die Eigenschaften nicht in einer Linie sondern in den Relationen, welche die Linie benutzen. Das Editoren mit Multipolygonen wesentlich besser umgehen könnten, habe ich bereits geschrieben.. Multipolygone führen dazu dass ähnliche Flächengrenzen zusammengefasst werden damit es übersichtlich aussieht (weil nur noch eine statt viele Linie im Editor zu sehen ist) aber in Wahrheit die realen Flächengrenzen verfälscht. Ein Wald endet nicht an der Mittellinie einer Strasse oder eines Flusses! Ich fange hier nicht die Diskussion von vorne an, so wie Du es tun möchtest - /was/ /wo/ endet wurde /ausführlich/ und begründet bereits in den entsprechenden Threads der letzten beiden Monate diskutiert. Ein Wald endet an der Straßenfläche oder dem Ufer eines Flusses! Wenn die Straßenfläche in OSM durch eine Linie repräsentiert wird, und es zudem nicht gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird, /dann/ ist es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu identifizieren. Es gibt einen Unterschied zwischen: Mittellinie einer Straße (in der Realität) Linie der Straße (in OSM) Die Linie der Straße in OSM ist __nicht__ die Mittellinie einer Straße der Realität. In OSM repräsentiert die Linie die Gesamtverkehrsfläche der Straße und nicht irgendeine Straßenmarkierung.. Wenn Dich das stört und es einen Konsens gibt, wie und ob Verkehrsflächen mit landuse= erfasst werden, kannst Du natürlich auch die Verkehrsfläche erfassen. All das ändert nichts daran, dass an jeder Flächengrenze mindestens zwei Flächen teilnehmen (von überlappenden Flächen, Enklaven, einmal abgesehen). Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 27.09.2011 11:49, schrieb Martin Koppenhoefer: Am 26. September 2011 22:13 schrieb Christian Müllercmu...@gmx.de: JOSM geht mit so etwas effizienter um, als mit closed- bzw. overlapping ways. Damit Du ein Multipolygon sinnvoll aufteilen kannst, musst Du es zuallererst mal in den Editor laden. Alleine das dauert schon ewig bei sehr großen Mulitpolygonen. Ab einer gewissen Größe (wie Frederik treffend beschrieben hat) geht es praktisch gar nicht mehr (weil der Editor zu langsam wird). Ich weiß jetzt nicht, ob irgendjemand von euch tatsächlich mappt - aber JOSM geht, ich wiederhole mich, sehr effizient auch mit unvollständigen Relationen um - es lassen sich bestimmte Teile nach belieben Nachladen, ohne dass die Gesamtrelation geladen werden muss. Auch unvollständige Relationen lassen sich bearbeiten, wenn man weiß, was man tut - sie lassen sich dort auseinanderbrechen, wo es relevant erscheint, _ohne_ das gesamte Multipolygon (alle Geometrien) in den Editor geladen zu haben. Weshalb diskutieren wir darüber eigentlich - einen closed way derselben Länge / desselben Detailgrads müsste schließlich auch in den Editor geladen werden, um ihn zu bearbeiten - das wiederum _immer_ komplett. Ich sehe hier den Bezug nicht, den Du zum aktuellen Thema herstellen möchtest. Eine weitere Frage ist, ob, wenn es solche Monster gibt, nicht schon vorher etwas falsch gelaufen ist.. Schließlich müssen sie ja erstmal da sein, bevor ich sie auseinandersplitte. Und: Du trägst nicht gerade zur Verbreitung von Multipolys bei, indem Du Monster und Mythen kreirst, damit sie in dem unrecht schwachen Licht stehen bleiben, welches sie derzeit karg beleuchtet.. Von Mythen war bei mir keine Rede, schau einfach mal nach Japan in die Wälder und versuche, einen der Riesenwälder in kleinere Stücke zu teilen. Link? Ich habe mal ein enorm großes Waldstück geteilt, welches basisgeometrisch erfasst war - ich kann nicht behaupten, dass das einfacher war. Ein Problem wird es dann, wenn sehr viele Nodes alle zu einem Objekt gehören (weil um dieses zu bearbeiten, zumindest für manche Bearbeitungen wie Teilungen, alle geladen werden sollten). Solange die Nodes alle in verschiedenen kleineren Objekten liegen ist das kein Problem: man bearbeitet einfach lokal das kleine Stück, das gerade im Editor liegt, und braucht sich um den Rest, der entfernt in einem anderen Objekt liegt, nicht scheren. Die Erklärung trifft auf irgend etwas zu, auf Monster vielleicht. Das Problem, welches Du beschreibst, gibt es doch mit der Methode, die ich beschrieben habe, überhaupt nicht. Das Multipolygon hat nicht mehr nodes, als ein basisgeometrisch erfasster closed way, was die 'outer'-Elemente betrifft und auch die 'inners' wären ohne das Multipolygon vorhanden. Will ich es jetzt teilen, stellt sich die Frage, wie die 'inner'-Mitglieder (die wieder Relationen sein können) auf die zwei neu entstehenden Multipolygone aufgeteilt werden, mehr nicht. Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. Bei mir (JOSM) entsteht da keine neue Version und ich habe das schon oft genug gemacht. Wenn ein Weg, der zu einem Multipolygon gehört, geteilt wird, wird der neue Weg zum /bestehenden/ Multipolygon addiert (an oder vor der Stelle des alten Weges, der Mitglied bleibt). Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund eines Konfliktes? Du könntest mal wieder ein bisschen Gas rausnehmen aus Deinem Schreibstil. Diese permanente Besserwisserei nervt ein bisschen. dito ;-) Ich habe nie geschrieben, dass man mit Multipolygonen mehr Nodes produzieren würde, und darum geht es mir auch nicht. Es wäre vielleicht besser, die (echten) Probleme mit Multipolygonen beim Namen zu nennen. Das Konzept /Multipolygon/ ist gut, die Editorumsetzung dürftig. Warum schließt Du dich dieser Sichtweise nicht einfach an, wenn es in deiner Gegend ohnehin schon usus ist, sie zu benutzen? Für mich klang es so, als wenn deine Bedenken im Hinblick auf Multipolys modell-technischer und nicht usability-technischer Natur waren. lg Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi, Am 23.09.2011 08:11, schrieb Frederik Ramm: Ich hatte dieses Problem kuerzlich, als ich ein Multipolygon mit 10.000 Ways (insgesamt 450.000 Nodes - Relation 1337942) in kleine Stuecke aufteilen wollte. Das war im Editor nicht mehr zu schaffen, ich musste dafuer extra ein Programm schreiben ;) Wow! Bei langen Radrouten-Relationen wird eine solche Relation dann nochmal unterteilt, z.B.: [D4] Mittelland-Route (545127) Das wäre doch für Multipolygone dieses Ausmaßes auch denkbar, oder? Wenngleich vermutlich Software, welche nicht die Kindrelationen besucht, angepasst werden müsste. http://www.openstreetmap.org/browse/relation/1337942 ist übrigens im Juli gelöscht wurden. Evtl. hat das also jemand schon in kleiner Flächen unterteilt.. Die Beantwortung der Frage, ob sich inner members mit den outers schneiden, ist vermutlich in Validatoren (Editor-intern, oder extern, ähnlich wie beim Relation-Analyzer) am besten aufgehoben. Ich schließe nicht aus, dass es da durchaus Edits geben kann, die ein größeres Multipolygon kaputt machen. Aber die Antwort darauf muss einfach ein so what? bleiben. fixing broken things war vermutlich schon immer ein Bestandteil der Arbeit an OSM. Weshalb sollte das ein Grund sein, sich an schlechte Mapping-Techniken / Datenhaltung zu klammern? Wie wäre es mit einer generellen Debatte darüber, welche Funktionen Editoren brauchen, um die Arbeit mit Multipolygonen zu vereinfachen, bzw. in den generellen Fokus bei Flächenedits zu rücken. Für mich gibt es da eine Sammlung von usability- und workflow- Aspekten. Grob - Trennung von Multipolygonen aus der allg. Relationsliste - Extra-Dialog vs. kein Dialog, je nach Umsetzung - Conversion Handling (Multipolygons Basisgeometrie (overlapping+closed ways)) - splitting a closed way (integrate multipolygon creation) - Selection Handling (make both, multipoly and boundary segment selectable in MapView) - at the moment, selecting the way segment is easy, but selecting the multipoly for tagging is cumbersome - etc. lot's of things I have not thought off Man möge das Gemansche aus dt. und engl. Sprache verzeihen, wenngleich es sich nur auf diese mail bezieht. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi, Am 23.09.2011 13:01, schrieb Martin Koppenhoefer: Nicht, dass ich Multipolygon-relationen nicht auch sinnvoll finde und sie so oft es Sinn macht auch anlege und nutze, aber je größer man die anfangs grob gezeichneten Gebiete (z.B. Wälder) anlegt, um so größer ist die Chance, dass 100 Versionen später daraus unübersichtliche Monster geworden sind, die Otto-Normal-Mapper überhaupt nicht mehr anfasst (die brauchen schon einige Minuten bis sie überhaupt in den Editor geladen sind, und dieser wird dann u.U. so langsam, dass man nicht mehr vernünftig arbeiten kann). Von welchem Editor sprichst Du denn? JOSM geht mit so etwas effizienter um, als mit closed- bzw. overlapping ways. Und: Du trägst nicht gerade zur Verbreitung von Multipolys bei, indem Du Monster und Mythen kreirst, damit sie in dem unrecht schwachen Licht stehen bleiben, welches sie derzeit karg beleuchtet.. Auch bei der Datenverarbeitung sind diese Monster extrem ungünstig (s. Japan), weil man z.B. für die kleinste Render-Kachel immer gleich einen riesigen Bereich (zig-tausende von Nodes) betrachten muss. Wenn man dagegen von vornherein nach der Maxime im Zweifel lieber fragmentieren als zusammenfassen arbeitet, ist das für die kommende Entwicklung gesünder. Ja, klar.. Weil lieber fragmentieren als zusammenfassen != zig-tausende Nodes. Klingt nicht gerade überzeugend. Ein Gebiet, welches sauber mittels multipolys gemappt ist, ist datenverarbeitungstechnisch einfacher zu handhaben und vor allem auf wesentlich vielfältigere Art und Weise, als das jetzt der Fall ist. Außerdem, ungleich deiner auf Unkenntnis beruhenden Behauptung, dürften multipolygon-gemappte Gebiete klar Nodes einsparen, anstatt, wie von Dir behauptet zig-tausende zu produzieren. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hallo, On 09/23/11 01:45, Christian Müller wrote: - Vorteil der Datenhaltung - keine Overlapping Ways - ist eine Fläche noch nicht komplett geladen, braucht man, für JOSM, nur Rechtsklick aufs Multipolygon unvollständige Elemente laden - auch einfache Fälle als multipolygon (die landuse=meadows links) - Für jede Flächengrenze (way) ist sofort ersichtlich /welche/ Flächen geändert werden, wenn die nodes der Flächengrenze verschoben werden - Verschachtelung: ... Finde ich alles gut und richtig so; empfehle ich auch jedem. - Genauso umgekehrt: Der Imnitzer Park ist als Fläche ohne Kinder interpretier- und ladbar In gewissen Grenzen, denn wenn man ihn beispielsweise aufteilen wollte in zwei Haelften oder die Geometrie staerker verformen, muss man aufpassen, dass die inners immer noch vollstaendig innen liegen. Ich hatte dieses Problem kuerzlich, als ich ein Multipolygon mit 10.000 Ways (insgesamt 450.000 Nodes - Relation 1337942) in kleine Stuecke aufteilen wollte. Das war im Editor nicht mehr zu schaffen, ich musste dafuer extra ein Programm schreiben ;) Für mich liegen die Vorteile auf der Hand, und wenn man die Beziehung Flächen - Flächengrenze einmal verstanden hat, ist es auch wesentlich einfacher, so zu editieren, als mit zig tausend ways, overlapping oder nicht, parallel oder nicht.. .. und das betrifft auch Änderungen - oft wird argumentiert, es sei schwerer Gebiete mit viel Beziehungen untereinander zu ändern - dabei ist es wirklich nur anders. Als abschreckendes Beispiel wuerde ich gern das hier zitieren, eine Gegend in Rumaenien, in der ich neulich nur mal schnell eine Selbstueberschneidung reparieren wollte: http://www.remote.org/frederik/tmp/despair.png Komplett ohne Relationen, aber kaum noch bearbeitbar. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 23. September 2011 08:11 schrieb Frederik Ramm frede...@remote.org: Als abschreckendes Beispiel wuerde ich gern das hier zitieren, eine Gegend in Rumaenien, in der ich neulich nur mal schnell eine Selbstueberschneidung reparieren wollte: http://www.remote.org/frederik/tmp/despair.png Komplett ohne Relationen, aber kaum noch bearbeitbar. +1, mit kleineren Einheiten wäre das nicht passiert, wenn man nicht die Flächen bis in die Straßen- bzw. Flussmitte gezogen hätte, etc. wäre das völlig übersichtlich geblieben und Multipolygon-relationen hätte man auch nicht benötigt, z.B. wäre das Industrial im residential, das Du markiert hast, einfach auszusparen, es gibt keinen Grund, warum das residential da weiterhin im Fluss laufen muss. Nicht, dass ich Multipolygon-relationen nicht auch sinnvoll finde und sie so oft es Sinn macht auch anlege und nutze, aber je größer man die anfangs grob gezeichneten Gebiete (z.B. Wälder) anlegt, um so größer ist die Chance, dass 100 Versionen später daraus unübersichtliche Monster geworden sind, die Otto-Normal-Mapper überhaupt nicht mehr anfasst (die brauchen schon einige Minuten bis sie überhaupt in den Editor geladen sind, und dieser wird dann u.U. so langsam, dass man nicht mehr vernünftig arbeiten kann). Auch bei der Datenverarbeitung sind diese Monster extrem ungünstig (s. Japan), weil man z.B. für die kleinste Render-Kachel immer gleich einen riesigen Bereich (zig-tausende von Nodes) betrachten muss. Wenn man dagegen von vornherein nach der Maxime im Zweifel lieber fragmentieren als zusammenfassen arbeitet, ist das für die kommende Entwicklung gesünder. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Martin, um zu sehen, was ich mir so als Ziel vorstelle, kannst Du in JOSM mal den Bereich 12.3168755,51.2102240,12.3196864,51.2111313 laden.. Aber bitte genau diesen, ansonsten ist es schwer zu verstehen, was genau die Vorteile von multipolygons beim Mappen der Bodennutzung sind. Es ist mit JOSM gar nicht sooo schwer, ein bestehendes Gebiet zu konvertieren, mir sind aber auch viele usability Aspekte aufgefallen, die den Weg hin zu multipolygonen erschweren bzw. versperren.. Wie auch immer, das Gebiet soll erstmal nur praktisch illustrieren, wovon ich überhaupt rede.. Was sollte an dem Beispiel zu sehen sein: - Vorteil der Datenhaltung: Beim Laden des Gebietes, erhalte ich nur die Flächengrenzen und nicht mehr gleich _alle_ Flächen, die das Gebiet schneiden. - keine Overlapping Ways: es gibt eine Flächengrenze, klickt man diese an, sieht man, wieviele und welche Flächen sie begrenzt - ist eine Fläche noch nicht komplett geladen, braucht man, für JOSM, nur Rechtsklick aufs Multipolygon unvollständige Elemente laden - auch einfache Fälle als multipolygon (die landuse=meadows links) - Für jede Flächengrenze (way) ist sofort ersichtlich /welche/ Flächen geändert werden, wenn die nodes der Flächengrenze verschoben werden - das ist für overlapping ways oft nicht der Fall, gerade wenn diese auf Wegen außerhalb der bbox entstehen, oder wenn in JOSM Objekte auf der Basis von IDs geladen werden - ich erhalte dann eine komplette Fläche (closed way), ohne evtl. zu sehen, welche Flächen beeinflusst werden, wenn ich einen Knoten verrücke. - Verschachtelung: Die Multipolygon meadows auf der linken Seite nehmen am Imnitzer Park in der Rolle inner Teil, sind aber selbst völlig autark lad- und bearbeitbar. Über die Elternrelation kann aber eine Lagebeziehung zu gröberen Gebieten ermittelt werden. - Genauso umgekehrt: Der Imnitzer Park ist als Fläche ohne Kinder interpretier- und ladbar (es ist denkbar, dass man die inner-Elemente z.B. beim Rendering oder anderweitigen Verarbeiten einfach ignoriert werden, und nur outer in Betracht gezogen wird). Falls man sich für extreme Nutzungsänderungen innerhalb einer gemappten Fläche, die überwiegend als Park genutzt wird, interessiert, betrachtet man einfach die inner-Elemente der Parkfläche.. fertig (ein Datennutzer kann also entscheiden, wie weit er granulieren möchte, bzw. ab welchen Flächengrößen er nicht mehr im Multipolygon-Netz hinabsteigen möchte). Diese Beispieldaten sind für die Geschichte mit den 2/3 Häusern im Wald übertragbar und auch auf die Geschichte mit dem Bäcker im Wohngebiet: (Beispiel - Situation Haus im Wald): (Imnitzer Park multipoly - landuse=forest) (landuse meadow children - mini-residentials im forest) (Beispiel - Situation Bäcker im Wohngebiet): (Imnitzer Park - landuse=residential) (landuse meadow children - tiny-commercials im residential) Nochmal, mir ist klar, dass das flächendeckend momentan nicht umsetzbar ist, dazu müssten Editoren multipolygons mehr in den Kern ihrer Editierfunktionalität rücken und nicht als Extra am Rand liegen lassen. Dennoch ist es gar nicht so schwer, etwa eine Fläche einzufügen, wenn man diese Daten hat. - neue Grenze zeichenen - neues Multipolygon erstellen und taggen - alte Flächenbeziehungen umdefinieren (häufig nur eine Fläche) Für mich liegen die Vorteile auf der Hand, und wenn man die Beziehung Flächen - Flächengrenze einmal verstanden hat, ist es auch wesentlich einfacher, so zu editieren, als mit zig tausend ways, overlapping oder nicht, parallel oder nicht.. .. und das betrifft auch Änderungen - oft wird argumentiert, es sei schwerer Gebiete mit viel Beziehungen untereinander zu ändern - dabei ist es wirklich nur anders. Wenn jemand z.B. einen neuen closed way in ein Multipolygon einfügt und mal vergisst, dieses als inner in ein bereits gröberes Gebiet (outer) einzutragen, ist das ja kein Beinbruch. Irgendeinem anderen Mapper wird das schon auffallen, der das dann fixed. Dieser verbindet dann MICROgemappte Daten mit MACROgemappten.. Übrigens: Auch immens große Flächen lassen sich damit im Detail und ohne großen Fehler editieren, indem man sich einfach nur auf das relevante Grenzsegment fokussiert. Genauso, wie derzeit Radrouten editiert werden - da befasst man sich i.d.R. auch nur mit Streckenabschnitten. Routen sind tatsächlich eine gute Analogie: auch hier wird von Basismappern oft durch Editieren der Basisgeometrie eine Relation kurzzeitig unbrauchbar.. ..die dann jemand, der sich mit der Route beschäftigt, wieder fix'd. Gleiches funktioniert für Flächen, die über Multipolygone abgebildet werden. Validatoren zeigen dabei Fehlerflächen schnell und unkompliziert auf.. Der Schlüssel für die multipolygon-Akzeptanz ist m.M.n. eine höhere Editorintegration. Das fängt schon damit an, dass multipolygone neben anderen
