Bug 199259

This is due to the fact that Marble uses pixmap data. There are two possible solutions to solve this issue:

- Render vector data on the client: This is a solution that we are aiming for. However this isn't easy to achieve.
- Make zooming "stick" to zoom levels that show the text as sharp as possible.

Currently there's work by Bernhard Beschow going on to make the second solution work.

This is due to the fact that Marble uses pixmap data. There are two possible solutions to solve this issue:

- Render vector data on the client: This is a solution that we are aiming for. However this isn't easy to achieve.
- Make zooming "stick" to zoom levels that show the text as sharp as possible.

Currently there's work by Bernhard Beschow going on to make the second solution work.

i made this bug report because i use digikam
digikam now uses marble as geo layer to show photo geolocalization.
they don't want to dedicate time to develop geo software it's not their pb. i understand.

the Marble default theme has very poor map
the openstreetmap is better but blured and you say it's a long way to have a solution. 
is there any plan for Marble using Google maps if it is a faster solution ?

> the Marble default theme has very poor map

The Marble default theme is designed to be low on resources and provide a simple topographic map.

> is there any plan for Marble using Google maps
> if it is a faster solution ?

There are no such plans at the moment:
* We can not legally offer Google Maps data.
* Google Maps are based on texture tiles. So if we used them then they'd appear "blurry" as well.

*** Bug 216915 has been marked as a duplicate of this bug. ***

Confirmed in KDE SC 4.3.90.

If enough people help we might be able to resolve this for KDE 4.5 in a proper way. If not then it might very well take until KDE 4.6 or KDE 4.7.

*** Bug 247410 has been marked as a duplicate of this bug. ***

As far as I know, Navit renders vector OSM data on the client side. I wonder if their code could be reused in Marble at little development cost?

Alexey: Unfortunately not:

* Just because another piece of software is opensource doesn't mean that you can go and copy code verbatim. Marble has got a completely different architecture and a completely different set of classes compared to Navit.

* Also the license (mostly GPL) is incompatible with Marble's library (LGPL). 

* Marble is not only an application but also a pretty clean Qt library that is fully based on Qt style APIs and architecture. Navit on the other hand is a bit of a cludge of different pieces, different programming languages and different licenses from what I recall.

Created attachment 50117 [details]
OSM tiles in a browser, in Mappero and in Marble

I'm willing to devote some time to make zooming stick to OSM levels. Torsten, if you can get me up to speed wrt to existing code that'd be great.

Screenshot shows a comparison of our current rendering compared to Mappero and OSM shown in a browser (openstreetmap.org).

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 :-)

the tile map is more and more popular,  it would be better to imporve the display of tile map in marble.
though render vector data in marble is possible, it's another big project,like qgis,in practice, the performance of render every paint from vector data is not affordable compare to display a tile image,especially the vector data is large.
since marble is not a serious gis program, i don't think render the vector(raster) data is the solution for the issue.

Hi,

Does someone have any news about this job?
Although it seems to be not so easy, as marble becomes so wonderfull, it will be great to have a clean tile rendering for promoting the software for non-OSM convainced users.

Thank you

While i appreciate the coolness of soft animation, the blurryness overrides that by reducing usage value. 

I think it would be good if a theme could indicate a preferred projection, and that for bitmap tiles, marble should go to the 1:1 scale and use that as a base for zooming, so it would safely land there again.

Currently, with osm marble apperarently never lands on the 1:1 scale of osm levels, so it allways look blurry.

*** Bug 271430 has been marked as a duplicate of this bug. ***

Git commit 723ff6ff21a69c4681866711a03307bd3a0bb16d by Bernhard Beschow.
Committed on 12/05/2011 at 20:21.
Pushed by beschow into branch 'master'.

let +/- buttons set the radius to the native map width for each tile zoom level

BUG: 199259

M  +18   -0    src/lib/MarbleMap.cpp     
M  +3    -0    src/lib/MarbleMap.h     
M  +20   -2    src/lib/MarbleWidget.cpp     
M  +24   -2    src/lib/TextureLayer.cpp     
M  +4    -1    src/lib/TextureLayer.h     

http://commits.kde.org/marble/723ff6ff21a69c4681866711a03307bd3a0bb16d

thanks to all

Oh yes. A great thank you to you, and to all marble dev. Now, I will be able to show an awesome geographic application!

Hey Bernhard, awesome work, thanks :-)

I've got a little problem with the patch: When setting still image quality to high or when panning the map after using +/- (at which point I get sharp tiles), I get blurred images again. It seems to be caused by an off-by-one error, can you look at the following patch which fixes that for me?

