<div dir="ltr"><br><br>On Thu, Jun 27, 2019 at 7:37 AM Micha Silver <<a href="mailto:tsvibar@gmail.com">tsvibar@gmail.com</a>> wrote:<br>><br>><br>> On 26/06/2019 23:44, Markus Metz wrote:<br>><br>><br>><br>> On Wed, Jun 26, 2019 at 10:16 PM Micha Silver <<a href="mailto:tsvibar@gmail.com">tsvibar@gmail.com</a>> wrote:<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > micha@TP480:code$ ogrinfo -so ../GIS/Ashalim/ashalim_train_pts.gpkg<br>> > INFO: Open of `../GIS/Ashalim/ashalim_train_pts.gpkg'<br>> >       using driver `GPKG' successful.<br>> > 1: ashalim_train_pts (Point)<br>> > 2: layer_styles (None)<br>> ><br>> ><br>> > The style ??!!<br>> ><br>> ><br>> > I removed that "layer_styles" table from the gpkg db, and deleted the entry from gpkg_contents, and now the import works.<br>> ><br>> > Who would have guessed ?<br>> ><br>> > I suppose that I should have specified the layer in v.import to avoid this problem.<br>><br>> Yes, specifying the layer should work.<br>><br>> I have seen this layer_styles layer before in other GPKG files but don't know what this is good for. GDAL documentation at<br>> <a href="https://gdal.org/drivers/vector/gpkg.html">https://gdal.org/drivers/vector/gpkg.html</a><br>> does not mention any style information.<br>><br>><br><div>> It comes from QGIS, where you can save a default layer styling directly into the gpkg. Very convenient, but I never thought it would appear to GRASS as a second layer without geometry or CRS.</div><div><br></div><div>This is not GRASS, it is OGR that recognizes it as a separate layer without geometry or CRS. I guess ogr2ogr skips this layer because there are no geometries in it.</div><div><br></div><div>In theory, v.in.ogr could skip empty OGR layers, but in practice it is not always easy to get the feature count of a layer, it depends on the data format. Sometimes, e.g. for OSM pbf, you need to read the whole OGR datasource to figure out the number of features per layer.</div><div><br></div><div>In v.in.ogr, there are already a number of special cases for specific OGR-supported formats, and I would like to keep these format-specific treatments to a minimum, avoiding yet another special case for GPKG + empty layer. Ideally, the GPKG driver of OGR would not expose such empty or special layers.<br></div><div><br></div><div>Markus M<br></div></div>