[GRASS-dev] v.in.osm working?

[Markus Metz]

On Thu, Aug 24, 2017 at 3:37 PM, Even Rouault <even.rouault at spatialys.com>
wrote:
>
> On jeudi 24 août 2017 15:34:11 CEST Markus Metz wrote:
>
> > On Thu, Aug 24, 2017 at 11:15 AM, Even Rouault <
even.rouault at spatialys.com>
>
> >
>
> > wrote:
>
> > > > You can use v.in.ogr directly for OSM PBF files (
>
> > > >
>
> > > > http://gdal.org/drv_osm.html).
>
> > > >
>
> > > >
>
> > > >
>
> > > > BTW, with GDAL 2.2.1, using OGR_INTERLEAVED_READING=YES does not
work
>
> >
>
> > for
>
> >
>
> > > > me (empty vector).
>
> > >
>
> > > Caution: you cannot just specify OGR_INTERLEAVED_READING=YES and loop
>
> >
>
> > over layers as usual. See the "Interleaved reading" section of
>
> > http://gdal.org/drv_osm.html
>
> >
>
> > I see, thanks for the hint. That means v.in.ogr must be changed to use
the
>
> > special reading mode, or OGR_INTERLEAVED_READING must be unset in
v.in.ogr,
>
> > together with a warning.
>
>
>
> If you unset OGR_INTERLEAVED_READING, the classical read pattern (loop
over layers, and for each layer, loop over its features) will work only for
small osm/pbf files where the number of features in each layer isn't larger
than 100K.
>
> For larger files, OGR_INTERLEAVED_READING=YES and the special reading
pattern described in drv_osm.html is needed.

OK, I have disabled OSM import for trunk and relbr72 (r71543,4), because it
results in empty vectors or incomplete imports.

I am not sure if v.in.ogr should be modified to use this special reading
mode for one single OGR supported format. The GDAL/OGR API is very
convenient because applications do not need to bother about particular
formats. If we start implementing code for particular formats in v.in.ogr,
we might open a Pandora's box...

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170831/21bbb678/attachment.html>