5

I have a shape (its topology is terrible but I don't think it's the problem). I'm trying to simplify it to reduced it's size using v.generalise. I succeeded at reducing the whole shape but I actually want to do a two steps simplification:

  1. simplifying all the shape with threshold 0.0001 first,
  2. simplifying all the polygons with urban=0 further more with threshold 0.0003

The problem is that my second v.generalize call simplifies everything, like if the WHERE call wasn't working.

For this question, we will just focus on the point 2, so here what I do:

A subset of my data can be found here.

And here is some visualization of what I did:

My shape initially:

enter image description here

My v.generalize call:

enter image description here

The result (below) show the blue line the new polygons border which where simplified even if they were not in urban=0.

enter image description here

Just like if the WHERE statement was ignore. I don't see any error in the log specific to that SQL statement. The actual call to GRASS built by QGIS is:

C:\OSGEO4~1\bin>v.generalize input=vector_5be4482a0b8e72 type="line,boundary,area" where="urban=0" method="douglas" threshold=0.0003 look_ahead=7 reduction=50 slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh=0 betweeness_thresh=0 alpha=1 beta=1 iterations=1 -l output=output96039149be394bdaa48a3ba7d8b849f7 error=error96039149be394bdaa48a3ba7d8b849f7 --overwrite

I've try multiple WHERE statement (urban="0", urban<1, etc) to try to match the v.generalise tutorial but still no luck. I also tried to do it directly in GRASS bypassing QGIS and the problem persist meaning is not a QGIS problem more than a GRASS problem.

In this example, the urban field is a real number.

Any idea what the problem is?

Improve this question
4
  • Please Edit the question to specify the data type of the urban field. I note that you did not list the valid SQL varchar delimiter -- single-quote -- in your examples (urban = '0')
    – Vince
    Commented Nov 8, 2018 at 14:55
  • Just did. In this case it's real, but I got other ones in my different tests (character, interger64, etc.). I also tried more complex queries (SUBSTR(FSALDU,2,1)==’0’, SUBSTRING(FSALDU,2,1)=’0’, etc.)
    – Bastien
    Commented Nov 8, 2018 at 15:04
  • I reproduced the issue on GRASS with your layer, tried a few things but didn't work. QGis seems out of cause yes, did you try with other layers/settings or is it definitely a GRASS issue ?
    – MaxPlank
    Commented Nov 9, 2018 at 8:34
  • Yes, I tried it with another shape and I get the same problem (example shape from R library(sf) could be created in R with: st_read(system.file("gpkg/nc.gpkg", package="sf"), quiet = TRUE) %>% mutate(CNTY = as.numeric(CNTY_<median(CNTY_))) %>% select(CNTY) %>% st_transform(st_crs(2264)) %>% st_write("d:/temp/NC_test.shp"). With a threshold of 10000 and a WHERE of CNTY<1 you get the same behaviour. Guess I should open an issue?
    – Bastien
    Commented Nov 12, 2018 at 13:41

1 Answer 1

Reset to default
2

The problem here is that the use of the cat and WHERE options from v.generalize requires the layer=1 option set as well. As of right now (nov 2018), QGIS default value for layer is set to -1 and doesn't allow to be change making QGIS currently useless for using v.generalize with the WHERE option. Use GRASS directly instead.

The tutorial now give good example on how to use the WHERE statement.

Further details on this problem can be obtained here.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.