<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="NO-BOK" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">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ā€¦<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Cheers<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Stefan<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> grass-dev [mailto:grass-dev-bounces@lists.osgeo.org]
<b>On Behalf Of </b>Markus Metz<br>
<b>Sent:</b> torsdag 16. november 2017 22.21<br>
<b>To:</b> Markus Neteler <neteler@osgeo.org><br>
<b>Cc:</b> GRASS developers list <grass-dev@lists.osgeo.org>; Helmut Kudrnovsky <hellik@web.de><br>
<b>Subject:</b> Re: [GRASS-dev] Which v.* modules are working with v.external'ed data<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB"><br>
<br>
On Thu, Nov 16, 2017 at 10:02 PM, Markus Neteler <</span><a href="mailto:neteler@osgeo.org"><span lang="EN-GB">neteler@osgeo.org</span></a><span lang="EN-GB">> wrote:<br>
><br>
> On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz<br>
> <</span><a href="mailto:markus.metz.giswork@gmail.com"><span lang="EN-GB">markus.metz.giswork@gmail.com</span></a><span lang="EN-GB">> wrote<br>
> > On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <</span><a href="mailto:neteler@osgeo.org"><span lang="EN-GB">neteler@osgeo.org</span></a><span lang="EN-GB">> wrote:<br>
> >><br>
> >> On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz<br>
> >> <</span><a href="mailto:markus.metz.giswork@gmail.com"><span lang="EN-GB">markus.metz.giswork@gmail.com</span></a><span lang="EN-GB">> wrote:<br>
> >> > On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <</span><a href="mailto:hellik@web.de"><span lang="EN-GB">hellik@web.de</span></a><span lang="EN-GB">><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?<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB">I wonder how much trouble corrupt or no output will cause?<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">Markus M <o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>