Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QGIS 3.34 RC Layout manager: dragging any item changes one or both X,Y coordinates to 9999999.000 #55240

Open
1 of 2 tasks
rareitmeyer opened this issue Nov 10, 2023 · 7 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Print Layouts Related to QGIS Print Layouts, Atlas or Reporting frameworks

Comments

@rareitmeyer
Copy link

What is the bug or the crash?

On Debian with QGIS 3.34 RC. I have several layouts from earlier versions of QGIS. When I open up one of those and try to drag an item (scalebar, text, map) it often disappears from the layout. When I look at item properties, one or both coordinates are now 9999999.000. Hand-editing the coordinate back to something smaller does not make the object re-appear, it often just causes the other coordinate to become 9999999.000 if it was not already.

I'm also seeing this in a layout I created in 3.34 RC. Was fine when I first made it, but after several cycles of opening the project, editing the layout and map, shutting down QGIS, ..., I'm seeing it in the new layout as well.

Steps to reproduce the issue

  1. Make a layout
  2. Add a bunch of text items, a scale bar, a map, and an attribute table or two
  3. move items around a little
  4. save layout
  5. save project
  6. close QGIS
  7. repeat steps 3-6 a half dozen times
  8. If you move an item a little, does the item disappear off screen and show an "absurd" coordinate?

Versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>
QGIS version 3.34.0-Prizren QGIS code revision ffbdd67
Qt version 5.15.8
Python version 3.11.2
GDAL/OGR version 3.6.2
PROJ version 9.1.1
EPSG Registry database version v10.076 (2022-08-31)
GEOS version 3.11.1-CAPI-1.17.1
SQLite version 3.40.1
PostgreSQL client version 15.3 (Debian 15.3-0+deb12u1)
SpatiaLite version 5.0.1
QWT version 6.1.4
QScintilla2 version 2.13.3
OS version Debian GNU/Linux 12 (bookworm)
       
Active Python plugins
plugin_reloader 0.7.9
db_manager 0.1.20
processing 2.12.99
QGIS version 3.34.0-Prizren QGIS code revision [ffbdd67](https://github.com/qgis/QGIS/commit/ffbdd678812) Qt version 5.15.8 Python version 3.11.2 GDAL/OGR version 3.6.2 PROJ version 9.1.1 EPSG Registry database version v10.076 (2022-08-31) GEOS version 3.11.1-CAPI-1.17.1 SQLite version 3.40.1 PostgreSQL client version 15.3 (Debian 15.3-0+deb12u1) SpatiaLite version 5.0.1 QWT version 6.1.4 QScintilla2 version 2.13.3 OS version Debian GNU/Linux 12 (bookworm)

Active Python plugins
plugin_reloader
0.7.9
db_manager
0.1.20
processing
2.12.99

Supported QGIS version

  • I'm running a supported QGIS version according to the roadmap.

New profile

Additional context

cat /etc/apt/sources.list.d/qgis.sources

Types: deb deb-src
URIs: https://qgis.org/debian
Suites: bookworm
Architectures: amd64
Components: main
Signed-By: /etc/apt/keyrings/qgis-archive-keyring.gpg

@rareitmeyer rareitmeyer added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Nov 10, 2023
@YoannQDQ YoannQDQ added the Print Layouts Related to QGIS Print Layouts, Atlas or Reporting frameworks label Nov 10, 2023
@yoalix
Copy link

yoalix commented Nov 12, 2023

Experiencing this as well on 3.32 and 3.34 on MacOs Sonoma 14.1 intel version.
The scale bar on 3.32 would grow infinitely and cause the program to crash. On 3.34 the scale bar appears diagonally and when tried to move, it will position x and y to 9999999.000
and cannot edit.

@col16
Copy link

col16 commented Mar 21, 2024

I got this too, but discovered the issue was that my layout CRS wasn't set correctly. When I fixed that, everything started behaving as normal.

@matt-needle
Copy link

matt-needle commented Sep 9, 2024

I am experiencing this with 3.38.0 on Windows 10. It is not fixed by setting CRS however. The layout items move in layout space, nothing to do with the scale / scalebar.

Creating a new profile, or updating QGIS to 3.38.2 does not resolve it.

@johnwbryant
Copy link

Also running into this issue on 3.38.1 on Ubuntu.
Peek 2024-09-20 10-44

@nyalldawson
Copy link
Collaborator

Can someone supply a sample project which demonstrates this? I've tried to reproduce but failed.

@nyalldawson nyalldawson added the Feedback Waiting on the submitter for answers label Sep 23, 2024
@johnwbryant
Copy link

The attached layout template has a scale bar item that seems to exhibit the behaviour. When I create a new layout from the template, I can't change the position of this item.

layout.zip

@YoannQDQ
Copy link
Contributor

Related to #57489

nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Sep 30, 2024
Instead of always calculating the scale along the bottom of the
map, expose a choice of methods to the user (along bottom,
middle, top, or average of the three measurements)

For new scalebars, default to the average method, which better
handles the scenario where the scale at the top or bottom of
the map cannot be calculated (eg when the top/bottom of the map
falls just outside valid areas for the map's crs)

This fixes one of the most common scenarios which cause scale
bar widths to blow out to massive sizes

Refs qgis#55240
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Sep 30, 2024
This can happen when eg a broken item size causes a nan position,
which breaks the layout size calculation and results in nan or
massive x/y values. Restoring these leads to a broken
layout which cannot be interacted with.

Refs qgis#55240
@agiudiceandrea agiudiceandrea removed the Feedback Waiting on the submitter for answers label Sep 30, 2024
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Sep 30, 2024
Instead of always calculating the scale along the bottom of the
map, expose a choice of methods to the user (along bottom,
middle, top, or average of the three measurements)

For new scalebars, default to the average method, which better
handles the scenario where the scale at the top or bottom of
the map cannot be calculated (eg when the top/bottom of the map
falls just outside valid areas for the map's crs)

This fixes one of the most common scenarios which cause scale
bar widths to blow out to massive sizes

Refs qgis#55240
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Print Layouts Related to QGIS Print Layouts, Atlas or Reporting frameworks
Projects
None yet
Development

No branches or pull requests

8 participants