<div dir="ltr"><div><div><br><br>On Mon, Sep 4, 2017 at 10:49 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Mon, Sep 4, 2017 at 8:32 PM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> > On Thu, Aug 31, 2017 at 7:21 PM, Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>><br>> >><br>> >> I am not sure if v.in.ogr should be modified to use this special reading<br>> >> mode for one single OGR supported format. The GDAL/OGR API is very<br>> >> convenient because applications do not need to bother about particular<br>> >> formats. If we start implementing code for particular formats in v.in.ogr,<br>> >> we might open a Pandora's box...<br>> ><br>> > Interleaved reading for OSM input has been added to v.in.ogr in trunk<br>> > r71464.<br>><br>> Thanks for that!<br><br></div>v.in.ogr has been further updated in trunk r71532 to use new features available with GDAL 2.2.<br><br></div>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.<br><div><div>><br>> > OSM import remains challenging. For v.in.ogr you need define a custom<br>> > OSM_CONFIG_FILE because the default osmconf.ini file will add all tags not<br>> > defined with attributes into "other_tags", potentially causing buffer<br>> > overflow. OSM polygons are overlapping which is correct because e.g.<br>> > administrative boundaries for multiple administrative levels are imported.<br>><br>> Perhaps we can cook up some examples in the GRASS Wiki for common use<br>> cases (or add to the manual page of v.in.ogr)?<br></div><div><br></div><div>Still a TODO.</div><div><br></div><div>Markus M<br></div><div>><br>> markusN<br><br></div></div></div>