[Talk-de] Konzept für Daten, Karte und Renderer
Heiko Jacobs
heiko.jacobs at gmx.de
Fr Mai 27 18:02:21 UTC 2011
Am 27.05.2011 09:19, schrieb Markus:
> Andererseits brauchen wir kartografisch sinnvolle Generalisierung,
> und routentechnische Berechnungseffizienz.
Beides fängt m.E. mit einem gemeinsamen Schritt an:
Zusammenfassen, was zusammen gehört, s.a. Ctrl-C+Ctrl-V-Mail ;-)
Linienbündel etc.:
Sowohl beim Rendern ( Radweg/Fahrbahn sollen sich nicht überdecken),
als auch beim Generalisieren (Straße mit/ohne Radweg) als auch
beim Routen (Rafahrer über Fahrbahn oder Radweg) braucht man die
Zusammenhänge paralleler Strukturen.
Einige Teilaufgaben brauchen paar mehr (Verdrängung Straße contra Fluss),
die andere nicht brauchen (oder? Hmmm... "nicht zu weit rechts fahren,
sonst *platsch* ;-) ), aber der geometrische Ansatz ist derselbe.
Das geht alles in Richtung GIS als Zwischenschicht.
Oder sowas in der Art.
Jedenfalls etwas, das Koordinaten nicht nur umbildet von
geographisch/WGS84 in Karten-x/y, sondern richtig analysiert
und verändert:
Was ist parallel zueinander?
Was stößt in einem Winkel darauf?
Was endet kurz davor?
Und all das darf sich nicht von unsauberem Mapping beeinflussen
lassen wie unterschiedlich dichte und verteilte Stützpunkte
bei parallelen Fahrbahnen, Unterbrechungen durch Brücken
(die tw. versetzt zueinander sind, wenn was in spitzem Winkel
gekreuzt wird etc. Oder beim parallelen Radweg fehlt die Brücke ...), ...
Und muss dennoch erkennen, ob ein eine Weile paralleler Radweg
doch irgendwo abschwenkt ...
Und dann:
Was gehört davon zusammen, was nicht?
Was für Aufgabe A (Verdrängung), B (Rendern), C (Routen), D (...), ...?
Und wie speichert man diese Zusammengehörigkeiten ab?
Wie hält man die aktuell, wenn jemand die Basisgeonetrie ändert?
Und wie steuert man die, wenn die Automagik falsch zusammenstöpselt?
Oder nur manuell, aber was, wenn die fehlt?
Gruß Mueck
Mehr Informationen über die Mailingliste Talk-de