The scale bar plugin rescales as the map is zoomed, of course, and occasionally displays integer values. Some of these integer values, though spaced linearily, are non linear in value. E.g., starting snapped to Zoom 15, we have (in miles): 0, 0.36, 0.72 Now we zoom out in small increments, and get: 0, 0.40, 0.80 0, 0.60, 1.20 and other values. All is fine so far. Finally an integer value, but this is fine, too: 0, 2, 4 So we keep zooming, looking for integer values: 0, 1, 3, 5 This is non linear, though spaced linearily. It is hard to tell what is correct. Continuing: 0, 2, 4, 6 linear 0, 2, 5, 8 nonlinear 0, 6, 12 linear Thereafter, we seen to get even integer values which are always linear. Reproducible: Always
OK, this applies when using miles for distance units, and appears to be a problem with truncation to single digit miles where single digits aren't enough. If so, a patch something like this might work: diff --git a/src/plugins/render/mapscale/MapScaleFloatItem.cpp b/src/plugins/render/mapscale/MapScaleFloatItem.cpp index bac707c..bcd90e5 100644 --- a/src/plugins/render/mapscale/MapScaleFloatItem.cpp +++ b/src/plugins/render/mapscale/MapScaleFloatItem.cpp @@ -262,7 +262,7 @@ void MapScaleFloatItem::paintContent( QPainter *painter ) unit = tr("mi"); intervalStr.setNum( j * m_valueInterval / 1000 ); - if ( m_bestDivisor * m_valueInterval > 3800 ) { + if ( m_bestDivisor * m_valueInterval >= 10000 ) { intervalStr.setNum( j * m_valueInterval / 1000 ); } else { The trouble is, I don't really understand the code. For instance, m_bestDivisor * m_valueInterval as shown above clearly represents a distance in units of meters throughout the code, but the map scale behaves as if units are miles/1000 in the above. That is, the scale uses an int if the scale is longer than 3.8 miles, and a qreal if it is less. (And I don't know what a qreal is, anyway; I don't know QT. (But I am finally looking at c++.))
I am doing bug triaging as Google Code-In 2014 student. This bug is already fixed in some previous commits, expected behaviour takes place now.
Closing based on comment #2, please feel free to reopen if this still happens with current git master or a later release.
Nope, still active as of 1.9.2; is that current enough? What commits address the issue?
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.