On Thu, Jul 07, 2011 at 12:05:13AM +0200, Stephan Wolff wrote: > Moin! > > Am 06.07.2011 14:19, schrieb Florian Lohoff: > >On Wed, Jul 06, 2011 at 12:27:29PM +0200, Sven Sommerkamp wrote: > >>Die Frage ist doch immer wieviel ist ausreichend und macht Sinn? > > > >Nein - es gibt kein ausreichend. Jeder darf so viel und so detailreich mappen > >wie er will solange er nicht dadurch den anderen die nutzung kaputt macht. > > Aber woran erkennt ein Mapper, ob nicht irgendeine Nutzung kaputt > geht oder schwerwiegende Nachteile hat?
Es faengt mal da an wo du Objekte entfernst und gegen irgendwas anderes ersetzt. Um bei meinem Beispiel zu bleiben - Straße als Linie oder als Flaeche? Wenn ich die Linie einfach drin lasse ZUSAETZLICH zur Flaeche mache ich nichts kaputt. Wenn ich die Flaeche ANSTATT der Linie drin habe bricht dort das ganze Routing ins essen. > Einzelne hinzugefügte POIs sind meist unproblematisch. Sobald man > ein bestehendes Objekt in mehrere Einzelteile zerlegt, gibt es meist > auch Nachteile. Hast du ein Beispiel? > Wie könnte man z.B. bei einer Bushaltestelle mit Bank und Unterstand > die Lage der drei Einzelobjekte (Haltestellenmast am Fahrbahnrand, > Bank hinter dem Fußweg, Unterstand 5 m in Fahrtrichtung) abbilden > ohne eine bestehende Auswertung zu schädigen? Was wird denn da heute ausgewertet? Der bus_stop - Aber den kann ich doch auch dem Masten abbilden oder? Den Unterstand als building und die bench da drin moeglicherweise. > Soll man eine Straßeneinmündung mit drei kleinen Verkehrsinseln mit > allen Details erfassen, wenn dadurch zehn zusätzliche Wegstücke und > fünf zusätzliche Abbiegerelationen nötig werden? Wie kann der Mapper > erkennen, ob es dann Probleme bei der TMC-Auswertung gibt? Wenn da eine signifikante Verkehrsinsel ist trenne ich die einmuendenden Wege immer auf. Das hat fuer mich den Grund das sich ein moegliches "Bitte wenden" eines routing moeglicherweise aendert. Und ja - dann sind das halt mehrere Wegstuecke und das TMC muss mit weit komplexeren dingern klarkommen - Siehe Autobahnkreuz. > >Wenn hier einige die Straßen als Flaechen mappen wollen - bitte sehr - > >solange > >halt fuer die routingalgorhythmen die mittellinie da bleibt. > > Selbst wenn keine bestehenden Daten geändert werden müssen, > erschweren drei eng benachbarte Linien anderen Mappern die Arbeit > und provozieren falsch verbundene Wege. Das Zerstoert aber keine Nutzung - Und etwas nur nicht zu machen weil es Arbeit bedeutet ist ja eben der grund warum das OpenStreetMap ist. Es gibt genuegend leute - zumindest auf einer langen Zeitachse um auch Komplexe dinge zu stemmen. Und das mit dem verbundene Linien ist ja auch ein Softwareproblem. Josm/Potlatch koennten da durchaus mal meckern wenn Flaechen und Linien (Highway mit Landuse) verbunden werden. > >Was ist daran nicht durchschaubar wenn ich eine flaeche highway=pedestrian > >area=yes habe und darauf viele nodes mit amenity=bench? > > Dieses Beispiel ist leicht verständlich. > Andere Konstrukte, insbesondere mit mehreren beteiligten Relationen, > können Mapper abschrecken oder fehlerträchtig in Erfassung und > Auswertung sein. > > Fast jede Detailerfassung hat Vor- und Nachteile. Oft müssen wir mit > den Nachteilen leben. Aber ich finde es legitim, auch Entscheidungen > gegen Detailerfassung zu Gunsten eines einfacheren, generalisierten > Datenmodells zu treffen. Also Relationen sehe ich noch nicht so als das Problem. Ich sehe eher das Problem das Relationen mittlerweile als alle moeglichen arten von "Ich sammle mal Objekte in einer Relation" missbraucht werden. Dafuer sind die aber gar nicht da. Flo -- Florian Lohoff [email protected] „Für eine ausgewogene Energiepolitik über das Jahr 2020 hinaus ist die Nutzung von Atomenergie eine Brückentechnologie und unverzichtbar. Ein Ausstieg in zehn Jahren, wie noch unter der rot-grünen Regierung beschlossen, kommt für die nationale Energieversorgung zu abrupt.“ Angela Merkel CDU 30.8.2009
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
