Multipolygonwahnsinn - oder: Durchblick war gestern!

poppei82 · 2013-06-30 12:52:01

Habe durch Zufall wieder eine Aufgabe für mutige Multipolygonspezialisten gefunden:
http://osm.org/go/0DW0BC9?layers=MN

In den niedrigen Zoomstufen wird bei mir noch ein Wald dargestellt. In der hohen Zoomstufe verschwindet der Wald (und wird stattdessen fälschlicherweise um die Stadt dargestellt).

aighes · 2013-06-30 13:19:15

Die Bäume sollten dann demnächst wieder vorhanden sein.

poppei82 · 2013-06-30 14:14:33

aighes wrote:

Die Bäume sollten dann demnächst wieder vorhanden sein.

Super! Danke! Sind wieder zu sehen.

fireball2 · 2013-07-23 17:13:04

Hallo Leute,

sorry, dass ich den Beitrag wieder hervorkrame. Aber ich habe in letzter Zeit, aufgrund einiger Renderfehler bei mapsforge-basierten Karten (hier ein Bsp.), versucht diverse Multipolygone zu reparieren. Jetzt bin ich schon des öfteren auf den Fehler "touching inner rings" gestoßen (z.B. diesen hier) , bei dem ich mir unsicher bin, wie dieser sauber zu korrigieren ist. Ich bitte daher um Eure Meinungen.

1.) Ist es überhaupt ein Fehler? Keepright oder auch OSMi zeigen ja manchmal auch Fehler an, wo gar keiner ist.
2.) Die einfachste Lösung, um die Fehlermeldung abzustellen, wäre doch, die gemeinsamen Punkte 1716846640 und 1716846640, der sich beiden berührenden "inner"-Flächen, einfach aufzutrennen (mittels JOSM "Linien trennen", Taste "G"). Dadurch würden sich beide Flächen nicht mehr berühren, da beide zu 100% aus eigenständigen Nodes bestehen würden. Aber, selbst wenn man die Flächenaußenkanten so nah wie nur möglich zusammenschiebt, so bliebe doch, wenn auch auf 99,9% aller Renderer unsichtbar, ein hauchdünner Streifen Wald zwischen den beiden Flächen bestehen. Und dies ist vor Ort nunmal nicht der Fall. Würde da nicht außerdem sinnlos Renderpower vergeudet, wenn jetzt wirklich viele solcher MPs derart konstruiert werden? Ich denke da mehr an stromsparende Handys als Rendereinheit als an einen Desktop-PC.

Wie würdet Ihr in diesem Fall idealer Weise den Fehler korrigieren?

Vielen Dank für Eure aufklärenden Worte im Voraus.

streckenkundler · 2013-07-23 17:22:10

fireball2 wrote:

Ist es überhaupt ein Fehler?

rein nach Datendefinition eines Multipolygons wäre das meiner Ansicht nach ein Fehler, da OSM den Datentyp Polygon im engeren Sinne nicht kennt, ist es glaube ich strittig, ob touching inner Rings ein Fehler ist.

Ich persönlich hinterlasse keine touching inner Rings. Ich grenze eine taglose inner Fläche ab, die die betreffenden inner-Flächen umfasst und entlasse dann die betreffenden inner-Flächen aus dem MP und lasse sie als simple Flächen stehen.

Sven

fkv · 2013-07-23 18:40:41

fireball2 wrote:

Jetzt bin ich schon des öfteren auf den Fehler "touching inner rings" gestoßen (z.B. diesen hier) , bei dem ich mir unsicher bin, wie dieser sauber zu korrigieren ist. Ich bitte daher um Eure Meinungen.
1.) Ist es überhaupt ein Fehler? Keepright oder auch OSMi zeigen ja manchmal auch Fehler an, wo gar keiner ist.

Genau um so einen Fall handelt es sich hier. Die Entwickler von OSMI kommen aus einer anderen Welt und haben eine persönliche Abneigung gegen touching inner rings, deshalb meckert OSMI sie an. Aber in Wahrheit sind sie in OSM zulässig: http://wiki.openstreetmap.org/wiki/Mult … nner_rings
Viele OSMI-Benutzer wissen das nicht und editieren dran rum, nur mit dem Ziel das Gebiet in OSMI "sauber" zu kriegen. In Wahrheit sind das aber Verschlimmbesserungen, da der Zweck der touching inner Rings dabei missachtet wird.

