Multipolygonwahnsinn - oder: Durchblick war gestern!

Pepito · 2012-11-04 02:27:34

Der "Wahnsinn" hat aber auch Methode. Auch wenn es immer heißt, dass wir nicht für die Renderer arbeiten, so ist es eben doch genau das. Man will ja seine Daten auch sehen, anwenden und nicht nur für die Wissenschaft arbeiten. Bei der Reitwanderkarte z.B. geht im Wald nichts mehr ohne Multipolygone, wenn man Wiesen als Orientierungshilfe sehen möchte. Vor einem Jahr ging das alles noch ohne Multipolygone.

Keichi · 2012-11-04 12:45:54

Also so wie ich die Diskussion jetzt hier verstanden habe, soll man MP's nicht für ganze Landzüge und Stadtteile mit Industriegebieten, Amenitys usw benutzen sondern nur für kleine Simpele Dinge? Für mich klingt das irgendwie auch nicht gerade besser, vorallem weil MP's für sowas wie landuse=* doch recht Praktisch sind, ich stell's mit zumindest beim landuse=farmland bzw. landuse=meadow sehr nützlich vor, da zwischen den einzelnen Feldern sehr oft natural=scrub ist , so bräuchte man nur noch die Polygone für den Wildwuchs einzeichnen, und das komplette MP Outer wäre farmland. So würde es zumindest auch simpel bleiben.

Ich bin eh kein großer Fan davon jedes Feld nun einzeln einzutragen, wenn es keine Trennung durch Wege oder andere Objekte dazwischen gibt, allerdings muss ich aber auch sagen, das ich durchaus den Nutzen dafür sehe jedes Feld ein eigenes Polygon zu geben, was aber wiederrum nur den Bauern nützen würde.

aighes · 2012-11-04 13:08:38

Es geht bei den MPs nicht darum, Flächen aus zu stanzen, damit der Renderer das alles toll malen kann, sondern zu sagen, wo Wald ist und wo er eben nicht ist. Das hat auch nicht viel mit "Tagging für einen Renderer" zutun. Unser Ziel ist es, die Realität so abzubilden, dass sie möglichst einfach eingepflegt und ausgewertet werden kann. Tagging für einen Renderer beschreibt den Vorgang, dass ein Mapper bewusst die Realität falsch einträgt, um ein hübsches Bild bei einem Renderer zu erhalten. Ein Beispiel wäre natural=beach für die Bunker auf Golfplätzen, um diese gelb rendern zu lassen.

@Keichi:
Warum "nur für den Bauern"? Wanderwege haben auch "nur" nutzen für die Wanderer.

Keichi · 2012-11-04 13:52:40

aighes wrote:

@Keichi:
Warum "nur für den Bauern"? Wanderwege haben auch "nur" nutzen für die Wanderer.

So sehe ich es ehrlich gesagt nicht.. Von Wanderwegen hat ehrlich gesagt schon wieder jeder etwas, ich gehe auch nicht wandern, aber finde es ab und zu ganz nützlich wenn ich weiß wo ein Weg ist und wo er hinführt und vorallem was sich an diesen stück befindet. Wenn da jetzt zbs. ne Alte Burg Ruine ist, benutz man ja nich gleich den gesamten Wanderweg sondern nur die Wegstücke die direkt an der Burg sind, und über die man am schnellsten dort hin kommt. Also hat davon jeder was.

Bei Feldern ist es allerdings wirklich so, das es zwar nützlich ist zu wissen, das dort welche sind, aber für die allgemeinheit ist es eben nicht interesannt zu wissen wie groß jetzt ein feld in einen haufen von 10 Feldern ist.

aighes · 2012-11-04 16:01:14

Sorry, hatte mich unklar ausgedrückt. Gemeint waren die Wanderrouten. Also nicht der Weg an sich, sondern nur die Zusatzinfo,dass der Wanderweg xy über diesen Weg verläuft. Ich will auch nicht sagen, dass jeder der Felder eintragen möchte, dies Feldgenau machen muss. Ich fand es nur etwas merkwürdig zu sagen, dass es "nur" den Bauern nutzt.

