ogr2ogr append GeoPackage styles to PostGIS public.layer_styles table if present
Feature description
When I use ogr2ogr to load a GeoPackage that has layer styles into a specific schema of a PostgreSQL/PostGIS database, I get an incomplete layer_styles table in that schema:
If this was instead appended to an existing layer_styles table in the public schema with the missing attributes completed, then these styles would be immediately available for use when subsequently loading these layers into QGIS.
Additional context
No response
Could you detail the exact command(s) you use with a sample dataset, the initial state of your database ?
- I first created a new PG16 database called "gisdata" and installed the PostGIS extension, then created a schema called "uk".
- I then loaded a separate layer through QGIS into the uk schema and saved symbology for that layer to the database, thus creating the public.layer_styles table.
- I then ran the following ogr2ogr command to load the attached GeoPackage (test_styles.zip) containing 2 layers that have styles:
ogr2ogr -f "PostgreSQL" PG:"host=localhost port=5432 user='postgres' password='password' dbname='gisdata' active_schema='uk'" "C:\temp\test_styles.gpkg" --config PG_USE_COPY YES
This results in a new uk.layer_styles table in the uk schema:
Which is incomplete when compared to the equivalent in the public schema.
If these rows were complete and instead appended to the public.layer_styles table then QGIS would be able to use these styles.
If these rows were complete and instead appended to the public.layer_styles table then QGIS would be able to use these styles.
oh I see. Hum, I understand your end goal, but this would require inserting pretty specialized logic in ogr2ogr/the PG river to take into account a QGIS specific behavior:
- the PG driver is instructed (by you) to copy content in the 'uk' schema
- and you would expect it to understand that the 'layer_styles' has a particular semantics, and that the f_table_catalog and f_table_schema columns must be filled.
This is technically do-able but I'm not sure if we want to add that level of sophistication in the PG driver
My end goal is ultimately a smooth workflow between complimentary OSGeo technologies, but I understand your reservations.