Feature request #11008
Field Calculator - get centroid of polygon easily
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | - | ||
| Pull Request or Patch supplied: | No | Resolution: | |
| Easy fix?: | No | Copied to github as #: | 19350 |
Description
Currently it's difficult (non-obvious) how to get the centroid of a polygon using the field calculator:
xmin(centroid($geometry))
ymin(centroid($geometry))
As a user I'd expect it to simply be:
$x
$y
If it's a polygon, assuming there are no parameters it seems reasonable to me that $x/$y would result in the respective coordinates of the centroid.
Associated revisions
Clean up and extend expression geometry functions:
- New expression functions for area(geom), perimeter(geom),
point_n(geom), start_point(geom), end_point(geom), make_point(x,y)
- Add new variant to length() function which takes a geometry object,
allows for length(geom) evaluation.
- Rename x_at, y_at to $x_at, $y_at (alias old names) to reflect that
these only work on current feature geometry
- Add x(geom), y(geom) functions which return x and y coordinate
for point geometries or centroid x/y for non-point geometries
(fix #11008)
History
#1
Updated by Andreas Neumann almost 10 years ago
You probably meant:
x(centroid($geometry))
y(centroid($geometry))
$x/$y would not work on a polygon, which is the input geometry.
#2
Updated by Jonathan Moules almost 10 years ago
I get what you're saying but the version you put (using "x" rather than "xmin") is no more obvious than the version that is currently in use because you still have the whole "centroid(geometry)" part.
$x and $y are obvious to end users (well as obvious as it can get given the nature of these things). The rest of the stuff should be done automagically behind the scenes.
I appreciate they don't currently work with the polygon geometry, the notion behind the ticket is that I believe they should work.
Hope that's clearer.
#3
Updated by Antonio Locandro almost 10 years ago
First of all the current behaviour is a very bad choice, it should have been x(centroid($geometry)),y(centroid($geometry)) from the start anyway. I also thing $geometry could have been replaced by $geom which is shorter if you have to type a lot
Having said that you could asume $x and $y for a polygon to return the centroid for it
Another option is to have something like
$centroid.x > will return longitude
$centroid.y > will return latitude
$centroid > will return an x,y tuple
As you see I am omiting writing $geometry since it should be implied, like when you calculate $area or $perimeter
It is a design choice but I think it would be nicer if one could ommit writing $geometry when possible
#4
Updated by Nyall Dawson almost 9 years ago
- Status changed from Open to Closed
Fixed in changeset 55027e545f6265aaeda47dc48923cd5be6a47d74.