[GRASS-dev] Which v.* modules are working with v.external'ed data

[Markus Neteler]

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

Thanks, added in r71743 (and backported).

>> ----- snap -----
>>
>> Please review.
>
> Importing point cloud data is fast, therefore there is little gain in using
> v.external instead of v.in.ogr.

I wonder how much disk space that would save?

markusN