diff --git a/src/lib/TileScalingTextureMapper.cpp b/src/lib/TileScalingTextureMapper.cpp
index 63274fb..2ec719f 100644
--- a/src/lib/TileScalingTextureMapper.cpp
+++ b/src/lib/TileScalingTextureMapper.cpp
@@ -146,7 +146,7 @@ void TileScalingTextureMapper::mapTexture( GeoPainter *geoPainter, ViewParams *v
                 StackedTile *const tile = m_tileLoader->loadTile( stackedId );
                 tile->setUsed( true );
 
-                const QSize size = QSize( qCeil( rect.right() - rect.left() ), qCeil( rect.bottom() - rect.top() ) );
+                const QSize size = QSize( qRound( rect.right() - rect.left() ), qRound( rect.bottom() - rect.top() ) );
                 const int cacheHash = 2 * ( size.width() % 2 ) + ( size.height() % 2 );
                 const TileId cacheId = TileId( cacheHash, stackedId.zoomLevel(), stackedId.x(), stackedId.y() );
                 QPixmap *im = (*m_cache)[cacheId];

Git commit 23d654cfecac6aa64e975add4b872a40455d2c63 by Dennis Nienhüser.
Committed on 14/05/2011 at 14:47.
Pushed by nienhueser into branch 'master'.

Use qRound instead of qCeil to fix an off-by-one error.
CCBUG: 199259

M  +1    -1    src/lib/TileScalingTextureMapper.cpp     

http://commits.kde.org/marble/23d654cfecac6aa64e975add4b872a40455d2c63

Which version is this fixed in? I can still see the behavior using Marble 1:4.7.4-1.fc16 on Fedora 16.

(In reply to comment #22)
> Which version is this fixed in?

It's  fixed  in  Marble  Version  1.2 (KDE  4.7): if  you  press  the  + or  - key  for  zooming  then  you  always  get  a  mostly  sharp  display.   

> I can still see the behavior using Marble
> 1:4.7.4-1.fc16 on Fedora 16.

Created attachment 67262 [details]
Blurry display with white lines

Sorry but this is not the case for me. The display is blurry and there are white lines (I guess at the tiles borders).

The white lines are from the coordinate grid. You can deactivate it in the Legend tab on the left.

Which projection are you using, maybe Globe? Globe is never sharp. Please make sure "Mercator" is selected as projection in the "Map View" tab on the left.

Is the map also blurry in Mercator projection?

That was it. The map is fine now. Thank you very much for the help.

*** Bug 303537 has been marked as a duplicate of this bug. ***

*** Bug 303203 has been marked as a duplicate of this bug. ***

Created attachment 77296 [details]
still blurry rendering. i zoomed fully out and then, using only the scrollwheel, in.

> Which projection are you using, maybe Globe? Globe is never sharp.
> Please make sure "Mercator" is selected as projection in the "Map View" tab on the left.

then this isn’t fixed.

also for me (KDE 4.10) i don’t see anything snapping to sharp resolutions. if i carefully zoom manually with the slider until the next zoom level is loaded, i can get something that could be considered *almost* sharp (but it’s still not the exact resolution)

if i use the scrollwheel, nothing is ever sharp.

————————

this bug will only be fixed once we use vector data or give users an option to only use zoom levels that correspond to pixmap resolutions. i’m reopening.

until [+]/[-] buttons and the scrollwheel don’t map to +/- keys (zoom-to-sharp), or we use vector data, users will mostly see blurry and only diving into the documentation and/or bugreports or wildly trying keybord shortcuts and having the idea that the only the mercator projection can get them to a sharply rendered map.

thus, noone simply opening the application will be able to see a sharp image somehow, and this bug isn’t fixed.

(In reply to comment #30)
> until [+]/[-] buttons and the scrollwheel don’t map to +/- keys
> (zoom-to-sharp), or we use vector data, users will mostly see blurry and
> only diving into the documentation and/or bugreports or wildly trying
> keybord shortcuts and having the idea that the only the mercator projection
> can get them to a sharply rendered map.
> 
Yep, I just did that, to find finally this bug report ... :-/

> thus, noone simply opening the application will be able to see a sharp image
> somehow, and this bug isn’t fixed.
> 
Agreed.

I was about to suggest Mercator as default, but I must say it is just to nice to start with the globe, which you can spin around as you like. :-)
So maybe an "Auto" view mode could help here, which auto switches between mercator and globe at specific zoom levels - and this could be set as default then.

About the zoom levels I don't really understand.

Hi,

this is the one BUG that prevents me from using Marble, that would otherwise be fine for its purpose.

We need a special mode for rasterised maps, that show ONLY the original bitmaps without scaling or other transformations.  Just imitate what web browsers are able to do.
I was experimenting about 10 years ago with trivial map display, the only zoom levels I allowed were powers of two. This trivial application (coded directly agains X11 libraries) was delivering MUCH better display for rasterised maps than I can see in Marble.

Maybe we need something like Projection: "Native"

The goal should be: the map must look at least as good (and sharp) as in web browser.

Can comeone point me to the right piece of code in Marble where such change could be implemented?

If you activate Mercator projection and zoom only using the +/- keys, does the result match your expectations (look like in a web browser)?

In this case it looks acceptable.

To make it practicable I would have to bind +/- keys to scroll wheel on the mouse.

If we assume this functionality is already working, then we still need the following:
* (option) restriction for mouse vertical wheel to stay at the right zoom level (as with +/- keys)
* (option) to disable coordinate grid lines or make them fall on exact pixels and thus unblur them.
* (option) for very high resolution displays a 2x and 3x mode would be needed, so that the map stays sharp and readable at the same time (with 2x and 3x I mean repeat every pixel 4 and 9 times, this was the working solution for OSM maps for N900, which had 267ppi)

As it was stated in comments above, not many users try +/- keys. It means the casual user will NEVER see OSM maps in its proper quality. It can certainly drive users away, as it was the case for me in the last few years.  I was trying new versions of Marble from time to time to see that OSM maps are still screwed.

kde app 18.12.2
kde plasma 5.15.2
kde framework 5.55.0
qt 5.12.1

marble 2.2.20

standard OSM map : problem still there
vector osm map : road well drew but text still blur

for the 2 maps if i choose mercator and use "+" or "-" it' is better but not good

I would suggest to make a note in the configuration, where it says "Map Quality": add in a subtitle that "the choice of projection also affects the visual quality".

(In reply to Jérôme Borme from comment #36)
> I would suggest to make a note in the configuration, where it says "Map
> Quality": add in a subtitle that "the choice of projection also affects the
> visual quality".

That sounds like a good idea indeed! Thanks for the suggestion!