<div dir="ltr"><div><br><br>On Thu, Nov 16, 2017 at 10:02 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote<br>> > On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>> >><br>> >> On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz<br>> >> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> >> > On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <<a href="mailto:hellik@web.de">hellik@web.de</a>><br>> >> > wrote:<br>> >> >><br>> >> >> Background of the question in subject: the GRASS algs in upcoming QGIS3<br>> >> >> are working with v.external linked data.<br>> >> >><br>> >> >> I've seen some modules doesn't work with such kind of data.<br>> >> >><br>> >> >> Is there maybe a list already available?<br>> >> ><br>> >> > It depends also on the format that is linked in with v.external. For all<br>> >> > formats that do not have a key column (e.g. shapefile), attributes are<br>> >> > not<br>> >> > accessible, and attributes would get lost when modifying the<br>> >> > geometries.Therefore it is generally not safe to link vector data with<br>> >> > v.external. In many cases it does not make sense to use v.external<br>> >> > linked<br>> >> > data with simple features, instead vector data should be imported to get<br>> >> > true topology. If upcoming QGIS3 is working with v.external linked data,<br>> >> > the<br>> >> > GRASS interface of QGIS is effectively broken.<br>> >><br>> >> I have turned this into a potential new snippet for the v.external manual:<br>> >><br>> >> ----- snip -----<br>> >> Due to these data model differences <em>v.external</em> does not work<br>> >> with all data formats. In general, for all formats that do not have a<br>> >> key column (e.g. SHAPE file), attributes are not accessible, and<br>> >> attributes<br>> >> would get lost when modifying the geometries. Therefore it is generally<br>> >> not safe to link vector data with <em>v.external</em>. In many cases it<br>> >> does not make sense to use <em>v.external</em> linked data with simple<br>> >> features, instead vector data should be imported with <em>v.import</em><br>> >> or <em>v.in.ogr</em> to get true topology support. Importantly, point<br>> >> cloud data which do not have topology, can be linked with<br>> >> <em>v.external</em><br>> ><br>> > as long as there are no attributes attached to these point cloud data, or if<br>> > the format of the point cloud data has a key column that allows to link<br>> > vector geometries to attributes.<br>><br>> Thanks, added in r71743 (and backported).<br>><br>> >> ----- snap -----<br>> >><br>> >> Please review.<br>> ><br>> > Importing point cloud data is fast, therefore there is little gain in using<br>> > v.external instead of v.in.ogr.<br>><br>> I wonder how much disk space that would save?<br><br></div>I wonder how much trouble corrupt or no output will cause?<br><div><br></div><div>Markus M <br></div></div>