[QGIS-Developer] QGIS composer export - issue with projection, scale & scalebar ?

[Nyall Dawson]

On Thu, 15 Nov 2018 at 03:41, kimaidou <kimaidou at gmail.com> wrote:
>
> Hi all,
>
> Sorry for my previous message, which (I just realize) can appear rude if you have not received the first one.

I think it was worded ok and didn't come across rude (to me at least).

>>> I have created 2 very simple QGIS projects (attached with data)
>>>
>>> * 1 vector polygon grid 1km X 1km (GeoJSON), created with the Vector processing tool.
>>> * 1 OpenStreetMap TMS background layer (EPSG:3857)
>>> * 1 A4 composer with a map taking full size, and a scale bar
>>> * 1 project in EPSG:3857 & its brother in EPSG:2154 (French proj)
>>>
>>> Issues noted:
>>>
>>> * In the composer, the scale bar does not fit with the 1km grid, in both projects.
>>> * After defining the same scale (1:10 000) in the composers, the view are really different in the 2 projects (see attached PDF)
>>>
>>> I know projections are biased representations of the reality, but as a user perspective, this 2 behaviours really seem like issues. Every time a user prints a map and take the A4 paper, he is condident he will be able to use his ruler to measure things and convert to real distances according to the scale. Or report N times the scale bar segments to get distances.
>>>
>>> I am like someone who just discovers the Earth is not flat...
>>>
>>> NB: I have tested this behaviour only in 2.18.

It's the same in 3.x.

My 2c: I don't actually believe there's an issue here. QGIS scale bars
*ALWAYS* use ellipsoidal distances, regardless of the projection (and
have for longer than I've been involved in the project, so since some
version earlier than 1.7).
This means you'll see differences between a 1km size grid created in a
some local projection vs the scale bar's size, because the grid size
is a cartesian size measurement based on a projected CRS, vs distances
measured on the ellipsoid. The differences will be more extreme for
CRSes which are bad for distance/area preservation, especially 3857.

I think the solution here is really just education -- we need to make
sure users know that 3857 is unsuitable for anything but web maps, and
that it's THEIR responsibility to make an informed decision what the
correct CRS is for their project.**

Nyall

** in reality, we'll never win this battle, and there'll always be
uninformed, untrained users pushing out junk results out based on 3857
calculations.