Re: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 19:34,
gisfi...@t-online.de wrote:
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
This is getting a bit murky ;-)
If the goal is to find areas in the digitized boundaries where
the centroid was missed, then how about a workflow like this:
Import just the boundaries.
Run v.centroid to convert them all to areas.
Import just the points (centroids, with some missing)
Run an intersection between the polygons and points.
Delete all polygons that intersect a point.
What's left are the polygons that were without a centroid.
HTH,
Micha
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
Gesendet: Montag, 23. Januar 2023 16:29
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: AW: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 17:21, gisfi...@t-online.de wrote:
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?
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.
Thank you and best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Sonntag, 22. Januar 2023 21:40
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
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.
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='...', .)
„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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell:
Re: [GRASS-user] v.in.ogr where-clause not working
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 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
Gesendet: Montag, 23. Januar 2023 16:29
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: AW: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 17:21, gisfi...@t-online.de wrote:
> 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?
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.
>
> Thank you and best regards,
>
> Uwe
>
>
> -Ursprüngliche Nachricht-
> Von: Micha Silver
> Gesendet: Sonntag, 22. Januar 2023 21:40
> An: gisfi...@t-online.de; grass-user@lists.osgeo.org
> Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
>
> Hi
>
>
> On 22/01/2023 14:42, gisfi...@t-online.de wrote:
>> 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.
>>
> 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='...', .)
>
>
>> „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
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr where-clause not working
On 23/01/2023 17:21, gisfi...@t-online.de wrote:
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?
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.
Thank you and best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Sonntag, 22. Januar 2023 21:40
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
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.
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='...', .)
„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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ogr where-clause not working
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?
Thank you and best regards,
Uwe
-Ursprüngliche Nachricht-
Von: Micha Silver
Gesendet: Sonntag, 22. Januar 2023 21:40
An: gisfi...@t-online.de; grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] v.in.ogr where-clause not working
Hi
On 22/01/2023 14:42, gisfi...@t-online.de wrote:
>
> 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.
>
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='...', .)
> „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
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