Pepito · 2012-11-04 20:09:01

Ging vor einem Jahr aber alles noch ohne Multipylgone. Ist doch klar, wenn ich auf farmland ein scrub-Gebiet habe, ist da natürlich kein Farmland. Aber war vielleicht rechenintensiver für die Renderer. Auf der anderen Seite ist es für die Datenerfasser um so komplizierter.

Was ich noch ungünstig finde: Die Tags für MP können einmal zu dem Objekt eingetragen werden, und zum anderen aber auch zu dem MP. Die Reitwanderkarte erfasst die Tags zum Multipolygon, die Navit-Karte dagegen die zum Objekt. Also alles zweimal eintragen. Es kommt dabei auch sicherlich öfter zu Differenzen bei den Tags, wenn jemand sich mit MP nicht auskennt und nur tags zum Objekt macht ohne etwas von den tags im MP zu wissen.

chris66 · 2012-11-04 20:18:27

Pepito wrote:

Also alles zweimal eintragen.

Das ist falsch. Entweder alle Tags an die Relation (ist die neuere, empfohlenen Methode), oder alle Tags
an die outer-ways.

viw · 2012-11-05 06:23:57

Pepito wrote:

Ging vor einem Jahr aber alles noch ohne Multipylgone. Ist doch klar, wenn ich auf farmland ein scrub-Gebiet habe, ist da natürlich kein Farmland. Aber war vielleicht rechenintensiver für die Renderer. Auf der anderen Seite ist es für die Datenerfasser um so komplizierter.

Ich glaube du denkst zu sehr an den Renderer. Wie sieht denn die Auswertung aus wenn man wissen möchte wieviel der Erdoberfläche mit Wald oder Farmland bedeckt ist? Man fragt die Datenbank einfach gib mir die Summen aller Flächen die getaggt sind mit forest. Wenn du jetzt über die Flächen drüberzeichnest, kann das der Renderer noch darstellen (jedenfalls wenn die Reihenfolge beim zeichnen in deinem Sinne ist), aber in der Datenbank müsst man jetzt jede Fläche zunächst einmal prüfen ob sie Flächen enthält. Und dann geht das Theater erst richtig los. Sind Häuser eigentlich Flächen die zum Wald gehören oder nicht mehr. Wenn das also sauber erfasst wurde, machts du anderen die Auswertung sehr viel leichter. Und du stellst für dich Sicher, das deine Flächen ordentlich angezeigt werden, auch wenn der Renderer mal zu erst Scrub und später Wald zeichnen sollte. In diesem Falle verschwindet sonst deine Lichtung oder was auch immer unter dem Wald.

Pepito · 2012-11-05 12:26:02

Die Frage ist aber auch, wer kompetenter ist: Ein Datenbankexperte, der weltweit den Waldbestand errechnen will, oder jemand, der mit GPS-Messgerät am Wochenende los zieht und sich am Anblick seiner neu entdeckten Wege auf der Karte erfreuen will. Und Letzterer lässt die Datenerfassung schnell sein, wenn er sich erst (leider open-source-typisch) wochenlang einlesen muss.

Für den Experten ist doch die Komplexität kein Problem. Aber das simple Datenerfassen für eine Karte, da hilft kein Experte, sondern schlicht Manpower. Myriaden von begeisterungsfähigen Menschen, die losziehen, die Welt zu erfassen!

aighes · 2012-11-05 13:13:51

Was du willst, ist eine Karte malen. Du editierst etwas, schaust es dir auf der Karte an und wenn es dir gefällt lässt du es so und wenn nicht, dann änderst du es solange, bis es schön aussieht. Das Ergebnis ist eine schöne Karte. Das ist aber nicht Ziel von OSM. Wir wollen korrekte Daten, aus denen "Experten" (wie du es so schön nennst) u.a. Karten erstellen können. Das können die "Experten" aber nur, wenn die Daten so erfasst sind, wie es auch in der Realität der Fall ist.

