[GRASS-dev] v.in.osm working?
Markus Metz
markus.metz.giswork at gmail.com
Fri Oct 6 07:52:08 PDT 2017
On Mon, Sep 4, 2017 at 10:49 PM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Mon, Sep 4, 2017 at 8:32 PM, Markus Metz
> <markus.metz.giswork at gmail.com> wrote:
> > On Thu, Aug 31, 2017 at 7:21 PM, Markus Metz <
markus.metz.giswork at gmail.com>
> >>
> >> 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...
> >
> > Interleaved reading for OSM input has been added to v.in.ogr in trunk
> > r71464.
>
> Thanks for that!
v.in.ogr has been further updated in trunk r71532 to use new features
available with GDAL 2.2.
BTW, when translating OSM data with ogr2ogr, the results might differ
between GDAL 2.1 and GDAL 2.2. Similarly, when importing OSM data with
v.in.ogr, results differ between GDAL 2.1 and GDAL 2.2, but are equivalent
to the corresponding ogr2ogr version.
>
> > OSM import remains challenging. For v.in.ogr you need define a custom
> > OSM_CONFIG_FILE because the default osmconf.ini file will add all tags
not
> > defined with attributes into "other_tags", potentially causing buffer
> > overflow. OSM polygons are overlapping which is correct because e.g.
> > administrative boundaries for multiple administrative levels are
imported.
>
> Perhaps we can cook up some examples in the GRASS Wiki for common use
> cases (or add to the manual page of v.in.ogr)?
Still a TODO.
Markus M
>
> markusN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20171006/aec76d5d/attachment.html>
More information about the grass-dev
mailing list