Am 27.05.2011 09:19, schrieb Markus:
Ich möchte gern mal über "quo vadis" sprechen...
Ei, dann hätte das eben bei den Gleisen getippte besser hierher gepasst: Ctrl-C, Ctrl-V: Am 27.05.2011 17:13, schrieb Torsten Leistikow: > Frederik Ramm schrieb am 26.05.2011 22:35: >> man muss das halt beim Rendern in den Griff kriegen. > > Solche Aussagen ohne konkrete Vorschlaege (oder auch > nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort "Linienbündel" Am 26.05.2011 22:35, schrieb Frederik Ramm: > und es wirkte etwas seltsam, dass ein einzelner Way, > der eine Trasse symbolisierte, sich an einem Bahnhof > ploetzlich auffaecherte zu lauter Gleisen und dann hinter > dem Bahnhof wieder zu einer Trasse zusammenlief - > ziemlich unlogisch, aber ich habe immer angenommen, > dass das halt ein voruebergehenden Zustand ist, bis > irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) > Damals schon konnte man beobachten, dass das Auffaechern > der Gleise auf den hohen Zoomstufen zwar gut war, > auf mittleren Zoomstufen aber haessliche schwarze Flecken im > Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... > Das ist eine Herausforderung, der man beim Rendern Herr > werden kann und muss. Eventuell *kann* man dem Renderer > irgendwie helfen, indem man eine Gruppe von Gleisen zu einer > "Bahntrassen"-Relation zusammenfasst und dann neue Funktionalitaeten > im Renderer einbaut, die in der Lage sind, solche gruppierten > linienfoermigen Objekte geeignet zu vereinfachen. > Man muss aber dabei auch den Fall abfangen, dass eine > solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... > Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, > wenn nicht sogar auch am Mapnik herumdrehen muessen. > Das wird nicht leicht, aber danach haben wir eine Karte, die > auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender & Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste "Umetikettierer", die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssenin passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik > In der Zwischenzeit - solang eben die Renderer nicht gut > genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen > anderen Fronten auch so (z.B. einzelne Haeuser, die man auf > kleineren Zoomleveln eigentlich lieber als grosse bebaute > Flaeche anzeigen will). Aber jetzt das Mapping-Rad > zurueckdrehen, beim Mapping zu stagnieren, bloss weil > der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de