Hallo, Am Freitag 15 Oktober 2010 13:32:06 schrieb NopMap: > > Wenn sie beim Import pauschal ausmultipliziert werden, entstehen mehrere > sich überlagernde Objekte, die insgesamt sinnlos sind, das Renderergebnis > ist Zufall aber jedes für sich sieht korrekt aus. Den Fehler findet man nur > noch unter größten Schwierigkeiten.
Ich glaube, man muss hier verschiedene Dinge trennen, die zu häufig in einen Topf geworfen werden und nagel hier mal 7 Thesen an die Listentür ( :-) ) 1. In der real existierenden Welt gibt es Dinge, die nicht nur eine Eigenschaft einer Gruppe haben. Als einfaches Beispiel für Farben mag das Zebra herhalten, als sinnvolle Tags für OSM sehe ich hier den Wirt, der tatsächlich Speisen mehrerer Küchen zubereitet, häufige Beispiele dafür cucina=greek;italian oder greek;turkish; und es gibt Haltestellen, an denen - für den Fahrgast praktisch, für den geplagten OSM-Renderer-Schreiber ärgerlich - mehr als eine Linie des ÖPNV halten. 2. Diese Dinge dürfen für OSM nicht einfach, weil es der Renderer so will, unter den Tisch fallen. Es ist für mich nicht akzeptabel, dass der Mapper sagt, hier gibt es zwar griechische und italienische Gerichte, aber ich esse lieber griechisch, also tagge ich nur greek (oder umgekehrt). 3. Diese Dinge können auf verschiedene Weise verwaltet werden. Beim ÖPNV werden die Linien und ihre Haltestellen in eine Relation gepackt. Das vermeidet das Semikolon an der Haltestelle. Sieht wie eine prima Lösung aus. Leider ergibt sich aber beim Rendern der Haltestelle das gleiche Problem wie bei jedem anderen Modell - die Haltestelle gehört zu mehreren Relationen , zu mehreren Linien, und bei dieser Auswertung tauchen - schwupp - die verschiedenen Liniennummern (Eigenschaften) wieder auf. Damit will ich nicht kritisieren, dass hier Relationen benutzt werden, das ist beim ÖPNV sinnvoll. Ich will nur aufzeigen, dass dadurch die Anhäufung von Eigenschaften nicht verhindert wird, da sie fatalerweise in der Wirklichkeit existiert. Folgerichtig wäre es zwar möglich, auf das Semikolon bei Gaststätten zu verzichten, indem eine Relation aller griechischen, italienischen,... Restaurants erzeugt wird. Bei Auswertung der einzelnen Gaststätte hat der Renderer aber wieder das gleiche Problem - 2 oder noch mehr Relationen, weil der verd. Koch sich einfach nicht auf eine Küche festlegen will. Gewissermaßen kocht er damit OSM-widrig. Leider sind wir noch nicht mächtig genug, um diesem Treiben ein Ende zu setzen ( :-) ) (für den, der Ironie nicht erkennt). Daraus folgt, dass die Relation das Problem nicht löst, sondern versteckt. Mehr noch - sie ruft die Relations-Kritiker auf den Plan, die zwar keine Alternative wie z.B. eine Kollektion anbieten, sich aber jede Sammel-Relation verbieten. Was mach jetzt der verzweifelte Mapper, der die Küche korrekt taggen will, die Relation nicht darf, das Semikolon nicht soll und die doppelte Küche sieht? Macht er 2 Nodes, eine für jede Küche, worauf alle Auswertungen mit 2 Restaurants reagieren? Oder verbindet er die 2 Nodes mit dem Gebäude in einer Site-Relation?. Das wäre ein gangbarer Weg, der aber nichts daran ändert, dass der Renderer vor dem Problem steht, wie er jetzt das darstellen soll. Abgesehen davon, dass dieses Tagging sachlich falsch wäre, schließlich wird nicht in 2 Küchen in einem Gebäude, sondern in einer Küche gekocht. 4. Das Problem liegt in den Scheuklappen vieler Aktiven. Es ist letztlich egal, ob einer der heutigen Renderer eine Sache richtig darstellt. Ich wiederhole es nochmal: Wir taggen nicht für irgendeine Anwendung, sondern ausschließlich die Realität, und zwar so gut, wie es uns zur Zeit möglich ist. Das bedeutet nicht, dass man jetzt unbedingt cucina=kretian taggen muss, wenn der Wirt hauptsächlich Gerichte aus Kreta anbietet. Greek ist auch dafür sachlich richtig (gehört ja dazu) und für alle Anwendungen leichter auswertbar. Kretian ist andererseits aber auch nicht falsch - ein Ermessensfall, in dem ich Sympathie für die Bezeichnung greek hätte (abgesehen davon, dass ich die Unterschiede in verschiedenen griechischen Küchen einfach unterstelle, ohne sie zu kennen). In Bezug auf die deutsche Küche gilt ähnliches: bavarian, bremian, hamburgian, rhinian - Stopp!! Vielleicht für ein Subtag. Der Ausländer wird german taggen und Schweinebraten mit Ködel (und Sauerkraut!!) darunter verstehen. 5. OSM ist eine überholte Bezeichnung. Das Projekt wurde von Steve Cost mal Openstreetmap getauft, weil er sich damals eine offene Straßenkarte vorstellte. Das hätte vermutlich jeder am Anfang so gesehen. Inzwischen ist das Projekt aber mutiert zu einer offenen Geodatensammlung. Es werden viele Dinge gemappt, die kein Renderer darstellt oder kein Renderer darstellen kann. Einkaufszentren in 3D zu mappen ist zur Zeit - betrachtet aus Sicht der Renderer - sinnfrei. Es ist aber nichtsdestotrotz sachlich richtig und wird auch gemacht. 6. Der Lizenzwechsel ist nur die logische Antwort auf die Wandlung des Projektes. In Zukunft werden die grafischen Abbilder der Datenbank nicht mehr zwangsläufig frei sein. Sie können in der Nutzung beliebig beschränkt werden. Frei dagegen wird der Zugriff und die Auswertung der Daten sein. Das wird kaum bedeuten (können), dass Mapnik oder Osmarender jetzt für die Mapper kostenpflichtig werden, beide sind Opensource und damit jederzeit auf einem anderen Server wieder für alle einsetzbar. Aber es wird deutlich, dass der Zweck des Projektes eben nicht darin liegt, Karten zu erzeugen, sondern Geodaten zu ermitteln und frei zugängig zu machen. (Konsequenter weise müsste das Projekt sich eigentlich umbenennen. Das würde ich aber nicht empfehlen, da der Name OSM gerade beginnt, ein wenig bekannter zu werden.) Freie Zugängigkeit der Daten bedeutet nicht nur für die Erstellung von Landkarten. Eine weitere Auswertung ist das Routing, deren Vertreter ebenfalls häufig versuchen, ein ihnen angenehmes Tagging zu erreichen. Frei zugängig bedeutet aber auch die Auswertung in Statistiken, wissenschaftlichen Untersuchungen und vieles mehr. Gerade damit heben wir uns ab von den anderen geografischen Datensammlern, deren Augenmerk zur Zeit ausschließlich auf der wirtschaftlichen Erstellung von mehr oder weniger genauen Karten für den Massenmarkt (Verkauf) liegt. Fangen wir aber jetzt an, den Renderern zuliebe die Wirklichkeit zu verbiegen, um ein "schönes" Bild zu erzeugen, machen wir uns selbst überflüssig. Wir sind dann nicht besser als der Hersteller dieser grauenhaft fehlerhaften Karten für Google. 7. Es bleibt die Diskussion über das Semikolon. Mich hat die Implementation 5 Minuten und 3 Programmzeilen gekostet. Das ist zugegebenermaßen nicht ganz fair. da die App neu ist. Wer eine bessere Möglichkeit weiß, multiple Eigenschaften in den Daten so abzubilden, dass es für den Mapper einfach anzuwenden ist, melde sich bitte. Aber nicht mit dem üblichen Semikolon - Protest - Geheul, sondern konstruktiv. Das einfache Verbieten oder Ignorieren von Dingen, die es real gibt, nur weil es sich zur Zeit (oder nie) von einem Renderer darstellen lässt, widerspricht jedem Grundsatz von OSM und ist für mich nicht akzeptabel. Vielen Dank denen, die bis hier gelesen haben. Gruß, Wolfgang ps. Nop: Das geht nicht gegen dich. Ich habe hier einfach auf das (bei mir) letzte Posting geantwortet. Ich meine aber, diese Meinung passt in diesen Thread. lg, d.o. _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
