Am 30. März 2011 18:29 schrieb Wolfgang <wolfg...@ivkasogis.de>: > Am Mittwoch 30 März 2011 16:55:43 schrieb M∡rtin Koppenhoefer: >> Bringen die site-relationen da Vorteile gegenüber schlichten >> Multipolygonen? > > Die Multipolygone betreffen (im konkreten Fall) Gebäude, die in der Mitte > einen Innenhof haben. > > Die sites haben z.B. den Vorteil, dass das Gelände wie auch die gemeinsam > genutzten Gebäude (Turnhallen, Verwaltung, Pausenhalle ...) in beiden sites > unabhängig voneinander eingetragen werden können. Eine Auswertung muss nur der > jeweiligen site folgen, um richtig zuordnen zu können.
das geht mit Multipolygonen genauso, man kann ways den relationen ja beliebig zuordnen. (Gut, beim Rendern gibt es evlt. Probleme durch doppelte Geometrien, aber das hast Du durch die Site genauso). > Ich sehe die site eine Art organisatorischer Sammlung, in der verschiedene > Objekte unabhängig von ihrer Lage sich zugeordnet werden. Sie hat keinen > Einfluss auf die geometrische Form der Abbildung. Verstehe ich nicht, in beiden Fällen weisst man doch Geometrien zu? > Die Aufgaben des Mulipolygons sehe ich eher darin, verschachtelte Objekte > voneinander zu trennen, mit direktem Einfluss auf die Abbildung. Die > Möglichkeit, mehrere Polygone als "outer" anzugeben, ist ein großer Vorteil, > wenn es darum geht, gleichartige Objekte einander zuzuordnen und zusätzlich > von anderen "inner" abzugrenzen. Diese Vorteile spielt das Multipolygon aus, > wenn es darum geht, z.B. ein Waldgebiet korrekt zuzuordnen, mit Lichtungen und > verschiedenen Waldteilen, ohne die einzelnen Multipolygone anschließend in > eine site packen zu müssen. Ähnliches dürfte für Wohngebiete und verstreute > Ortslagen gelten. Hier muss man aber sehen, dass die Zurordnung der einzelnen > Bestandteile über den "outer" läuft, während das "inner"-Polygon davon andere > Objekte abtrennt. jaja, schon klar. > Im konkreten Fall hätte ich das Problem, mit dem Grundstück bereits ein alles > umschließendes "outer"-Polygon zu haben, das zweimal angegeben geben muss, da > es beiden Schulen zugehört. und bei der Site? Ist das genauso. > Die darauf befindlichen Gebäude zusätzlich als > "outer" zu taggen, würde einem Renderer zwangsläufig Kopfschmerzen bereiten, > wäre aber organisatorisch richtig. Man könnte den Gesamtumriss als outer taggen, und die Gebäude, die nicht Teil sind, ausschließen mit inner. Was übrigbleibt ist die Schule. Probleme bieten allerdings Nodes und Ways (Nichtpolygone), die man ausschließen möchte, das stimmt. > Würde man sie geometrisch konsequent als > "inner" taggen, währe das jetzt organisatorisch nicht mehr korrekt. Außerdem > würden einige Gebäude in beiden, sich ohnehin überlappenden Polygonen als > "outer/inner"- Objekte auftauchen, andere nur in einem. Hinzu kämen die Nodes, > die ja schon vom Namen her nicht in ein Polygon passen. > > Man sollte immer versuchen, das Werkzeug zu benutzen, dass für die vorgegebene > Aufgabe am nützlichsten ist, und nicht ein Werkzeug so weit aufbohren, dass es > zwar für alles verwendbar ist, aber nur mit Klimmzügen und Tricks (und sich > dann über das Rendering wundern). ach, Du renderst die Sites schon? Wie hast Du da das Problem gelöst, dass manche Geometrien doppelt vorkommen? > Wir haben heute ja auch Bagger, um eine Autobahn zu bauen und benutzen > trotzdem noch den Spaten, um Tulpen zu pflanzen. Im Prinzip ginge es auch > anders, aber das wäre dann jeweils ein Fall für "Wetten dass". Die Welt der Daten und Software ist eben nicht so einfach übertragbar auf die physische Welt. Es macht ja auch kaum Sinn, sich eine Single (für die Jüngeren: so hiessen früher mal die kleinen Schallplatten) die man auch in Deutschland kaufen könnte, aus Cupertino schicken zu lassen, andererseits kaufen sehr viele Leute aus Deutschland einzelne Lieder genau dort ein... Oder anders gesagt: wenn der Bagger bereits samt Baggerführer vor der Tür steht, den Spaten ich mir aber erst noch von Hand schmieden müsste, dann lasse ich vielleicht auch den kleineren Graben vom Bagger ausheben... Gruß Martin _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