Überhaupt sollte man an Objekten, die wer anderer erstellt hat, nur dann etwas verändern, wenn es eine Verbesserung ist. Das ist eine Sache des Respekts gegenüber den Erstellern.

2.) Die einfachste Lösung, um die Fehlermeldung abzustellen, wäre doch, die gemeinsamen Punkte 1716846640 und 1716846640, der sich beiden berührenden "inner"-Flächen, einfach aufzutrennen (mittels JOSM "Linien trennen", Taste "G"). Dadurch würden sich beide Flächen nicht mehr berühren, da beide zu 100% aus eigenständigen Nodes bestehen würden. Aber, selbst wenn man die Flächenaußenkanten so nah wie nur möglich zusammenschiebt, so bliebe doch, wenn auch auf 99,9% aller Renderer unsichtbar, ein hauchdünner Streifen Wald zwischen den beiden Flächen bestehen. Und dies ist vor Ort nunmal nicht der Fall.

Genau, das wäre eine Verfälschung.

Allerdings ist der Bereich im konkreten Fall wirklich nicht optimal gemappt, denn der eine ausgeschnittene Ring hat überhaupt keine Tags und der andere nur non-physische. Wenn diese Bereiche kein Wald sind, was dann? Offensichtlich Wiese. Na dann sollten entweder beide Ringe mit landuse=meadow getaggt werden, oder man nimmt den östlichen Ring aus der Relation heraus und dehnt den westlichen auf den gesamten Wiesenbereich aus und taggt ihn mit landuse=meadow. Dann ist zufällig sogar OSMI zufrieden.

wambacher · 2013-07-23 19:47:32

fkv wrote:

Die Entwickler von OSMI kommen aus einer anderen Welt und haben eine persönliche Abneigung gegen touching inner rings, deshalb meckert OSMI sie an.

Zur Klarstellung - obwohl ich sicher bin, dass dir das auch bekannt ist:

Diese "andere Welt" ist nicht etwa eine abgelegene Stelle auf der uns abgewandten Mondseite, sondern der weltweit etablierte, von dutzenden Softwarepaketen diverser Hersteller unterstützte OGC-Standard.
Langfristig können wir es uns nicht leisten, diesen Standard zu ignorieren.

Die Autoren vom OSMI versuchen nur auf Datenstrukturen hinzuweisen, die diesem Standard nicht entsprechen. Man kann in OSM Touching Inner Rings benutzen, aber man braucht es nicht so zu machen.

Ich bevorzuge übrigens jetzt auch die einfache Version, die Streckenkundler vorhin erwähnt hat.

Last edited by wambacher (2013-07-23 22:07:37)

fkv · 2013-07-23 20:15:52

wambacher wrote:

Diese "andere Welt" ist nicht etwa eine abgelegene Stelle auf der uns abgewandten Mondseite, sondern der weltweit etablierte, von dutzenden Softwarepaketen diverser Hersteller unterstützte GIS-Standard.
Langfristig können wir es uns nicht leisten, diesen Standard zu ignorieren.

Doch, können wir. OSM hat es ganz ohne GIS-Standard zur weltgrößten Geodatenbank gebracht.

Die Autoren vom OSMI versuchen nur auf Datenstrukturen hinzuweisen, die diesem Standard nicht entsprechen.

Das dürfen sie in einem OGC-Validator machen, aber nicht in einem OSM-Validator. In OSM gelten andere Spezifikationen.

Englisch und Chinesisch sind weiter verbreitet als Deutsch, trotzdem benutzt du für deine deutschen Texte eine deutsche Rechtschreibprüfung und keine englische oder chinesische.

SunCobalt · 2013-07-23 20:34:15

Alles hat seine Nachteile, auch die künstlichen, in der Realität nicht vorhanden Lücken beim Vermeiden von Touching Inner Rings.

streckenkundler · 2013-07-23 21:34:35

wambacher wrote:

Langfristig können wir es uns nicht leisten, diesen Standard zu ignorieren.

Das betrachte ich als einen ganz, ganz wichtigen Satz. Danke!

