[Marble-bugs] [Bug 199259] marble openstreetmap text and limit line are blurred

[Torsten Rahn]

https://bugs.kde.org/show_bug.cgi?id=199259





--- Comment #12 from Torsten Rahn <rahn kde org>  2010-08-13 13:14:23 ---
Hi Dennis,

Yes, that would be cool. But it's not exactly trivial.

A.) First step would be to "lock" zooming to optimized zoom values that "match"
about the original tile resolution. Bernhard Beschow had already created a
patch for that. Problem was that the code looked a bit hackish. I think it's
still inside bernhard's gitorious repo.
I see two problems with the result:
1.) The quality is still inferior compared to the original tiles since we
resample the tiles as part of the projection adjustment (since our rasterizer
provides a generic pipeline for all projections.
2.) Personally I'm not very fond of zooming in steps. It steals the whole
experience. So we should at least have a "blurry" animation in between.

B.) Second step to improve the quality could be to introduce a
ScrollareaTextureMapper (as an alternative to the
AbstractScanlineTextureMapper). Initially the ScrollareaTextureMapper would be
used just in case the projection selected in Marble would match the projection
in which the tiles get provided (e.g. Mercator or Equirectangular). Creating a
ScrollAreaTextureMapper would also reduce CPU usage and make Marble faster for
the flat map rendering. The result would match the quality of the tiles of
course. Problem would be how to get the animations in between zoom level
changes. And of course the quality would only be the same as for the tiles as
long as the user views OpenStreetMap in Mercator projection. If he uses
anything else (Globe or Equirectangular) then the quality will just be as it is
right now.


C.) Third step would be to assemble in-memory tiles that fit the projection
currently used. This would be done only if the source projection doesn't match 
the tile projection. This wouldn't improve quality much for e.g. the
Equirectangular projection when looking at OSM. But it would improve speed for
that particular projection.

So all these changes would be quite time consuming with limited benefit. Best
outcome would be that Marble would be fast for OpenStreetMap and Mercator
Projection. Speed would still be the same for Globe. And display quality would
only change noticably for the Mercator projection.

Really the best solution would be to render OSM in vectors using GeoPainter.
Then it doesn't matter which projection the user uses: it would always be
crystal clear and fast! The only backdraw could be that initially the rendering
would have other shortcomings over Mapnik (labels would initially maybe not
follow the streets or whatever).

 Andrew had started to work on that with his osmannotation plugin. Thibault
Gridel is currently laying the foundation for a proper implementation of
rendering GeoData. Once GeoData can be easily rendered we'd need to find a
solution how to render OSM in chunks (similar to the Texture Tile loading).
Once that is done we have a really nice fast renderer :-)

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.