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

hellik · November 15, 2017, 12:36pm

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?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

Markus_Metz · November 15, 2017, 2:49pm

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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.

Markus M

hellik · November 15, 2017, 3:01pm

Markus Metz-3 wrote

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <

hellik@

> 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.

Markus M

_______________________________________________
grass-dev mailing list

grass-dev@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-dev

in QGIS 3 options, a switch to v.in.ogr is possible..

I think we should communicate to the QGIS devs that v.external isn't the
best choice.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

martinl · November 15, 2017, 3:02pm

2017-11-15 16:01 GMT+01:00 Helmut Kudrnovsky <hellik@web.de>:

in QGIS 3 options, a switch to v.in.ogr is possible..

I think we should communicate to the QGIS devs that v.external isn't the
best choice.

absolutely, I can imagine linking point data. But generally, import
should be default option. Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

neteler · November 15, 2017, 3:35pm

On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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 v.external 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 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 with v.import
or v.in.ogr to get true topology support. Importantly, point
cloud data which do not have topology, can be linked with v.external.
----- snap -----

Please review.

Markus

Markus_Metz · November 15, 2017, 9:03pm

On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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 v.external 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 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 with v.import
or v.in.ogr to get true topology support. Importantly, point
cloud data which do not have topology, can be linked with v.external

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.

----- snap -----

Please review.

Importing point cloud data is fast, therefore there is little gain in using v.external instead of v.in.ogr.

Markus M

Markus

neteler · November 16, 2017, 9:02pm

On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote

On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
> On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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 v.external 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 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 with v.import
or v.in.ogr to get true topology support. Importantly, point
cloud data which do not have topology, can be linked with
v.external

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

Markus_Metz · November 16, 2017, 9:20pm

On Thu, Nov 16, 2017 at 10:02 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote

On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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 v.external 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 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 with v.import
or v.in.ogr to get true topology support. Importantly, point
cloud data which do not have topology, can be linked with
v.external

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?

I wonder how much trouble corrupt or no output will cause?

Markus M

neteler · November 16, 2017, 9:27pm

On Wed, Nov 15, 2017 at 4:01 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

in QGIS 3 options, a switch to v.in.ogr is possible..

I think we should communicate to the QGIS devs that v.external isn't the
best choice.

Just done in the related pull request for GRASS GIS support.

markusN

Blumentrath_Stefan1 · November 16, 2017, 10:18pm

Just for the record: some of my colleagues are making quite extensive use of v.external for GPS tracking (point) data they have in PostGIS. Earlier we tried to use PostGIS rasters, but it is much more convenient and efficient to e.g. just upload raster values to linked PostGIS tables from GRASS, now that v.what.rast does not require topology any more…

Cheers

Stefan

···

On Thu, Nov 16, 2017 at 10:02 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote

On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hellik@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 v.external 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 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 with v.import
or v.in.ogr to get true topology support. Importantly, point
cloud data which do not have topology, can be linked with
v.external

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?

I wonder how much trouble corrupt or no output will cause?

Markus M