[GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file

Veronica Andreo veroandreo at gmail.com
Wed Oct 10 06:45:23 PDT 2018


Hola :)

El mié., 10 oct. 2018 a las 15:04, Markus Metz (<
markus.metz.giswork at gmail.com>) escribió:

>
>
> On Tue, Oct 9, 2018 at 8:32 PM Veronica Andreo <veroandreo at gmail.com>
> wrote:
> >
> > Hi Markus,
> >
> > Many thanks for your answer :)
> >
> > El mar., 9 oct. 2018 a las 19:42, Markus Metz (<
> markus.metz.giswork at gmail.com>) escribió:
> >>
> >>
> >>
> >> On Tue, Oct 9, 2018 at 2:11 PM Veronica Andreo <veroandreo at gmail.com>
> wrote:
> >> >
> >> > A follow up:
> >> >
> >> > If I convert the gpkg to shapefile and import into GRASS, then all
> points are imported:
> >> >
> >> > v.import input=central.shp layer=central output=central --overwrite
> >> > Check if OGR layer <central> contains polygons...
> >> > Creating attribute table for layer <central>...
> >> > Importing 30 features (OGR layer <central>)...
> >> > -----------------------------------------------------
> >> > Building topology for vector map <central at testing>...
> >> > Registering primitives...
> >> > Input <central.shp> successfully imported without reprojection
> >> >
> >> > v.db.select -c central | wc -l
> >> > 30
> >> >
> >> > What could be the problem with gpkg and how to test further??
> >>
> >> The problem is that the bounding box included in the gpkg does not
> cover all points: these missing 2 points are outside the bbox embedded in
> the gpkg. As a safety measure, v.in.ogr applies a spatial filter using the
> input layer's bbox to exclude corrupt features (previously observed in some
> shapefiles). This spatial filter is passed directly to OGR and as a
> consequence, OGR provides only 28 and not 30 points to v.in.ogr.
> >
> >
> > And how is this bounding box created/defined, I was not aware of it.
>
> It is created by the software that created that layer.
> > I only converted from .kml to gpkg and then imported into GRASS.
>
> In this case something must have gone wrong when converting from kml to
> gpkg.
> >
> >>
> >> I am not sure what to do about this. Disable this safety check again?
> >
> >
> > Maybe the bb safety check makes sense for features other than points,
> dunno. Others can for sure tell some use cases that I am not aware of. But
> I can say that it is pretty striking to see that some features are "eaten
> and lost" when importing into GRASS while ogr and others show everything.
> >
> > What about a flag? Import all by default and the safety check with a
> flag? Or at least a note in the manual page of v.in.ogr
>
> I would rather disable this safety check if it does more harm than good.
>

+1

Vero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20181010/5886102d/attachment.html>


More information about the grass-dev mailing list