Der "Experte" sieht bei deiner Methode bspw. aus den Daten nicht, ob der Parkplatz nun zum Wald dazu gehört oder ob da alle Bäume abgeholzt wurden, um den Parkplatz zu schaffen. Ähnliches beim Spielplatz. Deshalb ist es sehr wichtig, dass der Datenerfasser die Daten korrekt erfasst. Denn er kann es sich vor Ort anschauen, der "Experte" kann nur Raten.

Zecke · 2012-11-05 15:08:05

aighes wrote:

Das Ergebnis ist eine schöne Karte. Das ist aber nicht Ziel von OSM. Wir wollen korrekte Daten, aus denen "Experten" (wie du es so schön nennst) u.a. Karten erstellen können.

Mal ganz unvoreingenommen - wenn du sagst "wir", bist du dir eigentlich wirklich sicher, für die Mehrheit der Mapper zu sprechen oder nicht doch eher für die "Experten"?
Das übliche Mantra jetzt mal hin oder her...

ICH will zumindest beides - meine Motivation ist auf jedenfall eine gute Karte, wenn dabei noch eine Datenbank bei rauskommt, die für mehr zu gebrauchen ist, umso besser. Aber die nackte Datenbank ist sicher nicht mein Antrieb!

Gruß,
Zecke

aighes · 2012-11-05 15:25:36

Ich fang mal mit einer Gegenfrage an: Welche eine schöne Karte hättest du denn gerne?

Ich klammer die Nutzerseite mal aus und betrachte nur die Mapper. Da gibt es meiner Meinung nach eine große Gruppe Gelegenheitsmapper, die nur für die Karte mappen, die sie nutzen. Die wissen aktiv nicht wirklich, dass sie eigentlich eine schöne DB mappen wollen, passiv wollen sie aber genau da. Denn nur so ist es eben möglich, dass jeder seine schöne Karte erhält. Siehe Gegenfrage am Anfang.

Wenn ich schön die Bunker auf den Golfplätzen als Strand mappe, sieht das zwar gut aus, aber wenn ich mal den nächsten Strand suche, könnte der Schuss nach hinten losgehen. Oder der Wanderer, der fleißig Wanderrouten erfasst hat. Möchte der nicht auch, dass nicht Wanderer, die etwas am Weg ändern und damit seine Wanderrouten temporär kaputt machen, dass diese die Wanderrouten hinterher auch wieder ganz machen?

viw · 2012-11-05 15:28:51

Zecke wrote:

aighes wrote:
Das Ergebnis ist eine schöne Karte. Das ist aber nicht Ziel von OSM. Wir wollen korrekte Daten, aus denen "Experten" (wie du es so schön nennst) u.a. Karten erstellen können.
Mal ganz unvoreingenommen - wenn du sagst "wir", bist du dir eigentlich wirklich sicher, für die Mehrheit der Mapper zu sprechen oder nicht doch eher für die "Experten"?
Das übliche Mantra jetzt mal hin oder her...
ICH will zumindest beides - meine Motivation ist auf jedenfall eine gute Karte, wenn dabei noch eine Datenbank bei rauskommt, die für mehr zu gebrauchen ist, umso besser. Aber die nackte Datenbank ist sicher nicht mein Antrieb!
Gruß,
Zecke

Das ist alles ganz korrekt. Übrigens die Motivation habe ich auch. Ich schaue gerne auf die Karte und freue mich über das Ergebnis. Aber Mapnik ist nicht alles. Auch wenn OSM render seinen Dienst eingestellt hat und Maperativ nicht so verbreitet ist, sollte man die Brauchbarkeit der Daten nicht auf DIE EINE Karte reduzieren. Alle Navigationsinfos usw. sind doch auch nicht zu sehen. Die werden einfach anders ausgewertet und das kannst du bei anderen Daten nicht. Diesen Vorteil haben wir nur bei OSM.