Ich meine, diesen OGC- Standard gibt es nicht umsonst.... Er markiert eine hinreichend saubere und allgemein akzeptierte Ebene der Verwendung von Datentypen in Geoinformationssystemen. Letztendlich ist OSM auch nichts anderes als ein Geoinformationssystem. Den OGC-Standard zu ignorieren halte ich für blauäugig und falsch. Je einfacher man an bestimmten stellen seine Datenhaltung gestaltet und je mehr man sich um Kompaktibilität mit etablierten Standards kümmert, desto höher ist die Akzeptanz dessen, was man nach der Arbeit tut und sorgt für Anreiz, eher aktuellere OSM- Daten zu verwenden, als kostenpflichtige Daten Dritter...

Ich hab ein kleines bisschen ein Problem damit, daß OSM sich nach besten Wissen und Gewissen um die Freigabe von Daten (welcher Form und Quelle auch immer) kümmert, ohne selbst einen Schritt weiter zu gehen, und sich schwer damit tut, selbst solche offenen, freien und als allgemeiner Standard dokumentierten Datentypen einzführen.

Um zum Thema zurück zukehren:

Ich rate, möglichst stets geschlossene, Linienzüge als Polygone ohne Relationen zu verwenden. Touching inner Rings und aus Linien gebildete Multipolygone sollte man vermeiden (auch wenn sie bei OSM zulässig sind).

in diesem Sinne...

Happy Mapping,

Sven

fireball2 · 2013-07-23 22:14:27

@Sven, danke für Deine Antwort. Soll das heißen, Du würdest um diese beiden Flächen/Wege (159566803 und 221656070) einen neuen separaten way drumrumzeichnen? Also ohne jegliche tags, nur als way mit der Rolle "inner"? Ich hab' dies mal so korrigiert, wie ich es jetzt von Dir verstanden habe. Das man dann innerhalb der ausgestanzten Fläche wieder ganz normal mit Polygonen arbeiten kann, hat definitiv einen gewissen Reiz der Einfachheit. Andererseits ist das "Nachmalen" der beiden Flächen für das Ausstanzen zweier Flächen nur bei kleinen Flächen mit wenigen Nodes praktikabel, oder?

@all: Danke für die vielen Antworten. Anhand ihrer sieht man allerdings, dass viele Wege nach Rom führen und nicht alles in Stein gemeiselt ist, typisch OSM eben ;-). Wie auch immer, ich gebe zu faul zu sein und werde daher auf Dauer eher einfache Lösungen bevorzugen. Außerdem möchte ich schnell vorwärts kommen bzw. in meiner spärlichen Zeit möglichst viel zu OSM beitragen. In diesem speziellen Fall hätte ich daher wohl einfach die beiden gemeinsamen Punkte der beiden Flächen aufgetrennt, da die Zeiterfordernis (Mausklick, Taste G, Mausklick, Taste G) für die Problembeseitung so minimal gewesen wäre. Noch weniger Arbeitszeit hätte natürlich fkv's-Lösung benötigt, das Problem nicht beseitigen weil (eventuell) gar keines besteht. Der Mapsforge-Writer hatte übrigens (in diesem Fall) keine Probleme mit der richtigen Darstellung, nur Selbstüberschneidungen von (Multi-)Polygonen mag er scheinbar nicht (intersections). Es ist wie immer eine Gradwanderung zwischen verschiedenen Anforderungen an die OSM-Datenbank... .

streckenkundler · 2013-07-24 07:27:37

fireball2 wrote:

Soll das heißen, Du würdest um diese beiden Flächen/Wege (159566803 und 221656070) einen neuen separaten way drumrumzeichnen? Also ohne jegliche tags, nur als way mit der Rolle "inner"?

ja, so verfahre ich immer. Ich persönlich würde es auch vermeiden, ein Multipolygon mit aus einzelnen Linienzügen zusammengesetzte Outer-Rolle zu verwenden. http://www.openstreetmap.org/browse/relation/1405243. Solche Dinger sind äußerst fragil und machen es unheimlich schwer, eine Teilfläche abzuteilen weil sich z.B. eine Nutzung geändert hat. Außerdem werden damit oft unnötige Relationen erzeugt, wo simlpe geschlossene, relationsfreie Linienzüge aureichen würden. Aber das ist eine Sache, was andere Mapper anders sehen...

