When using the 'Create Polygon from Closed Area' tool, the resulting(newly created) polygon does NOT inherit the 'attributes' of the respective linestring.
Ideally, all the attributes from the source linestring should copy over into the resulting polygon.
Thanks,
Eric
Your request is difficult to achieve as surrounding lines may have different schemas and different values.
Different schemas would be difficult to handle as attributes with same name may have different meaning or data types.
Even different values is not that easy as you may want to let the user choice how values will be aggregated (sum, mean, concatenation).
My opinion is that this task should be achieved by a dedicated tool. There are already a few candidates, but currently all have their limitation.
- Tool > Analysis > Spatial join with attribute aggregation : unfortunately, it misses a "touch" operator, which should not be too hard to add
- Extension > Analysis > Aggregation : there are a few more options, but unfortunately, still not the touches operator
- Extention > matching : the only one which makes it possible to aggregate line features on the new area (use "linear intersection operator). However, I discovered a little bug in the user interface (aggregation is not proposed if the line layer has no String attribute)
I am referring to the tool that is available as an icon on the Toolbar... this tool/operation only does one polygon at a time(or such is the case on OS X), whereas the operation located in the Tools > Edit Geometry > Convert Selected Geometries/Layer to > Polygon takes and converts all closed linestring segments into polygons.
In the case of the tool located on the Toolbox, as-is, it basically only outputs one feature on one layer, and it requires a closed linestring, or closed segments on the same layer, or on multiple layers. Thus, ideally, if the output/resulting polygon could inherit the attributes from the respective feature on the selected layer, then that would more then suffice. Make it so that the tool requires a specific column to be selected, and have a rule that requires the segments must contain the same value in the given column, otherwise the operation will not be allowed.
It is much quicker and a lot easier to check/change attributes in a given layer for a given set of features, then it is to figure out what values belong to the newly created polygon wherein those values then need to be entered/added to that newly created feature.
I will start playing around with the above suggested aggregation tools and see where it takes me... thanks for the advice.
Thanks,
Eric
Hi Eric,
I see what you mean, but I still think that attribute transfer
should be kept as a separate task because
- most users don't need it (ex. they build a building block
or a wood from a road network)
- for those who need it, it may be tricky to set attribute
transfer options (different schemas, different attribute types,
different aggregation operator...)
Moreover, I think that adding such a feature is not as easy as
it may seem (the plugin uses the polygonizer which works on a
set of pure geometries and the closed area never knows the
"features" surronding it during the process). So that all the
information has to be retrieved from adjacent tests.
Finally, I cannot see the advantage of using this tool if you just
want to convert closed linestrings to polygons. Anything wrong
with "Convert Selected Geometries/Layer to > Polygon" ?
Michaël
Related
Bugs:
#335On 09.10.2013 22:38, Eric Jarvies wrote:
well, no. if you select geometries beforehand only these are modified.
..ede
Funny how differently we use OJ. I use this tool for building polygons into the empty spaces left between existing features and I have never even thought that attributes could be transferred because I have always many features with different attributes around the new polygon.