Und das Problem mit dem Wald ist einfach der Walpparkplatz oder eine asphaltierte Lichtung.

Auchso und wenn jemand auf die Idee kommt die Renderingreihenfolge zu vertauschen ist die schöne arbeit ganz umsonst, weil der Wald nicht durchsichtig ist. Aber mit der Komplexität kommt der Kartenersteller schon klar und der Navikartenersteller sowieso.

wambacher · 2012-11-05 16:05:39

Zecke wrote:

ICH will zumindest beides - meine Motivation ist auf jedenfall eine gute Karte, wenn dabei noch eine Datenbank bei rauskommt, die für mehr zu gebrauchen ist, umso besser. Aber die nackte Datenbank ist sicher nicht mein Antrieb!

Genau anderes rum ist es richtig:
- gute Daten + gute Programme -> gute Karten.
- schlechte Daten + gute Programme -> schlechte Karten

auf kurz: gigo

@Pepito: Man begreift das Problem spätestens dann, wenn man selber eine Karte erstellen oder spezielle Auswertungen machen will; vorher ist das nicht einfach zu verstehen. Ging mir 2009/2010 genauso.

Gruss
walter

kartler175 · 2012-11-05 16:23:04

Für eine schöne Karte braucht man weder Multipolygone noch das Aneinanderkleben von Wegen und Flächen.

Andererseits erschwert die unnötige Verwendungung oder auch die eigentlich notwendige Nichtverwendung von Multipolygonen das Editiern und sowie die Auswertung, sei es für das Rendern als auch für statistische Auswertungen.

Multipolygone sind eine logische Gruppierung mehererer (Multi) Flächen(Polygone=Vielecke), die in einer Beziehung zueinander stehen, und sonst nichts. Multipolygone verkompliziern die Dinge nur und sollten nur sparsam angewendet werden.

Beispiele für eine sinnvolle Nutzung von Multipolygonen:

- Grenze eines Landkreises, der eine Kreisfreie Stadt vollständig umschließt mit der äußeren Grenze des Landkreises als äußeres Polygon und der Grenze der Kreisfreien Stadt als inneres Polygon (z.B. Stadt und Landkreis Rosenheim).
- Gemeindgrenzen mit Exklaven (z.B. Gemeinde Kirchseeon mit Gebietsinseln im gemeindefreien Gebiet des Ebersberger Forstes)
- Nutzungsinseln innerhalb von anderen Nutzungen(Siedlungen, Kiesgruben etc. innerhalb geschlossener Waldgebiete, Inseln in Seen etc)
- getrennte Flächen, die aber logisch zusammengehören (z.B. zersteute Siedlungsflächen, die unter gleichen Namen und mit gleichen Attributen zusamenfasst werden sollen). Das stellt für mich aber schon einen Grenzfall dar.

Ich sehe auch weder einen Nachteil für die Mehrheit der Mapper, wenn sie Multipolygone in der Regel nicht verwenden, noch glaube ich dass man sich wochenlang einlesen muss, um den Sinn von Multipolygonen zu verstehen. Im Gegenteil erscheint es mit einfacher, mit einfachen und klaren Strukturen das Mappen zu beginnen und dann, wenn diese nicht mehr ausreichen, um die vorgefundenen Verhältnisse sinnvoll und logisch strukturiert abzubilden, sich mit komplexeren Strukturen auseinanderzusetzen.

Je einfacher und einheitlicher strukturiert die Daten vorliegen, dest einfacher ist es auch, die Daten in „schönen“ Karten darzustellen. Eine gute Datenbank ist Voraussetzung für eine gute Karte.

