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

Error saving file only after converting multipolygon to single polygons #58942

Closed
2 tasks done
secretmango opened this issue Oct 2, 2024 · 6 comments · Fixed by #58954
Closed
2 tasks done

Error saving file only after converting multipolygon to single polygons #58942

secretmango opened this issue Oct 2, 2024 · 6 comments · Fixed by #58954
Assignees
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter!

Comments

@secretmango
Copy link

secretmango commented Oct 2, 2024

What is the bug or the crash?

I have a geopackage layer with a huge multipolygon on it. It is the result of an overpass turbo OSM extraction, then I cut off the overlap with a different layer. Then I changed the coordinate system to a projected pseudo-mercator one.

All fine until now.

I want to convert the huge polygon into separate polygons, so that I can geoprocess them individually.

I use the "vector - geometry - multi- to single polygon" tool and it works instantly.

Then I try to save the temporary layer and always get the same crash.

Steps to reproduce the issue

  1. Convert a multipolygon layer to single polygons. I will attach the geopackage for you.

demo-file-multipolygon.gpkg.zip

  1. try to save or export the resulting single-polygon layer in geopackage format
  2. it always errors out
Temporary Draft layer cannot be made permanent.
Error: Error writing object:
Object creation error (OGR-Fehler: failed to execute insert : UNIQUE constraint failed: this-file-cannot-be-saved.fid)
Objekterzeugungsfehler (OGR-Fehler: failed to execute insert : UNIQUE constraint failed: this-file-cannot-be-saved.fid)
... repeat
... stops after 1001 failed attempts

Versions

QGIS-Version 3.34.11-Prizren QGIS-Codezweig Release 3.34
Kompiliert gegen Qt 5.15.14 Laufendes Qt 5.15.15
Python-Version 3.12.6
GDAL-Version 3.8.5
PROJ-Version 9.3.1
EPSG-Registraturdatenbankversion v10.098 (2023-11-24)
GEOS-Version 3.12.2-CAPI-1.18.2
SQLite-Version 3.45.1
PDAL-Version 2.6.3
PostgreSQL-Client-Version 16.4
SpatiaLite-Version 5.1.0
QWT-Version 6.2.0
QScintilla2-Version 2.13.4
BS-Version Fedora Linux 40 (Toolbx Container Image)
       
Aktive Python-Erweiterungen
alkisplugin 2.0.56
address_search 0.1
SAGisALKISSearch 1.0.2
projektcheck 1.3
qgis-maptiler-plugin 3.3.2
OSMDownloader 1.0.3
MetaSearch 0.3.6
db_manager 0.1.20
grassprovider 2.12.99
processing 2.12.99

Supported QGIS version

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

New profile

Additional context

this only happens with this exact converted file. All others didn't give an error. renaming, checking the name, checking again, changing locations, ... all dont work.

Restarting QGis also didnt work.

Using a BTRFS Filesystem.

@secretmango secretmango added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Oct 2, 2024
@secretmango
Copy link
Author

secretmango commented Oct 2, 2024

I see that all these files get saved, but stop at around 100KB. They are also saved to my home folder, which is strange. Normally the files are saved to the same folder the qgz project is in, which is not my home folder.

example-saved-file.zip

@nyalldawson nyalldawson self-assigned this Oct 3, 2024
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Oct 3, 2024
Respect the OnConvertFormatRegeneratePrimaryKey layer property when
making a temporary layer permanent.

This ensures that processing outputs which require primary key
regeneration will correctly get new primary keys when they are
initially run with a memory layer output, and then later that
memory layer is made permanent

Fixes qgis#58942
@secretmango
Copy link
Author

So @nyalldawson , the issue is that the converted layer lacks unique IDs per polygon?

I will happily test the latest commit, but would also appreciate a workaround in the meantime, as you seem to know what it going wrong here.

Thanks!

@secretmango
Copy link
Author

secretmango commented Oct 8, 2024

Hi, could you tell me when a new release is planned, so that this fix ends up on devices?

Or in the meantime if you know of any workaround?

I currently cannot proceed my work with this error 😅

I am trying to build latest QGis myself using QtCreator, after giving up on RPM packaging for now. I am unsure if Qt6 packages can already be used, as to my knowledge QGis is still fully using Qt5?

@troopa81
Copy link
Contributor

troopa81 commented Oct 8, 2024

Hi, could you tell me when a new release is planned, so that this fix ends up on devices?

QGIS 3.40 released the 25th of october, no backport is planned so far.

I am trying to build latest QGis myself using QtCreator, after giving up on RPM packaging for now. I am unsure if Qt6 packages can already be used, as to my knowledge QGis is still fully using Qt5?

Both Qt6 and Qt5 are working now, but the official is still Qt5. I don't know the policy for package on redhat/fedora but you'd probably have to build it yourself.

@nyalldawson
Copy link
Collaborator

@secretmango

Or in the meantime if you know of any workaround?

The easiest workaround would be to remove the fid field from the output layer before saving as gpkg. Alternatively if you directly set the processing tool to store the result in a gpkg it will automatically do this for you (on all current versions)

@secretmango
Copy link
Author

thanks! Well that was obvious, they are all the same XD

Instead I did

  1. Open field calculator
  2. Click "update existing field"
  3. Select the "fid" column
  4. as function use @row_number

done

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!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants