Bug report #4880
"add feature" tool (for polygons) + "avoid intersection" is inconsistent when it is used to fill holes and/or spaces
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Marco Hugentobler | ||
| Category: | Digitising | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 14704 |
Description
Note: to better understand the issue first look at the attached screencast, then read :)
I'll tag this ticket as "high" priority because it is a huge usability/digitizing problem, that I've been said is moving away many potential users from QGIS. I'll tag this also as bug instead of feature because the behaviour I'll describe is inconsistent (it partially works) so it is not just a missing feature, but a bad working feature.
Case study: a user has to create a map of land use. The map will consist of adjacent polygons, but the workflow can't be always the one that using snapping, pseudo-topology and avoid intersection will lead the user to draw new polygons one beside each other.
It more probable that the user will draw the polygons of a particular land use and then draw other beside them or even around them.
After the map is complete it will probably need adjustments -> draw a new parcel inside of an existing polygon and/or draw a new parcel between two existing polygons. This can be achieved with the editing tools already available (plus the help of a few contributed plugins) but it is easy demonstrable that it is missing a core tool and that the "add feature" tool acts in an inconsistent way.
- The "hole" issue: holes can be carved with the proper tool, but then to be filled you need to enable "avoid intersection" and draw a polygon around it. This will cost the user at least a few clicks and probably a trip in the menus. It would be much better to have a tool that with one click fills a hole and ask for attributes (pre-filling the table with the values of the polygon surrounding the hole). There is the "ringer" plugin, but this does not do the job the right way, as it fills every hole in a given polygon and it doesn't ask for attributes.
- The "space" between polygons issue: spaces between polygons can be left on purpose or by mistake, and can be definitely be done as necessity, to e filled in a second moment. At the moment there isn't a tool (core or plugin) that allows to fill such spaces with one click. The "ringer" plugin works just for holes, the "trace edit" plugin works but is not handy: if the space/hole is not very complex (just a few vertexes and with very straight lines) then it can be used, but if the space is made of a lot of vertexes and very complex segments then is not usable (also because there is no way to undo a node that snapped in the wrong place).
The solution in this case is to use the "add feature" tool enabling the "avoid intersection" option and drawing a polygon around the space (between polygons). The problem is that such operation it often results in the following message:
"The feature could not be added because removing the polygon intersections would change the geometry type"
I have been said that this happens because the resulting geometry is a multipart -> the newly created polygon will have an island.
Well, to me and many other users it doesn't make much sense that this tool to have such limitation. In any case one can say "just pay attention and draw the polygon in a way that after the "clipping" you won't have any island". The suggestion make sense, unfortunately it is easy to demonstrate that the message sometimes pop up also when the user follows it.
I attach to this ticket a sample project (with a sample layer) and a couple of screencasts to show that the user is often puzzled about how he/she can fill such spaces.
If the limitation is really the change of geometry then I would suggest to remove it (the limitation).
Related issues
History
#1
Updated by Filipe Dias almost 13 years ago
I've come across this issue a few times and it's a little troubling. It would be great if this limitation could be overcome.
#2
Updated by Marco Hugentobler almost 13 years ago
Yes, the error message is because the layer is Polygon, but after 'avoid intersection', it is multipolygon and may cause problem when committing e.g. to PostGIS.
There are two parts of the problem:
1. Because avoid intersection is done iteratively, it is possible that at some stage, the polygon turns into multipolygon and stays like that even if later the outcome would be a polygon
2. Sometimes there are sliver polygons, probably because of rounding. With the test dataset, this happens in some of the cases
I've disabled the check until there is a better solution. Part1 of the problem seems fixable (union all the resulting parts together). However, for part 2, I don't have an idea yet.
#3
Updated by Paolo Cavallini almost 13 years ago
For problem 2, perhaps a small amount of snapping could do?
#4
Updated by Giovanni Manghi almost 13 years ago
Marco Hugentobler wrote:
Yes, the error message is because the layer is Polygon, but after 'avoid intersection', it is multipolygon and may cause problem when committing e.g. to PostGIS.
There are two parts of the problem:
1. Because avoid intersection is done iteratively, it is possible that at some stage, the polygon turns into multipolygon and stays like that even if later the outcome would be a polygon
2. Sometimes there are sliver polygons, probably because of rounding. With the test dataset, this happens in some of the casesI've disabled the check until there is a better solution. Part1 of the problem seems fixable (union all the resulting parts together). However, for part 2, I don't have an idea yet.
From the user point of view the "problem" is that the above warning shows also when is not going to be created a multi-polygon. This is puzzling for the user.
To start, one solution, always from the user point of view, would be to have two more tools (to be chosen like it is done in the selection tool, with a kind of drop down) in the "capture polygon" tool:
- one to fill holes
- one to fill spaces
if it can be done a tool that do both then even better.
There is also another case, the one when the user don't want to fill entirely the space/hole. This would need a good trace edit tool (the contributed plugin is not good enough, but consider that the trace edit tool is an important part of the editing toolbar of the most known GIS package) or have the "capture polygon" tool to be handle better the "multipolygon" issue described above.
But I would say that to start a "fill hole/spaces" tool would be a very good, able to solve much of the issues users has to solve in this situations.
#5
Updated by Giovanni Manghi almost 13 years ago
Paolo Cavallini wrote:
For problem 2, perhaps a small amount of snapping could do?
Snapping is good and useful, but what about if the hole/space you have to fill has very complex boundaries (many dense nodes, many non straight boundaries)?
The "trace edit" plugin (that uses snapping) demonstrate that in this cases to do the task can be a nightmare.
#6
Updated by Giovanni Manghi almost 13 years ago
Marco Hugentobler wrote:
, it is multipolygon and may cause problem when committing e.g. to PostGIS.
this is the problem you are alterting to?
Could not commit changes to layer test_fill_spaces
Errors: ERROR: 1 feature(s) not added.
SUCCESS: 3 geometries were changed.
Provider errors:
PostGIS error while adding features: ERROR: new row for relation "test_fill_spaces" violates check constraint "enforce_geotype_the_geom"if yes then it is a real (life) issue.
You can test on this server
mapserver.uevora.pt
db: ue_publico
username/password: ue
with the layer "test_fill_spaces" or better with the much more complex "uso_single" -> try filling the holes without passing over other holes (and so get the mentioned error)... this real life example shows well also the need for a (core) "fill hole/space" tool.
#7
Updated by Giovanni Manghi almost 13 years ago
- File 33.png added
#8
Updated by Stefan Blumentrath over 12 years ago
Is not Bug #2921 (#2921) a part of the same problem?...
BTW: Are you sure,that the problem is occurring because of a polygon/multi-polygon conflict? Or could´nt it be the case that the tool is trying to create a line (because of the decimal precision / rounding problems), which would conflict e.g. with a polygon shape file? Anyway, it would be really great, to get this bug solved! This is the main obstacle, when using the otherwise (imo) excellent digitising tools in QGIS...
#9
Updated by Giovanni Manghi over 12 years ago
Stefan Blumentrath wrote:
Is not Bug #2921 (#2921) a part of the same problem?...
BTW: Are you sure,that the problem is occurring because of a polygon/multi-polygon conflict? Or could´nt it be the case that the tool is trying to create a line (because of the decimal precision / rounding problems), which would conflict e.g. with a polygon shape file? Anyway, it would be really great, to get this bug solved! This is the main obstacle, when using the otherwise (imo) excellent digitising tools in QGIS...
Hi Stefan,
I'm not sure they are related, I would have to study a little more the issue described in #2921. In any case this ticket is more a feature request, about the lack of core tools to allow fill holes and spaces between polygons.
#10
Updated by marisn - over 12 years ago
With current workaround in place, instead of getting annoying message, now I get crashes on saving edits. When I revert 6a44e1151d04f7e3659760fea44a4c442c6950d3, I get disappearing polygons but QGIS isn't crashing anymore.
#11
Updated by Paolo Cavallini about 12 years ago
- Target version set to Version 2.0.0
#12
Updated by Giovanni Manghi almost 12 years ago
- Priority changed from High to Normal
#13
Updated by Marco Hugentobler over 11 years ago
The small gaps appear because of numerical problems, see geos-devel list (http://lists.osgeo.org/pipermail/geos-devel/2013-February/006227.html). So my workaround in QGIS dc074b393e800368bd0ed35b137d9dd930b73f75 is to always enable topological editing if avoid intersection is used (also to background layers if they are editable).
I'm suggesting to close this ticket.
#14
Updated by Giovanni Manghi over 11 years ago
- Status changed from Open to Feedback
Marco Hugentobler wrote:
The small gaps appear because of numerical problems, see geos-devel list (http://lists.osgeo.org/pipermail/geos-devel/2013-February/006227.html). So my workaround in QGIS dc074b393e800368bd0ed35b137d9dd930b73f75 is to always enable topological editing if avoid intersection is used (also to background layers if they are editable).
I'm suggesting to close this ticket.
Hi Marco, let me study the issue again and then I'll leave feedback. Thanks!
#15
Updated by Giovanni Manghi over 11 years ago
- Resolution set to fixed
- Status changed from Feedback to Closed
#16
Updated by Sandro Santilli almost 11 years ago
- Resolution deleted (
fixed)
What about changing the algorithm avoiding the recursive intersection approach ?
You could extract all the linework of polygons involved in the "avoid intersection" process, fully node the linework, polygonize the noded linework and finally re-assign polygons to new or pre-existing features. Does it sound as a possible solution ?
#17
Updated by Giovanni Manghi almost 11 years ago
Sandro Santilli wrote:
What about changing the algorithm avoiding the recursive intersection approach ?
You could extract all the linework of polygons involved in the "avoid intersection" process, fully node the linework, polygonize the noded linework and finally re-assign polygons to new or pre-existing features. Does it sound as a possible solution ?
hi Sandro,
the important ticket about this issue is now #8174, that is tagged (someone would say improperly) a blocker even if is not a regression, to underline (imho) how bad is this issue from the practical/real life point of view.