Ich finde es nicht schlüssig, sich einerseits nicht bestimmten Regeln unterwerfen zu wollen (aus welchen Gründen auch immer), nur um es den „Experten“ recht zu machen, auf der anderen Seite von den „Experten“ aber zu erwarten, aus dem Durcheinander von Daten „schöne“ Karten, Routenplaner etc. bereitzustellen.

viw · 2012-11-05 17:21:14

kartler175 wrote:

Multipolygone sind eine logische Gruppierung mehererer (Multi) Flächen(Polygone=Vielecke), die in einer Beziehung zueinander stehen, und sonst nichts. Multipolygone verkompliziern die Dinge nur und sollten nur sparsam angewendet werden.

Im Gegensatz zu deiner Definition sind Multipolygone auch Flächen, welche aus mehreren Wegen zusammengesetzt sind. Dies ist zum Beispiel immer dann sinnvoll, wenn sonst dutzende Wege übereinanderliegen. Das passiert zum Beispiel an Stellen wo mehrere Flächennutzungen auf eine Straße treffen, welche dann auch gleich noch die Grenze für Orte/Ortsteile und Verwaltung bildet. Wenn dann dort 5 Wege übereinanderliegen ist das nicht mehr wirklich editierbar. Da würde sich vielleicht anbieten wie bei Grenzen auch das zwei benachbarte Gebiete sich einen Weg teilen.

Auch sollte man Multipolygone bei Gebäuden nicht verachten. Immerhin gibt es welche mit begrüntem Innenhof die komplett vom gebäude eingeschlossen sind. Wie willst du die von jenen unterscheiden die lediglich eine Wiese auf dem Dach haben?

kartler175 · 2012-11-05 21:08:40

viw wrote:

Auch sollte man Multipolygone bei Gebäuden nicht verachten. Immerhin gibt es welche mit begrüntem Innenhof die komplett vom gebäude eingeschlossen sind. Wie willst du die von jenen unterscheiden die lediglich eine Wiese auf dem Dach haben?

Das ist m.E. ein klassischer Anwendungsfall für die Verwendung eines Multipolygons:

kartler175 wrote:

- Nutzungsinseln innerhalb von anderen Nutzungen(Siedlungen, Kiesgruben etc. innerhalb geschlossener Waldgebiete, Inseln in Seen etc)

viw wrote:

Im Gegensatz zu deiner Definition sind Multipolygone auch Flächen, welche aus mehreren Wegen zusammengesetzt sind.