fireball2 wrote:

Andererseits ist das "Nachmalen" der beiden Flächen für das Ausstanzen zweier Flächen nur bei kleinen Flächen mit wenigen Nodes praktikabel, oder?

Auch bei großen Flächen geht das schnell: Taste "F" im JOSM Also Funktion Linie verfolgen. Wie das bei anderen Editoren ist, weiß ich nicht.

fireball2 wrote:

nur Selbstüberschneidungen von (Multi-)Polygonen mag er scheinbar nicht (intersections).

Intersectons wiederum, also sich selbst überschneidende Linien und Punkte sind wirkliche, echte Geometriefehler, die einerseits vermieden werden müssen und andererseits wenn schon vorhanden, zu beseitigen sind.

Sven

fireball2 · 2013-07-24 11:00:35

Nochmals danke für die Klarstellung. Ich ziehe aus den Ausführungen daher meine Schlussfolgerung, die Priorität bei der Fehlerbeseitigung auf Intersections und andere eindeutige Fehler in der OSM-DB zu legen. In das Wespennest "Touching Inner" werde ich dann lieber nicht stechen, vor allem da "meine" benutzten Renderer diesen "Fehler" scheinbar im Sinne des Ersteller korrekt verarbeiten bzw. anzeigen. Vielleicht bringt hier die Zukunft Konsens ... .

Für den Tipp mit der Taste "F" in JOSM bin ich dankbar, diese Funktion hatte ich bislang noch nie ausprobiert.

Ich persönlich würde es auch vermeiden, ein Multipolygon mit aus einzelnen Linienzügen zusammengesetzte Outer-Rolle zu verwenden. ... Außerdem werden damit oft unnötige Relationen erzeugt, wo simlpe geschlossene, relationsfreie Linienzüge aureichen würden.

Dieser Meinung schließe ich mich eindeutig an. Das sinnloses Zerschnippeln einfacher bzw. kleiner Flächen bereitet mir leider auch immer wieder Bauchschmerzen, wenn ich sowas sehe. Besonders diese MP-Monster aus grauer OSM-Urzeit sollten m.E. nach und nach wieder auf "handhabbare Normalgröße für Jedermann" zurückgestutzt werden. Mir ist natürlich bewusst, dass es immer Fälle gibt, wo o.g. MP's aus mehreren Linienzügen unumgänglich sind. Leider sind es genau diese Objekte, die wieder und wieder bei den Fehlermeldungen auftauchen und einer Reparatur bedürfen, und da kommt manchmal schon etwas Frustration auf. Schließlich möchte ich etwas zu OSM beitragen und nicht ständig in Fließbandarbeit immer wiederkehrende Fehler reparieren. Auf der anderen Seite möchte ich aber auch mit einer Karte unterwegs sein, wo möglichst alle Objekte (fehlerfrei) angezeigt werden. Daher glaube ich, dass die Fehlerbeseitigung in der OSM-DB in Zukunft immer mehr Zeit beanspruchen wird, aber dies ist wohl auch das Ergebnis einer immer weiter wachsenden Datenbank. Die Anfänge von OSM sind nunmal vorbei und jetzt müssen wir uns wohl oder übel den neuen Aufgaben und Herausforderungen stellen, damit das Projekt sich selbst nicht im Wege steht.

Aber das ist eine Sache, was andere Mapper anders sehen...

Das ist OSM live .

Taunide · 2013-08-09 11:04:36

fireball2 wrote:

Das sinnloses Zerschnippeln einfacher bzw. kleiner Flächen bereitet mir leider auch immer wieder Bauchschmerzen, wenn ich sowas sehe. Besonders diese MP-Monster aus grauer OSM-Urzeit sollten m.E. nach und nach wieder auf "handhabbare Normalgröße für Jedermann" zurückgestutzt werden. Mir ist natürlich bewusst, dass es immer Fälle gibt, wo o.g. MP's aus mehreren Linienzügen unumgänglich sind. Leider sind es genau diese Objekte, die wieder und wieder bei den Fehlermeldungen auftauchen und einer Reparatur bedürfen, und da kommt manchmal schon etwas Frustration auf.

Dies ist alles richtig, und kann m.E. nur durch ein paar, 2-3, vielleicht auch mehr Dinge erreicht werden:

