[Talk-de] Konzept für Daten, Karte und Renderer

Heiko Jacobs heiko.jacobs at gmx.de
Fr Mai 27 17:32:04 UTC 2011


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





Mehr Informationen über die Mailingliste Talk-de