Bug 199259 - marble openstreetmap text and limit line are blurred
Summary: marble openstreetmap text and limit line are blurred
Status: CONFIRMED
Alias: None
Product: marble
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE RPMs Linux
: NOR normal with 61 votes (vote)
Target Milestone: ---
Assignee: Torsten Rahn
URL:
Keywords:
: 216915 247410 271430 303203 303537 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-07 11:21 UTC by Philippe ROUBACH
Modified: 2019-03-09 12:32 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
OSM tiles in a browser, in Mappero and in Marble (406.85 KB, image/png)
2010-08-13 10:23 UTC, Dennis Nienhüser
Details
Blurry display with white lines (756.89 KB, image/png)
2011-12-30 20:00 UTC, Matthieu Pupat
Details
still blurry rendering. i zoomed fully out and then, using only the scrollwheel, in. (36.36 KB, image/png)
2013-02-14 16:02 UTC, Philipp A.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe ROUBACH 2009-07-07 11:21:05 UTC
Version:           0.8 RC1 (using 4.2.95 (KDE 4.2.95 (KDE 4.3 RC1)), Mandriva Linux release 2010.0 (Cooker) for i586)
Compiler:          gcc
OS:                Linux (i686) release 2.6.30.1-desktop-1mnb

when using openstreetmap with marble you can see that :

- town names are blurred
- town limit lines are blurred
- coast line is blurred
Comment 1 Torsten Rahn 2009-07-10 18:34:44 UTC
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.
Comment 2 Torsten Rahn 2009-07-10 18:38:01 UTC
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.
Comment 3 Philippe ROUBACH 2009-09-04 12:16:52 UTC
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 ?
Comment 4 Torsten Rahn 2009-09-04 13:48:16 UTC
> 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.
Comment 5 Michael G. Hansen 2009-12-01 11:44:55 UTC
*** Bug 216915 has been marked as a duplicate of this bug. ***
Comment 6 Jakob Lehmann 2010-01-21 05:15:56 UTC
Confirmed in KDE SC 4.3.90.
Comment 7 Torsten Rahn 2010-01-21 12:01:17 UTC
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.
Comment 8 Dennis Nienhüser 2010-08-11 23:08:04 UTC
*** Bug 247410 has been marked as a duplicate of this bug. ***
Comment 9 Alexey Charkov 2010-08-11 23:22:53 UTC
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?
Comment 10 Torsten Rahn 2010-08-12 12:09:52 UTC
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.
Comment 11 Dennis Nienhüser 2010-08-13 10:23:29 UTC
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).
Comment 12 Torsten Rahn 2010-08-13 13:14:23 UTC
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 :-)
Comment 13 slickqt 2010-09-03 04:16:07 UTC
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.
Comment 14 Nicolas Dumoulin 2011-02-08 10:30:13 UTC
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
Comment 15 Anders Lund 2011-03-01 21:47:39 UTC
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.
Comment 16 Dennis Nienhüser 2011-04-24 22:18:29 UTC
*** Bug 271430 has been marked as a duplicate of this bug. ***
Comment 17 Bernhard Beschow 2011-05-12 21:24:48 UTC
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
Comment 18 Philippe ROUBACH 2011-05-12 22:02:46 UTC
thanks to all
Comment 19 Nicolas Dumoulin 2011-05-13 09:09:50 UTC
Oh yes. A great thank you to you, and to all marble dev. Now, I will be able to show an awesome geographic application!
Comment 20 Dennis Nienhüser 2011-05-14 13:13:05 UTC
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];
Comment 21 Dennis Nienhüser 2011-05-15 16:17:23 UTC
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
Comment 22 Matthieu Pupat 2011-12-30 19:43:46 UTC
Which version is this fixed in? I can still see the behavior using Marble 1:4.7.4-1.fc16 on Fedora 16.
Comment 23 Torsten Rahn 2011-12-30 19:54:29 UTC
(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.
Comment 24 Matthieu Pupat 2011-12-30 20:00:45 UTC
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).
Comment 25 Dennis Nienhüser 2011-12-30 20:11:45 UTC
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?
Comment 26 Matthieu Pupat 2011-12-30 20:40:15 UTC
That was it. The map is fine now. Thank you very much for the help.
Comment 27 Dennis Nienhüser 2012-07-15 09:03:40 UTC
*** Bug 303537 has been marked as a duplicate of this bug. ***
Comment 28 Dennis Nienhüser 2012-08-13 17:16:16 UTC
*** Bug 303203 has been marked as a duplicate of this bug. ***
Comment 29 Philipp A. 2013-02-14 16:02:13 UTC
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.
Comment 30 Philipp A. 2013-02-14 16:06:29 UTC
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.
Comment 31 Richard Llom 2014-03-12 12:35:47 UTC
(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.
Comment 32 Paul Ortyl 2015-02-21 16:43:16 UTC
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?
Comment 33 Dennis Nienhüser 2015-02-22 18:28:39 UTC
If you activate Mercator projection and zoom only using the +/- keys, does the result match your expectations (look like in a web browser)?
Comment 34 Paul Ortyl 2015-02-22 18:52:26 UTC
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.
Comment 35 Philippe ROUBACH 2019-03-09 12:32:49 UTC
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