1 - eine Verbesserung des WIKI anstatt zu beschreiben "was ist alles technisch möglich?" hin zu konkreten Empfehlungen "wann MP mappen, und wann einfaches Objekt". Ein Teil des Problems ist, dass es für "pfiffige" Mapper zu einfach ist, MP's zu erzeugen. Auch solche die dann hinterher nahezu unwartbar sind. Der Ehrgeiz eines einzigen Mappers, sich in einer Region mit komplexen Strukturen zu "verewigen" anstatt solche zu erzeugen, die leicht wartbar sind, oder auch nur "mal auszuprobieren" was er im vorhandenen WIKI über die verschiedenen Varianten der Multipolygone gelesen hat, kann die Arbeit anderer in derselben Region empfindlich stören bzw. diese auf lange Zeit hin aus dieser Region "vertreiben". Zumindest diejenigen die nicht die Geduld haben sich in die Denke dieser "besonders Pfiffigen" oder mit besonderer Freude an komplexen Strukturen begabten mühselig einzuarbeiten.

2 - bessere funktionale Unterstützung in den gängigsten Editoren wie Potlatch 2 betreffend die Wartung von MP's. Was das Neuanlegen von MP's angeht, bietet hierfür Potlatch im "normalen" Mode kaum Hilfe, das ist m.E. auch richtig. Was den "Advanced" Mode angeht, sollte es durch eine Funktions- oder Fehlerprüfung ergänzt werden, erst dann sollte in die Datenbank geschrieben werden. Was die übrigen vorhandenen Editoren angeht (die ich im einzelnen nicht kenne) sollten diese sich ähnlich verhalten. Würden sie sich so verhalten, gäbe es weniger Anlass zur Klage.

3 - evtl. eine Beschränkung zur Menge der "Inner" oder "Outer" Objekte eines MP's. Ich bin da selber nicht klar drüber. Es gibt z.B. bei uns im Taunus Waldgebiete die nahezu "kein Ende nehmen" und dazu noch eine unzählige Menge "Löcher" d.h. Inseln haben. Ich halte diese, mit teils hunderten Inner- und oft mehr als 10 Outer-Flächen, für im wesentlichen richtig gemappt. Ich sehe aber keinen Bedarf für weitere solche "Monster"; es sei denn für Gebiete, wo das Grobmapping noch nicht abgeschlossen ist. Ich glaube aber nicht, dass es von solchen MP's viele gibt. Vielleicht wäre es (- 4. -) erforderlich, dass sich eine spezielle Arbeitsgruppe um solche Groß-MP'e kümmert.

5 - die hohe Nummerierung der neu in die Datenbank aufgenommenen Objekte mit "ganz ähnlichen" Nummern für ganz unterschiedliche MP'e, welche die Nummern-Merkfähigkeit des gewöhnlichen Mappers überfordern oder sehr weit strapazieren, erschwert die Wartung solcher Objekte ganz außerordentlich. Sicher bin ich nicht der einzige, der viel lieber an "alten" MP's mit 5-stelliger Nummerierung arbeitet, von denen ich teils im Kopf habe wo sie sich befinden weil ich so oft an ihnen gearbeitet habe. Wenn dann besonders "Schlaue" auf die glorreiche Idee kommen diese MP's zu zerstückeln, worauf sie dann ähnlich aussehende, hohe Nummern bekommen, geht sicher nicht bloss mir alleine die Hutschnur hoch...!

Last edited by Taunide (2013-08-09 11:22:12)

streckenkundler · 2013-08-09 11:57:41

Hallo,

Ein Aufteilen von Übergroßen Monster-MP's halte ich für dringend nötig.

Taunide wrote:

eine Verbesserung des WIKI anstatt zu beschreiben "was ist alles technisch möglich?" hin zu konkreten Empfehlungen "wann MP mappen, und wann einfaches Objekt".

Wenn mir diverse MP's anschaue, komme ich oft zu dem Schluß, daß es einfacher geht. Ich komme auch zu dem Schluß, daß bei einer sinnvollen Größengestaltung des MP's solche aus meheren nicht geschlossenen Linienzügen gebildeten MP's mittlerweile völlig unnötig, weil auch kompliziert und stark fehleranfällig sind. Für mich gehören solche abgeschafft.

