<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 23/01/2023 19:34,
      <a class="moz-txt-link-abbreviated" href="mailto:gisfisch@t-online.de">gisfisch@t-online.de</a> wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:001101d92f50$f8e88f20$eab9ad60$@t-online.de">
      <pre class="moz-quote-pre" wrap="">Hi Micha,

sorry, I did not tell the whole truth again. The boundaries are clean, but the cents are not complete. Strictly speaking, it is the goal of the whole process to find cases where the digitizing operator forgot to </pre>
    </blockquote>
    <p><br>
    </p>
    <p>This is getting a bit murky ;-)</p>
    <p>If the goal is to find areas in the digitized boundaries where
      the centroid was missed, then how about a workflow like this:</p>
    <ul>
      <li>Import just the boundaries.</li>
      <li>Run v.centroid to convert them all to areas.</li>
      <li>Import just the points (centroids, with some missing)</li>
      <li>Run an intersection between the polygons and points.</li>
      <li>Delete all polygons that intersect a point.</li>
      <li>What's left are the polygons that were without a centroid.</li>
    </ul>
    <p>HTH,</p>
    <p>Micha<br>
    </p>
    <blockquote type="cite"
      cite="mid:001101d92f50$f8e88f20$eab9ad60$@t-online.de">
      <pre class="moz-quote-pre" wrap="">place centroids. Thus, I need to import bounds and cents. As far as I can see (in my old workflow), areas WITH centroids were placed on layer 2 while areas WITHOUT centroids were placed on layer 1 (at least this is what QGIS shows when the imported GRASS map was loaded). I will try to add category values to those somehow "empty" areas using v.category option=add, and I hope that I can adress them after this in my script and export them (for usage as error markers) using v.out.ogr. I remember that I tried to add centroids using v.centroid in a similar case, but I could not get it to work. So I used v.category. Not sure if I did everything correct.

Best regards,
Uwe

-----Ursprüngliche Nachricht-----
Von: Micha Silver <a class="moz-txt-link-rfc2396E" href="mailto:tsvibar@gmail.com"><tsvibar@gmail.com></a> 
Gesendet: Montag, 23. Januar 2023 16:29
An: <a class="moz-txt-link-abbreviated" href="mailto:gisfisch@t-online.de">gisfisch@t-online.de</a>; <a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
Betreff: Re: AW: [GRASS-user] v.in.ogr where-clause not working


On 23/01/2023 17:21, <a class="moz-txt-link-abbreviated" href="mailto:gisfisch@t-online.de">gisfisch@t-online.de</a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hello Micha and list,

thank you for the answer.
The double quotes did not work. But when I tried, it suddenly became clear what could be the problem. You could not see that in my example. I use a directory as input, containing one shapefile with boundaries and one with centroids (goal: create area vector map). Only the boundaries have the attribute LENGTH. So it cannot be found in the centroids, and that is the reason for that message.
I wonder why it worked in the old GRASS/PYTHON? There was a message that the 'where' clause is only applied to the first input layer which is the boundary shapefile named 'arc.shp' (starts with a, so probably it is the first). This must have changed in GRASS78.

I used this and was happy with it because I need to import those shapes and create a vector map out of them. Now, I think I will have to import them in two steps (only one with 'where')  and put them together in GRASS. Is 'v.patch' followed by 'v.build' a good way or is there a better straightforward way?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">

If the boundary shapefile is topologically clean (no crossing lines, and all boundaries are closed) then no need to import the centroids. Just get the boundary lines, then run v.centroid with option=add. It will take care of adding centroids to all closed boundaries, thus creating areas. This would be after v.clean in any case.


</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
Thank you and best regards,

Uwe


-----Ursprüngliche Nachricht-----
Von: Micha Silver <a class="moz-txt-link-rfc2396E" href="mailto:tsvibar@gmail.com"><tsvibar@gmail.com></a>
Gesendet: Sonntag, 22. Januar 2023 21:40
An: <a class="moz-txt-link-abbreviated" href="mailto:gisfisch@t-online.de">gisfisch@t-online.de</a>; <a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working

Hi


On 22/01/2023 14:42, <a class="moz-txt-link-abbreviated" href="mailto:gisfisch@t-online.de">gisfisch@t-online.de</a> wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Hello list,

I have problems with v.in.ogr in a python script; I use:

/grass.run_command('v.in.ogr',input='d:/my_input',output='my_output',
t ype='boundary,centroid',where='LENGTH
!= 1',snap=0.01,min_area=0.01,flags="o",overwrite=True)/

This has been working fine for years in GRASS 7.0.3 with Python 2.

Now, I tried in GRASS 7.8 on Python 3 and I get the following error:

ERROR 1: "LENGTH" not recognised as an available field.

FEHLER: Error setting attribute filter 'LENGTH != 1'

The field called LENGTH is present and there is no typing error. What 
I absolutely not understand is that the command is working fine 
inside GRASS itself! Just the Python script does not.

</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">Can you try to create the where clause with double quotes before calling grass.run_command? Like so:


expr = '"LENGTH != 1"'

grass.run_command('v.in.ogr', input='...', output='...', where=expr, 
type='...', .....)


</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">„LENGTH“ is not a Python reserved keyword, and no SQL reserved 
keyword. I also tried it with another name for that column. That also 
did not work.

Any ideas what could be wrong? Thank you very much.

Uwe


_______________________________________________
grass-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a>
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918</pre>
  </body>
</html>