I have a polygon vector, and need to add point in the center of mass of each one.
I used v.centroid, but it adds just a centroid, but not in the central position of the polygon area.
any hint are welcome!
cheers
–
Miltinho - mcr@rc.unesp.br
Laboratório de Ecologia Espacial e Conservação - LEEC
Depto de Ecologia - UNESP - Rio Claro
Av. 24A, 1515- Bela Vista
13506-900 Rio Claro, SP, Brasil
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
any hint are welcome!
I take liberty to cite a previous email here which is somewhat related:
On Tue, Feb 28, 2012 at 8:48 PM, Hamish <hamish_b@yahoo.com> wrote:
Vishal wrote:
i'm interested in estimating the centre of population of a city
and how it might have changed in 10 years. i have a vector
polygon layer for each year, which is the ward population.
each layer has 198 polygons(wards) with population attributes
for each polygon(ward). The distribution of population within
a ward is not known, hence assumed uniform for now.
is there a module in GRASS for calculating this. i know we can
calculate geographic centroids, but was'nt sure if there was
one for this kind of thing.
Otherwise i could do it manually by extracting the geographic
centroid of each polygon, then the coordinates of the
population centre would be:
but then tested to see if the point is within the polygon.
beware of "C" or "O" shaped wards, where the center of mass
(or the more simple center of the bounding box) may not be.
"v.points.cog is a shell script which will create a new point at
the center of gravity of each cluster of input points or
centroids, grouped by attribute. Among other things this is
useful for labeling swarms of points."
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
any hint are welcome!
I take liberty to cite a previous email here which is somewhat related:
i’m interested in estimating the centre of population of a city
and how it might have changed in 10 years. i have a vector
polygon layer for each year, which is the ward population.
each layer has 198 polygons(wards) with population attributes
for each polygon(ward). The distribution of population within
a ward is not known, hence assumed uniform for now.
is there a module in GRASS for calculating this. i know we can
calculate geographic centroids, but was’nt sure if there was
one for this kind of thing.
Otherwise i could do it manually by extracting the geographic
centroid of each polygon, then the coordinates of the
population centre would be:
but then tested to see if the point is within the polygon.
beware of “C” or “O” shaped wards, where the center of mass
(or the more simple center of the bounding box) may not be.
“v.points.cog is a shell script which will create a new point at
the center of gravity of each cluster of input points or
centroids, grouped by attribute. Among other things this is
useful for labeling swarms of points.”
Due to the shape issue there is no general solution, it depends on the data.
Maybe other list members have further suggestions.
Markus
–
Miltinho - mcr@rc.unesp.br
Laboratório de Ecologia Espacial e Conservação - LEEC
Depto de Ecologia - UNESP - Rio Claro
Av. 24A, 1515- Bela Vista
13506-900 Rio Claro, SP, Brasil
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
--
Miltinho - mcr@rc.unesp.br
Laboratório de Ecologia Espacial e Conservação - LEEC
Depto de Ecologia - UNESP - Rio Claro
Av. 24A, 1515- Bela Vista
13506-900 Rio Claro, SP, Brasil
On Sat, Jan 25, 2014 at 12:08 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
On Sat, Jan 25, 2014 at 12:27 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Jan 25, 2014 at 12:08 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
On Sat, Jan 25, 2014 at 12:27 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Jan 25, 2014 at 12:08 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
Right, I forgot about this nice addon!
Perhaps its functionality might be merged into v.centroids [1]?
No, because the center of mass is not always within the area.
But couldn't that be a documented flag (e.g. something like this: 'always place centroid within the area (for GRASS polygon)').
Personally, I support MarkusN's idea of merging the two, if that's possible from the code point of view. I find it more intuitive to look for a module creating centroids...
I agree that a flag would be a good way ..
Best wishes
miltinho
2014-01-27, Moritz Lennert <mlennert@club.worldonline.be>:
On 25/01/14 12:52, Markus Metz wrote:
On Sat, Jan 25, 2014 at 12:27 PM, Markus Neteler <neteler@osgeo.org>
wrote:
On Sat, Jan 25, 2014 at 12:08 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of
each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
Right, I forgot about this nice addon!
Perhaps its functionality might be merged into v.centroids [1]?
No, because the center of mass is not always within the area.
But couldn't that be a documented flag (e.g. something like this:
'always place centroid within the area (for GRASS polygon)').
Personally, I support MarkusN's idea of merging the two, if that's
possible from the code point of view. I find it more intuitive to look
for a module creating centroids...
--
Miltinho - mcr@rc.unesp.br
Laboratório de Ecologia Espacial e Conservação - LEEC
Depto de Ecologia - UNESP - Rio Claro
Av. 24A, 1515- Bela Vista
13506-900 Rio Claro, SP, Brasil
On Mon, Jan 27, 2014 at 9:38 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 25/01/14 12:52, Markus Metz wrote:
On Sat, Jan 25, 2014 at 12:27 PM, Markus Neteler <neteler@osgeo.org>
wrote:
On Sat, Jan 25, 2014 at 12:08 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sat, Jan 25, 2014 at 12:10 AM, Milton Ribeiro
<miltinho.astronauta@gmail.com> wrote:
Dear all,
I have a polygon vector, and need to add point in the center of mass of
each
one.
I used v.centroid, but it adds just a centroid, but not in the central
position of the polygon area.
Right, I forgot about this nice addon!
Perhaps its functionality might be merged into v.centroids [1]?
No, because the center of mass is not always within the area.
But couldn't that be a documented flag (e.g. something like this: 'always
place centroid within the area (for GRASS polygon)').
Centroids must always be within the area. We can add the functionality
to v.category (v.centroids is just a wrapper for v.category) or
better, to the vector library, but then centroids are still not
guaranteed to be the center of mass.
Personally, I support MarkusN's idea of merging the two, if that's possible
from the code point of view. I find it more intuitive to look for a module
creating centroids...
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Personally, I support MarkusN's idea of merging the two, if that's possible
from the code point of view. I find it more intuitive to look for a module
creating centroids...
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Well, that's when you come from the GRASS perspective with a very specific meaning for 'centroids'. I think for most users centroids are the center of mass. So, I'm not sure that this will really be an issue of great confusion.
But I won't make an issue out of this. v.centerpoints is already a nice solution and I think it should be moved to trunk, although I've stumbled on some issues, but I'll file bug reports on those.
On Thu, Jan 30, 2014 at 10:39 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 28/01/14 11:52, Markus Metz wrote:
On Mon, Jan 27, 2014 at 9:38 AM, Moritz Lennert
Personally, I support MarkusN's idea of merging the two, if that's
possible
from the code point of view. I find it more intuitive to look for a
module
creating centroids...
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Well, that's when you come from the GRASS perspective with a very specific
meaning for 'centroids'. I think for most users centroids are the center of
mass. So, I'm not sure that this will really be an issue of great confusion.
Centroids, in the sense of v.centroids for which you request the
modification, are calculated in the very specific GRASS meaning of
'centroids', i.e. they really must be inside the area for which they
are calculated. Moreover, the center or mass for two or more different
areas can be exactly the same.
But I won't make an issue out of this. v.centerpoints is already a nice
solution and I think it should be moved to trunk, although I've stumbled on
some issues, but I'll file bug reports on those.
Please let me know, I will try to fix these issues.
On Thu, Jan 30, 2014 at 10:39 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 28/01/14 11:52, Markus Metz wrote:
On Mon, Jan 27, 2014 at 9:38 AM, Moritz Lennert
Personally, I support MarkusN's idea of merging the two, if that's
possible
from the code point of view. I find it more intuitive to look for a
module
creating centroids...
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Well, that's when you come from the GRASS perspective with a very specific
meaning for 'centroids'. I think for most users centroids are the center of
mass. So, I'm not sure that this will really be an issue of great confusion.
Centroids, in the sense of v.centroids for which you request the
modification, are calculated in the very specific GRASS meaning of
'centroids', i.e. they really must be inside the area for which they
are calculated. Moreover, the center or mass for two or more different
areas can be exactly the same.
I might have not been clear in my suggestion: I completely understand the nature of centroids in v.centroids. The idea of the suggestion was that for many people, the notion of "centroid" is more similar to what you propose in v.centerpoint. So, why not merge the two modules so that we have one module v.centroid which, by default, provides the v.centerpoint functionality, but via a flag provides the current v.centroid functionality.
But at the same time, I think we have more important issues such as Python on Windows for example ;-), so I won't push this any further.
Personally, I support MarkusN’s idea of merging the two, if that’s
possible
from the code point of view. I find it more intuitive to look for a
module
creating centroids…
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Well, that’s when you come from the GRASS perspective with a very specific
meaning for ‘centroids’. I think for most users centroids are the center of
mass. So, I’m not sure that this will really be an issue of great confusion.
Centroids, in the sense of v.centroids for which you request the
modification, are calculated in the very specific GRASS meaning of
‘centroids’, i.e. they really must be inside the area for which they
are calculated. Moreover, the center or mass for two or more different
areas can be exactly the same.
I might have not been clear in my suggestion: I completely understand the nature of centroids in v.centroids. The idea of the suggestion was that for many people, the notion of “centroid” is more similar to what you propose in v.centerpoint. So, why not merge the two modules so that we have one module v.centroid which, by default, provides the v.centerpoint functionality, but via a flag provides the current v.centroid functionality.
But at the same time, I think we have more important issues such as Python on Windows for example ;-), so I won’t push this any further.
Miltinho - mcr@rc.unesp.br
Laboratório de Ecologia Espacial e Conservação - LEEC
Depto de Ecologia - UNESP - Rio Claro
Av. 24A, 1515- Bela Vista
13506-900 Rio Claro, SP, Brasil
On Fri, Jan 31, 2014 at 4:48 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
On 30/01/14 23:13, Markus Metz wrote:
On Thu, Jan 30, 2014 at 10:39 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 28/01/14 11:52, Markus Metz wrote:
On Mon, Jan 27, 2014 at 9:38 AM, Moritz Lennert
Personally, I support MarkusN's idea of merging the two, if that's
possible
from the code point of view. I find it more intuitive to look for a
module
creating centroids...
IMHO it will be confusing if there is a flag to calculate the center
of mass, but centroids are then not always the actual center of mass,
in which case it is safer to assume that centroids are not the center
of mass.
Well, that's when you come from the GRASS perspective with a very
specific
meaning for 'centroids'. I think for most users centroids are the center
of
mass. So, I'm not sure that this will really be an issue of great
confusion.
Centroids, in the sense of v.centroids for which you request the
modification, are calculated in the very specific GRASS meaning of
'centroids', i.e. they really must be inside the area for which they
are calculated. Moreover, the center or mass for two or more different
areas can be exactly the same.
I might have not been clear in my suggestion: I completely understand the
nature of centroids in v.centroids. The idea of the suggestion was that for
many people, the notion of "centroid" is more similar to what you propose
in v.centerpoint. So, why not merge the two modules so that we have one
module v.centroid which, by default, provides the v.centerpoint
functionality, but via a flag provides the current v.centroid functionality.
I agree with MarkusM that the modules should not be merged. I think that
it would create a confusion at the end. Users trying to create areas from
boundaries and complaining that they are not able to create a valid
topology.
One module is doing computation of point based on area, the other is
validating GRASS vector topology. We must explain this to the user and not
support misconceptions about GRASS vector model.
So, this should be solved on documentation level. If link (with a sentence
perhaps) in See also section is not enough, there can be a whole paragraph
explaining what the module is not doing and that the other module is doing
this.
Vaclav
But at the same time, I think we have more important issues such as Python
on Windows for example ;-), so I won't push this any further.