Taunide wrote:

3 - evtl. eine Beschränkung zur Menge der "Inner" oder "Outer" Objekte eines MP's. Ich bin da selber nicht klar drüber.

Mh... da halte ich nichts davon... wird glaube ich auch nicht funktionieren. Wenn man Sinnvolle Größen der MP's verwendet, begrenzen sich die Objektezahl von allein.

Taunide wrote:

Ich halte diese, mit teils hunderten Inner- und oft mehr als 10 Outer-Flächen, für im wesentlichen richtig gemappt.

MP's mit mehreren Outer sind zwar zugelassen, ich finde diese aber doch sehr unschön. Wenn man zu einer Fläche neuere Erkenntnisse hat und eine Teilfläche aus dem MP abschneiden und als simple Fläche weiterverarbeiten will, weigert sich z.B. JOSM zu schneiden: Es kann MP's mit mehreren Outer nicht verarbeiten.

Taunide wrote:

Wenn dann besonders "Schlaue" auf die glorreiche Idee kommen diese MP's zu zerstückeln, worauf sie dann ähnlich aussehende, hohe Nummern bekommen, geht sicher nicht bloss mir alleine die Hutschnur hoch...!

Hm... wenn man vielen MP-Monstern Herr werden und sie in handhabbare Stücke teilen will, wird man an einer neuen Nummer nicht umhin kommen....

...und wir brauchen den Datentyp Polygon und sollten möglichst OGC-Konform sein.

SunCobalt · 2013-08-09 12:34:29

streckenkundler wrote:

Ich komme auch zu dem Schluß, daß bei einer sinnvollen Größengestaltung des MP's solche aus meheren nicht geschlossenen Linienzügen gebildeten MP's mittlerweile völlig unnötig, weil auch kompliziert und stark fehleranfällig sind. Für mich gehören solche abgeschafft.

Große Worte. Wie stellst Du Dir das bei Wäldern, die die Größe eines Bundeslandes erreichen können, vor?

wambacher · 2013-08-09 12:36:40

Taunide wrote:

5 - die hohe Nummerierung der neu in die Datenbank aufgenommenen Objekte mit "ganz ähnlichen" Nummern für ganz unterschiedliche MP'e, welche die Nummern-Merkfähigkeit des gewöhnlichen Mappers überfordern oder sehr weit strapazieren, erschwert die Wartung solcher Objekte ganz außerordentlich. Sicher bin ich nicht der einzige, der viel lieber an "alten" MP's mit 5-stelliger Nummerierung arbeitet, von denen ich teils im Kopf habe wo sie sich befinden weil ich so oft an ihnen gearbeitet habe. Wenn dann besonders "Schlaue" auf die glorreiche Idee kommen diese MP's zu zerstückeln, worauf sie dann ähnlich aussehende, hohe Nummern bekommen, geht sicher nicht bloss mir alleine die Hutschnur hoch...!

Tja, da kann man nix gegen machen: MP sind Relationen und werden in der OSM-Datenbank in der Tabelle relations abgespeichert. Zusammen mit allen anderen Relationen (Routen, Turn-Restrictions, die ach so unbeliebten Sammel-Relationen und was es sonst noch so gibt).
Jede neue Relation bekommt automatisch eine neue, noch nie verwendete eindeutige Nummer - und das war es auch schon. "Frei" gewordene Nummern werden nicht neu vergeben, da sie in der History immer noch gespeichert sind.

Hier mal die Datenstruktur im Osmosis Snapshot-Schema, die der Datenstruktur auf dem OSM-DB-Server ähnlich ist (osm2pgsql legt die Tabellen etwas anders an):

planet=# \d relations
                    Table "public.relations"
    Column    |            Type             |     Modifiers      
--------------+-----------------------------+--------------------
 id           | bigint                      | not null
 version      | integer                     | not null
 user_id      | integer                     | not null
 tstamp       | timestamp without time zone | not null
 changeset_id | bigint                      | not null
 tags         | hstore                      | 

Indexes:
    "pk_relations" PRIMARY KEY, btree (id)

Derzeit hat relations 2.440.146 Einträge mit der höchsten vergebenen id 3.127.203 - und das erhöht sich ständig. (*)