Im OSM-Wiki zu Multipolygonen (http://wiki.openstreetmap.org/wiki/DE:R … einen_Ring) kann ich nichts dazu finden. Darin ist nur von flächenhaften Mitgliedern von Multipoygonen die Rede. Gegenteilige widerspräche auch der Definition des Polygons http://de.wikipedia.org/wiki/Polygon

viw wrote:

Das passiert zum Beispiel an Stellen wo mehrere Flächennutzungen auf eine Straße treffen, welche dann auch gleich noch die Grenze für Orte/Ortsteile und Verwaltung bildet. Wenn dann dort 5 Wege übereinanderliegen ist das nicht mehr wirklich editierbar. Da würde sich vielleicht anbieten wie bei Grenzen auch das zwei benachbarte Gebiete sich einen Weg teilen.

Diese Meinung teile ich überhaupt nicht. Unterschiedliche Typen von Objekten sollten unabhängig voneinander editierbar sein. Wenn sich z.B. durch den Neubau einer Straße sich der Verlauf ändert, möchte ich dies ändern können, ohne dass ich dabei gleichzeitig eventuell die Gemeindegrenze mit ändere. Bitte nicht künstlich Abhängigkeiten schaffen, die in Wirklichkeit nicht existieren. Die erschweren die Editierbarkeit nur. Wenn verschiedene Objekttypen getrennt sind, kann man sie einzeln editieren, ohne andere zu beinträchtigen. Dazu kann man geeigneten in Editoren störende Objektypen ausblenden. Wenn man solche Möglichkeiten nicht nutzen will oder kann, sollte man deswegen nicht fachlich fragwürdige Konstruktionen wählen, um ich die Arbeit leichter zu machen.

aighes · 2012-11-05 21:29:42

kartler175 wrote:

viw wrote:
Im Gegensatz zu deiner Definition sind Multipolygone auch Flächen, welche aus mehreren Wegen zusammengesetzt sind.
Im OSM-Wiki zu Multipolygonen (http://wiki.openstreetmap.org/wiki/DE:R … einen_Ring) kann ich nichts dazu finden. Darin ist nur von flächenhaften Mitgliedern von Multipoygonen die Rede.

Steht doch genau hinter deinem Link (sogar in fett)

Unser Wiki stellt bei solchen Empfehlungen, wie nur für große Flächen, sind immer Stand der Erstellung der Seite. OSM ändert sich aber sehr schnell. Wenn man heute denkt, ein Verfahren ist nur für x nützlich, kann es sein, dass morgen einer auf die Idee kommt, dass es auch für y nützlich ist.

Pfad-Finder · 2012-11-05 21:40:48

kartler175 wrote:

Diese Meinung teile ich überhaupt nicht. Unterschiedliche Typen von Objekten sollten unabhängig voneinander editierbar sein. Wenn sich z.B. durch den Neubau einer Straße sich der Verlauf ändert, möchte ich dies ändern können, ohne dass ich dabei gleichzeitig eventuell die Gemeindegrenze mit ändere. Bitte nicht künstlich Abhängigkeiten schaffen, die in Wirklichkeit nicht existieren. Die erschweren die Editierbarkeit nur. Wenn verschiedene Objekttypen getrennt sind, kann man sie einzeln editieren, ohne andere zu beinträchtigen. Dazu kann man geeigneten in Editoren störende Objektypen ausblenden. Wenn man solche Möglichkeiten nicht nutzen will oder kann, sollte man deswegen nicht fachlich fragwürdige Konstruktionen wählen, um sich die Arbeit leichter zu machen.

Dem kann ich nur zustimmen. Ich habe am Anfang auch gedacht, dass es clever ist, die Begrenzungen von Meadow auf der linken Straßenseite und Wald auf der rechten Straßenseite auf die Straße draufzutackern (es geht um ein Gebiet, das noch 2009 quasi unberührt war). Inzwischen liegt die 2. Generation Bing-Bilder vor, und ich kann den ganzen Sch... wieder mühsam auseinanderrupfen, weil zwischen Straße und Meadow inzwischen massiv scrub gewachsen ist.

Und beim Remappen der Niederlausitz hat ein Stratege unvorsichtig an Grenzen rumgezupft und dabei ordentlich Waldwege mitgerissen.

Keep it simple, keep it stupid. Wenn die Hemmschwelle für Gelegenheitsmapper zu hoch wird, werden sie nix beitragen - und die Experten alleine kriegen die notwendige Flächendeckung nicht hin. Ich weiß, wovon ich rede - in der Uckermark sind die Wälder teilweise heute noch auf Landsat-Status.

Für mich ist OSM am Anfang auch nur Spin-off meiner Outdooraktivitäten gewesen. Zum Glück war ich in meiner ersten Ecke noch fast alles weiß. Hätte ich in der Königsbrücker Heide angefangen (der Beritt von Multipolygon-Freund m****k), wäre ich wahrscheinlich nicht mehr dabei.

aighes · 2012-11-05 21:59:06

Ich kann dir da nur teilweise zustimmen. Es wird in einem komplexen Projekt wie OSM immer Dinge geben, die nicht jeder Gelegenheitsmapper sofort hinzufügen kann und auch keiner verlangt von einem Gelegenheitsmapper, dass er alles gleich perfekt einzeichnet. Wenn er den Wald dann als einen geschlossenen Weg erstellt und den See nicht ausnimmt mit einem MP, dann kann man das hinterher immer noch ändern. Evtl. dem Mapper dies auch erklären, damit er auch was lernt, so er denn will. Aber wer meint, dass man alles in OSM als Einsteiger sofort eintragen kann, der ist ein wenig weltfremd. Das heißt aber auch nicht, dass man es um jeden Preis so kompliziert machen muss, wie möglich.

Pepito · 2012-11-05 22:13:21

wambacher wrote:

- gute Daten + gute Programme -> gute Karten.
- schlechte Daten + gute Programme -> schlechte Karten

Bei Landkarten war es doch vor OSM-Zeiten immer so, dass die Karten fast nie aktuell waren und Waldwege etc. vernachlässigt wurden. War halt unbezahlbar, ständig Kartografen loszuschicken.

Ein wenig ist das ja auch bei Google-Maps auch heute noch so trotz moderner Technik. Allerdings vermessen die meines Wissens auch nicht präzise die Straßen, sondern fahren einfach mit dem Auto und GPS rum. Die Daten mögen bei Google-Maps auch sicherlich professioneller erfasst werden als bei OSM.

In gewisser Weise wird bei OSM noch mehr "dirty" gearbeitet als bei Google Maps, aber dafür enthalten sie Details, die andere Karten nicht haben und sind meist aktueller.

Deswegen meine These:
Sehr gute Daten = Ganz wenige, sehr teure, völlig veraltete Daten, von Kartografen erfasst = Bisherige Karten
Gute Daten = Wenige , teure, bald veraltete Daten, von angelernten Kräften erfasst = Google-Maps
Schlechte Daten = Viele aktuelle Daten, größtenteils von Laien just for fun erfasst = OSM

Sorge ich nun für eine hohe Komplexität der Datenerfassung, kommt man in den Bereich von Google-Maps und wird dann unterliegen.

Pfad-Finder wrote:

...
Keep it simple, keep it stupid. Wenn die Hemmschwelle für Gelegenheitsmapper zu hoch wird, werden sie nix beitragen - und die Experten alleine kriegen die notwendige Flächendeckung nicht hin. Ich weiß, wovon ich rede - in der Uckermark sind die Wälder teilweise heute noch auf Landsat-Status.
Für mich ist OSM am Anfang auch nur Spin-off meiner Outdooraktivitäten gewesen...

So ich auch so. Und bei vielen dürfte es beim Spin-off der Outdooraktivitäten bleiben.

Last edited by Pepito (2012-11-05 22:28:20)

fx99 · 2012-11-05 22:46:12

Pepito wrote:

Deswegen meine These:
Sehr gute Daten = Ganz wenige, sehr teure, völlig veraltete Daten, von Kartografen erfasst = Bisherige Karten
Gute Daten = Wenige , teure, bald veraltete Daten, von angelernten Kräften erfasst = Google-Maps
Schlechte Daten = Viele aktuelle Daten, größtenteils von Laien just for fun erfasst = OSM

These 3 muss ich heftigst widersprechen: alle Untersuchungen zeigen, dass OSM inzwischen bei Straßen mindestens
vergleichbar gut wie alle kommerzielle Anbieter ist.

Die Objekte, über die hier diskutiert wird, sind in den gängigen kommerziellen On-line Karten viel weniger erfasst.

MasiMaster · 2012-11-05 23:40:14

viw wrote:

Wenn dann dort 5 Wege übereinanderliegen ist das nicht mehr wirklich editierbar.

Mal ne Frage:
Was genau fällt so schwer, nur die richtige Linie auswählen? (Ja, auch ich find es momentan nicht ganz einfach.)
Ich nehme an, die Funktion mit der mittlere Maustaste ist bekannt... Vielleicht können wir den Editor verbessern, so dass es einfacher wird eine Linie auszuwählen. (Dann bräuchte man keine komplexen Strukturen um einfache Dinge abzubilden.)

Gibts da Vorschläge/Vorstellungen?
(Um etwas verbessern zu können, muss erstmal das Problem erkannt werden.)
Ich fänd es wahrscheinlich hilfreich, wenn man auf eine doppelte Linie klickt, dann öffnet sich ein Kontextmenü (so wie bei der mittleren Maustaste), und mit dem nächsten Klick wählt man dann seine gewünschte Linie/Fläche aus.
Also ohne das jetzige Flackern und mit Unterstützung von Strg & Umschalt zum Auswählen weiterer Elemente.

aighes · 2012-11-05 23:50:58

Die Probleme sind:

in Kombination mit Straßen/Wegen die auf der Straßenmitte als Linie erfasst sind, dass man das Feld, die Wiese oder was auch immer größer macht, als sie in Wirklichkeit ist.

mach mal eine Mehrfachauswahl mit Objekten, die jeweils mit anderen Objekten zusammen liegen. Da macht es keinen Spaß, nach jedem Objekt, das man der Auswahl hinzufügt auch noch auswählen zu müssen, welches der x Elemente man gerne hätte.

unzählige Fehler, wo eine einmündende Straße an der Fläche endet und nicht mit der Straße verbunden ist.

eine deutlich erhöhte Datenmenge. Je mehr Nodes die doppelt erfasste Geometrie hat, desto mehr spart man.

Last edited by aighes (2012-11-05 23:51:49)

MasiMaster · 2012-11-06 00:09:31

kartler175 wrote:

Unterschiedliche Typen von Objekten sollten unabhängig voneinander editierbar sein. Wenn sich z.B. durch den Neubau einer Straße sich der Verlauf ändert, möchte ich dies ändern können, ohne dass ich dabei gleichzeitig eventuell die Gemeindegrenze mit ändere. Bitte nicht künstlich Abhängigkeiten schaffen, die in Wirklichkeit nicht existieren. Die erschweren die Editierbarkeit nur. Wenn verschiedene Objekttypen getrennt sind, kann man sie einzeln editieren, ohne andere zu beinträchtigen.

+1
Am schwierigsten ist es, eine Hecke o.ä. in ein Multipolygon-Cluster (aus Einzellinien) einzufügen. Diese eigentlich simple Ergänzung artet darin aus, mit mehreren Multipolygonen zu hantieren, Linien zu kürzen, aus einer in die andere Relation zu packen.
Dies ginge auch mit 2 sehr simplen Schritten: Hecke malen, Wiesenkonturabschnitt verschieben/mergen.

kartler175 wrote:

Im OSM-Wiki zu Multipolygonen [...]. Darin ist nur von flächenhaften Mitgliedern von Multipoygonen die Rede.

Hier steht, dass nur Linien Elemente eines Multipolygons sein dürfen.
Ich hatte mal versucht, dies (mMn im Sinne der meisten hier) "up-zu-daten", bin aber gescheitert. Aber das ist ein anderes Thema

Announcement

#201 2012-11-04 02:27:34

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#202 2012-11-04 12:45:54

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#203 2012-11-04 13:08:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#204 2012-11-04 13:52:40

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#205 2012-11-04 16:01:14

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#206 2012-11-04 20:09:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#207 2012-11-04 20:18:27

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#208 2012-11-05 06:23:57

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#209 2012-11-05 12:26:02

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#210 2012-11-05 13:13:51

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#211 2012-11-05 15:08:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#212 2012-11-05 15:25:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#213 2012-11-05 15:28:51

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#214 2012-11-05 16:05:39

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#215 2012-11-05 16:23:04

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#216 2012-11-05 17:21:14

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#217 2012-11-05 21:08:40

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#218 2012-11-05 21:29:42

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#219 2012-11-05 21:40:48

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#220 2012-11-05 21:59:06

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#221 2012-11-05 22:13:21

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#222 2012-11-05 22:46:12

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#223 2012-11-05 23:40:14

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#224 2012-11-05 23:50:58

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#225 2012-11-06 00:09:31

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer