[Qgis-user] Help with scales in print layouts for geographic CRS

[Jorge Gustavo Rocha]

Hi,

Thanks to Greg, Patrick, Nicolas and Nyall for the good discussion.

I never used lat/lon based layouts before and the result can be odd. I 
was trying to make it work, but it is not easy. The layout must include 
a warning about the difference in scales along the axes.

As Nyall said, additional logic could be added to detect scale changes 
along different directions. That introduces newer configurable 
parameters to decide the percentage of change to warn the users.

I think that it would be enough to warn users when they start a layout 
with a lat/lon coordinate system. The warning can be as simple as: 
"Please consider the usage of a projected CRS for your layout. Be aware 
that lat/lon printed maps can have different scales on the x and y axes.".

Regards,

Jorge

On 07/04/22 02:51, Nicolas Cadieux via Qgis-user wrote:

> Hi Nyall,
>
> That would be a "nice to have"!
>
> Nicolas
>
> On 2022-04-06 9:13 p.m., Nyall Dawson via Qgis-user wrote:
>> On Thu, 7 Apr 2022 at 10:26, Greg Troxel <gdt at lexort.com> wrote:
>>>
>>> Nyall Dawson <nyall.dawson at gmail.com> writes:
>>>
>>>> In all cases (projected OR geographic) the scalebar logic is:
>>>>
>>>> 1. Create a horizontal line across the width of the layout map
>>>> 2. Calculate the length of that line using great circle/ellipsoidal
>>>> calculations, based on the project's ellipsoid settings.
>>>> 3. Compare the length of the ellipsoidal line vs the map width to
>>>> calculate the corresponding scale
>>> That is a very straightforward approach with easy-to-understand
>>> semantics.
>>>
>>>> So qgis scalebar calculations are ALWAYS based on great
>>>> circle/ellipsoidal lengths*.
>>> And more precisely, a true geodesic between two points varying in x and
>>> with constant y in the layout CRS.  For north-up (at least ish)
>>> projections, that means a line of constant latitude.
>>>
>>> For a lat/lon CRS in the layout, at mid latitudes, it's going to mean
>>> that the scale in the y axis is smaller by about 110km/70km; a 
>>> square in
>>> lat/lon is taller than it is wide (and plus it's not a square, but
>>> that's less obvious).  Equivalently, a square on the ground has a 
>>> larger
>>> difference in longitude than it does in latitude.  Or maybe I have that
>>> backward, but using lat/lon in a layout does not preserve shapes.
>>>
>>> This is what I was trying to get at: a single concept of scale is 
>>> really
>>> only valid for a projection that has the same scale in x and y.  
>>> Which I
>>> think is true iff the projection is conformal.  And it's only truly
>>> valid if the scale doesn't change over the layout, which is probably
>>> ~never exactly true, but many projections aim to have it remain close
>>> enough to be treated as constant (e.g. UTM).
>>>
>>> Which is a long way of getting around to "if you are using lat/lon as
>>> the axes in your layout, either you are doing something odd on purpose
>>> or you probably should rethink your approach."  If you really do mean
>>> it, I would find the explanation of why interesting.
>> All correct, indeed!
>>
>> I've been thinking about introducing a new warning when exporting
>> layouts, which would look something like this:
>>
>> 1. For each scale bar, look at the referenced map
>> 2. Measure the scale using multiple lines, each across the
>> top/middle/bottom horizontally and left/center/right vertically
>> 3. Compare these scale values, and if any differ by more than XXX %
>> then show a warning to the user. Something like "The scale for map 1
>> varies from 1:xxxx to 1:yyyyy across different parts of the map.
>> Consider using an alternative form of representing the map scale (such
>> as a grid overlay), as the scale bar may be misleading for this map."
>>
>> What do you think?
>>
>> Nyall
>>
>>
>>>> * Unless the project itself is set to not use ellipsoidal calculations
>>>> and only use planar calculations, in the project properties dialog
>>> Presumably those calculations are in the project CRS's xy space, and
>>> would typically (when used sensibly) be grid distance in UTM, some 
>>> State
>>> Plane Coordinate System, or similar.
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>