planet=# select count(id) from relations;
  count  
---------
 2440146
(1 row)

planet=# select max(id) from relations;
   max   
---------
 3127203
(1 row)

in den Punkten 1+2 gebe ich dir - inzwischen - recht und versuche a) solche Konstrukte zu vermeiden und b) diese abzubauen. 3+4 halte ich für unnötig.

Gruss
walter

*) vorm Abschicken der Antwort: 2.440.152/3.127.209

Last edited by wambacher (2013-08-09 12:42:28)

streckenkundler · 2013-08-09 12:44:53

SunCobalt wrote:

Wie stellst Du Dir das bei Wäldern, die die Größe eines Bundeslandes erreichen können, vor?

Hast du da ein Beispiel?

SunCobalt · 2013-08-09 12:54:34

streckenkundler wrote:

SunCobalt wrote:
Wie stellst Du Dir das bei Wäldern, die die Größe eines Bundeslandes erreichen können, vor?
Hast du da ein Beispiel?

Ist das Ironie oder kennst Du wirklich keine so großen Waldgebiete?

streckenkundler · 2013-08-09 12:59:49

SunCobalt wrote:

Ist das Ironie oder kennst Du wirklich keine so großen Waldgebiete?

Das ist keine Ironie.
Ich hab mich bisher nur im Brandenburgischen rumgetrieben, und alles, was ich hier gesehen habe, rechtfertigte kein aus Einzellinien gebildetes MP: Lieberoser Heide, Reicherskreuzer Heide, Rochauer Heide sind sehr groß, auch im Norden Brandenburg gibt es große (Schorheide...)
Sven

SunCobalt · 2013-08-09 13:10:09

streckenkundler wrote:

SunCobalt wrote:
Ist das Ironie oder kennst Du wirklich keine so großen Waldgebiete?
Das ist keine Ironie.
Ich hab mich bisher nur im Brandenburgischen rumgetrieben, und alles, was ich hier gesehen habe, rechtfertigte kein aus Einzellinien gebildetes MP: Lieberoser Heide, Reicherskreuzer Heide, Rochauer Heide sind sehr groß, auch im Norden Brandenburg gibt es große (Schorheide...)
Sven

OK. Du hattest geschrieben, dass Du mehrere Outer abschaffen willst. Man kann große Wälder schon etwas teilen, aber ganz auf mehrer Outer zu verzichten, wird doch etwas schwierig, selbst in DE
Bayern mehrere Outer trotz Teilungs des Waldes: http://www.openstreetmap.org/?relation= … 22/10.9937

Aber das ist nichts gegen Wälder in änderen Ländern. Denk mal an Südamerika.

geri-oc · 2013-08-09 13:14:53

SunCobalt wrote:

streckenkundler wrote:
Ich komme auch zu dem Schluß, daß bei einer sinnvollen Größengestaltung des MP's solche aus meheren nicht geschlossenen Linienzügen gebildeten MP's mittlerweile völlig unnötig, weil auch kompliziert und stark fehleranfällig sind. Für mich gehören solche abgeschafft.
Große Worte. Wie stellst Du Dir das bei Wäldern, die die Größe eines Bundeslandes erreichen können, vor?

Wälder eines Landes bestehen aus Forstrevieren, Forstbezirken.
Wenn diese nicht bekannt sind werden Wälder von Straßen, Eisenbahn oder Flüssen geteilt.
Und selbst Schneisen im Wald (meist nummeriert) können zur "Verkleinerung" der Riesen-MP genutzt werden.
Dann gibt es noch die Möglichkeit an Grenzen zu "schneiden".

streckenkundler · 2013-08-09 13:29:05

Hm... da kommt wieder mein GIS-Denken durch.

SunCobalt wrote:

Man kann große Wälder schon etwas teilen, aber ganz auf mehrer Outer zu verzichten, wird doch etwas schwierig, selbst in DE

Was ist denn eigentlich der Grund, mehrere outer anwenden zu wollen/müssen? Die Eigenschaft des Waldes (Laubwald Mischwald, Nadelwald) ansich ist es nicht. Der Name? Hm...

SunCobalt wrote:

Aber das ist nichts gegen Wälder in änderen Ländern. Denk mal an Südamerika.

Warum nicht auch als Fläche?

