grass
grass copied to clipboard
v.dissolve resolve issue with dissolving line features
This seems to solve issue #3420
Would you be able to provide a test for this? The current tests pass so that's great. A test for lines or points would be nice addition. v.dissolve has grass.gunittest-based tests in testsuite directory and pytest-based tests in tests. You can pick whatever makes more sense to you.
Would you be able to provide a test for this? The current tests pass so that's great. A test for lines or points would be nice addition. v.dissolve has grass.gunittest-based tests in
testsuitedirectory and pytest-based tests intests. You can pick whatever makes more sense to you.
I haven't figured out how those tests work. Something on my todo list.
There is, however, several places in the code and doc which mention area. Can you please update those?
I can give it a try. Most descriptions you read are about dissolving boundaries between adjacent polygons. That is the more common and also easily visualized user case. But in this case, adjacent or overlapping features can be dissolved irrespective of their type (at least, I tried with lines and polygons, I haven't tried the other types). That makes it a bit harder to clearly describe.
But perhaps first the observation that in the manual, it reads that:
Multiple areas with the same category or the same attribute value which are not adjacent are merged together into one entity which consists of multiple areas, i.e., a multipolygon.
This is the actual behavior, which differs from what the general description suggests, which reads:
Dissolves boundaries between adjacent areas sharing a common category number or attribute.
I would have thought that the latter is the more common approach to dissolving features?
I actually like how QGIS has implemented this. Its dissolve function offers the option to "keep disjoint features as separate". Selecting that option means that any features in the layer that do not share a common boundary with another feature will be kept as separate features. I am not sure how ArcGIS handles things.
There is, however, several places in the code and doc which mention area. Can you please update those?
I can give it a try. Most descriptions you read are about dissolving boundaries between adjacent polygons. That is the more common and also easily visualized user case.
For merging this PR, it would be enough just to fix the places where is says it does areas (only). If it says "areas and other types" that should be enough to clarify it is not areas only.
But perhaps first the observation that in the manual, it reads that:
Multiple areas with the same category or the same attribute value which are not adjacent are merged together into one entity which consists of multiple areas, i.e., a multipolygon.
This is the actual behavior, which differs from what the general description suggests, which reads:
Dissolves boundaries between adjacent areas sharing a common category number or attribute.
I would have thought that the latter is the more common approach to dissolving features?
Based on what I found, just a conjecture based on what are the defaults in different SW, the more common behavior is the same what the current v.dissolve does. It may be different from the expectations created by the more geometrically focused examples in GIS 101 classes, but that's the reality perhaps based on what is easier to implement. The v.dissolve implementation relies on two-step (three with aggregation) process with the geometry and attributes being resolved separately and at this point does not have an easy switch for changing to the other behavior. The update would have to happen in v.extract and practically it is likely just a question of how much time/money is someone willing to spend adding that feature.
There is, however, several places in the code and doc which mention area. Can you please update those?
I can give it a try. Most descriptions you read are about dissolving boundaries between adjacent polygons. That is the more common and also easily visualized user case.
For merging this PR, it would be enough just to fix the places where is says it does areas (only). If it says "areas and other types" that should be enough to clarify it is not areas only.
But perhaps first the observation that in the manual, it reads that:
Multiple areas with the same category or the same attribute value which are not adjacent are merged together into one entity which consists of multiple areas, i.e., a multipolygon.
This is the actual behavior, which differs from what the general description suggests, which reads:
Dissolves boundaries between adjacent areas sharing a common category number or attribute.
I would have thought that the latter is the more common approach to dissolving features?
Based on what I found, just a conjecture based on what are the defaults in different SW, the more common behavior is the same what the current v.dissolve does. It may be different from the expectations created by the more geometrically focused examples in GIS 101 classes, but that's the reality perhaps based on what is easier to implement. The v.dissolve implementation relies on two-step (three with aggregation) process with the geometry and attributes being resolved separately and at this point does not have an easy switch for changing to the other behavior. The update would have to happen in v.extract and practically it is likely just a question of how much time/money is someone willing to spend adding that feature.
Fair enough. And it is possible to separate geographically separated features in a separate step using the code https://github.com/OSGeo/grass-addons/pull/1021, if that is required.
As for the text, I'll have a look.
Are you sure about the image the result has A and B values in key column, there should probably be cat column again with 1 and 2.
You are right, I misunderstood the earlier text. Removed that part of the text and the figure.
I don't know if it was the formatting changes or just GitHub diff rendering, but I had to read everything to figure out what was changed. That took some time to get to it. It looks great overall. Hopefully next round can be quick.
Sorry about that. I have never figured out when GitHub shows the diff for the line in which the change took place, or whole blocks of text, or what I should do to make sure it only shows the line with changes.
...I have never figured out when GitHub shows the diff for the line in which the change took place, or whole blocks of text, or what I should do to make sure it only shows the line with changes.
If there are changes in wrapping of paragraphs, than it shows the whole blocks as edited. Both Git and GitHub can show just changed words and they try to show changes around unchanged text, but if there is a change on every line, than everything looks new and the word diff is no longer possible. The versioning is line-oriented and if there is a change in a line it will show it (and it will not show it otherwise).
You can limit some of these issue by really editing just the necessary stuff, e.g., by picking only what you intended to change using git add -p (which is a really great tool in general). This may help with things like slightly modified images or automatically changed lines by your editor.
If you do changes everywhere, then, of course, you create a huge diff and that's fine if making changes everywhere is what you are really doing.