ob ich nun einen Sack voll einzelner outer-Linien und einen Sack voll einzelner Innerlinien habe... oder wenige, aber geschlossene.
Das einzige, was mir einfällt: Anzahl der Punkte pro Objekt... Aber was bewirkt es, wenn man diese Grenze für bestimmte, nicht verkleinerbare Objekte aufhebt?

Sven

SunCobalt · 2013-08-09 13:30:35

geri-oc wrote:

SunCobalt wrote:
streckenkundler wrote:
Ich komme auch zu dem Schluß, daß bei einer sinnvollen Größengestaltung des MP's solche aus meheren nicht geschlossenen Linienzügen gebildeten MP's mittlerweile völlig unnötig, weil auch kompliziert und stark fehleranfällig sind. Für mich gehören solche abgeschafft.
Große Worte. Wie stellst Du Dir das bei Wäldern, die die Größe eines Bundeslandes erreichen können, vor?
Wälder eines Landes bestehen aus Forstrevieren, Forstbezirken.
Wenn diese nicht bekannt sind werden Wälder von Straßen, Eisenbahn oder Flüssen geteilt.
Und selbst Schneisen im Wald (meist nummeriert) können zur "Verkleinerung" der Riesen-MP genutzt werden.
Dann gibt es noch die Möglichkeit an Grenzen zu "schneiden".

Wälder gibt es nicht nur in deutschen Forstrevieren oder Forstbezirken mit numerierten Schneisen und künstlichen Unterbrechungen durch Straßen oder Eisenbahnen alle paar km. Wenn man bei OSM vorschlägt etwas abzuschaffen, hier war von MP mit mehreren Outer die Rede, dann kann man nicht nur von deutschen Gegebenheiten ausgehen.

SunCobalt · 2013-08-09 13:33:20

streckenkundler wrote:

Hm... da kommt wieder mein GIS-Denken durch.
SunCobalt wrote:
Man kann große Wälder schon etwas teilen, aber ganz auf mehrer Outer zu verzichten, wird doch etwas schwierig, selbst in DE
Was ist denn eigentlich der Grund, mehrere outer anwenden zu wollen/müssen? Die Eigenschaft des Waldes (Laubwald Mischwald, Nadelwald) ansich ist es nicht. Der Name? Hm...
SunCobalt wrote:
Aber das ist nichts gegen Wälder in änderen Ländern. Denk mal an Südamerika.
Warum nicht auch als Fläche?
ob ich nun einen Sack voll einzelner outer-Linien und einen Sack voll einzelner Innerlinien habe... oder wenige, aber geschlossene.
Das einzige, was mir einfällt: Anzahl der Punkte pro Objekt... Aber was bewirkt es, wenn man diese Grenze für bestimmte, nicht verkleinerbare Objekte aufhebt?
Sven

Bei OSM dürfen Linien nur 2000 Nodes haben. Bei großen Wäldern reicht das oft nicht. Ich unterteile die auch so oft es geht. Aber wenn die Unterteilung dann aufwendiger wird als mehrere Outer Ways zu verwenden, lass ich es halt.
Woher die 2000er Grenze kommt und was es für Implikationen hätte, wenn man die Grenze aufhebt, weiß ich nicht

Announcement

#376 2013-06-30 12:52:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#377 2013-06-30 13:19:15

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#378 2013-06-30 14:14:33

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#379 2013-07-23 17:13:04

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#380 2013-07-23 17:22:10

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#381 2013-07-23 18:40:41

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#382 2013-07-23 19:47:32

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#383 2013-07-23 20:15:52

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#384 2013-07-23 20:34:15

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#385 2013-07-23 21:34:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#386 2013-07-23 22:14:27

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#387 2013-07-24 07:27:37

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#388 2013-07-24 11:00:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#389 2013-08-09 11:04:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#390 2013-08-09 11:57:41

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#391 2013-08-09 12:34:29

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#392 2013-08-09 12:36:40

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#393 2013-08-09 12:44:53

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#394 2013-08-09 12:54:34

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#395 2013-08-09 12:59:49

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#396 2013-08-09 13:10:09

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#397 2013-08-09 13:14:53

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#398 2013-08-09 13:29:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#399 2013-08-09 13:30:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#400 2013-08-09 13:33:20

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer